Because the public key process is in widespread use, there are many public keys in circulation. Successful use of this system requires that every user be sure that a public key does indeed belong to the assumed owner. The assignment of users and public keys will be confirmed by trustworthy instances by means of public key certificates. Such certificates contain the name of the key owner, the corresponding public key, and the electronic signature of the person issuing the certificate. Trustworthy instances are usually part of a certification infrastructure that, in addition to issuing and signing certificates, is also responsible for the other aspects of certificate management. This includes publication, withdrawal and renewal of certificates. An infrastructure of this kind is generally referred to as a public key infrastructure or PKI. One familiar PKI is the OpenPGP standard in which users publish their certificates themselves without central authorization points. These certificates become trustworthy when signed by other parties in the “web of trust.”

The hierarchically structured X.509 Public Key Infrastructure (PKIX) is an alternative model defined by the IETF (Internet Engineering Task Force that now acts as an exemplar for almost all publicly-used PKIs. In this model, authentication is carried out in a hierarchical tree structure by certification authorities (CA). The root of the tree is formed by the root CA, which certifies all sub-CAs or the next level own to the sub-CAs of the lowest level which issue user certificates. The user certificates become trustworthy through certification by the next highest sub-CAs, which in turn have been certified by the higher levels of the hierarchy. This creates a certification path that ends with the root CA.

The security of such a PKI stands and falls with the trustworthiness of the CA certificates. To make certification practices transparent for PKI customers, the PKI operator defines a certification practice statement (CPS) in which the procedures for certificate management are defined. This should ensure that the PKI only issues trustworthy certificates.

An X.509 certificate is a data structure with several fixed fields and (optional) additional extensions. The fixed fields mainly contain the name of the key owner, the public key, and the data relating to the issuing CA (name and signature). For security reasons, a certificate should only have a limited period of validity, so a field is also provided for this date. The CA guarantees the validity of the certificate in the specified period. The CPS usually stipulates that the PKI (in other words, the CA in the final analysis) should create and distribute a new certificate before validity lapses.

The extensions can contain any additional information. An application does not normally need to be able to evaluate an extension unless it is identified as critical. If an application does not recognize a critical extension, it must reject the certificate. Some extensions reduce the use of the certificate to a specific application, such as signature or encryption.

Table 26.1. “X.509v3 Certificate” shows the principle underlying an X.509 certificate in version 3.

If a certificate becomes untrustworthy before the validity period has lapsed, it must be blocked immediately. This can become necessary if, for example, the private key has become public knowledge. This applies in particular if the private key belongs to a CA rather than a user certificate. In this case, all user certificates issued by the relevant CA must be blocked immediately. If a certificate is blocked, the PKI (the responsible CA) must make this information available to all those involved. The instrument currently used for this is a certificate revocation list (CRL).

These lists are supplied by the CA to public CRL distribution points (CDPs) at regular intervals. As an option, the CDP can also be named as an extension in the certificate, so the checker can fetch a current CRL from there for validation purposes. One way to do this is the online certificate status protocol (OCSP). The authenticity of the CRLs is ensured by means of the signature of the issuing CA. Table 26.2. “X.509 Certificate Revocation List (CRL)” shows the principle underlying an X.509 CRL.

To be used, the certificates and CRLs for a CA must be made publicly accessible. This involves a repository. Because the certificates and CRLs cannot be forged, thanks to the signature, the repository itself does not need to be secured in a special way. On the contrary, the aim should be to achieve the simplest and fastest access possible. For this reason, certificates are often provided by means of an LDAP or HTTP server. Find explanations about this in Section 21.8. “LDAP — A Directory Service”. Chapter 22. The Apache Web Server contains information about the HTTP server.

YaST contains modules for the elementary management of X.509 certificates. This mainly involves the creation of CAs, sub-CAs and their certificates. At this point it should be noted that the services of a PKI go far beyond simply creating and distributing certificates and CRLs. The operation of a PKI is a service that also requires a well-conceived administrative infrastructure. The continuous updating of certificates and CRLs requires very complex management, which is provided by commercial PKI products and can also be partly automated. YaST functionality for creating and distributing CAs and certificates cannot provide this background information at present. In general, the PKI products currently available under Open Source are subject to the commercial versions. To set up a “small” PKI, you can use the YaST modules described below. However, you should use commercial products to set up an “official” — or even commercial — PKI.

The first step when setting up a PKI is to create a root CA. This is achieved using ‘Security and Users’+‘CA Management’ in the YaST control center. After the module has been started, first see a list of all existing CAs. ‘Create Root CA’ opens the first of three dialogs for entering CA-related data.

Enter the basic data for the CA in the first dialog, shown in Figure 26.1. “YaST CA module — Basic Data for a Root CA”. For ‘Common Name’ enter the name to use to refer to the CA. ‘CA Name’ should be the technical name of the CA. Directory names, among other things, are derived from this name, which is why only the characters specified in the help can be used. The technical name is also displayed in the overview when the module is started. Several e-mail addresses can be entered that can be seen by the CA user. This can be helpful for inquiries. Select the country where the CA is operated in ‘Country’.

Figure 26.1. YaST CA module — Basic Data for a Root CA

After clicking ‘Next’, enter a password in the second dialog. This password is always required when using the CA — when creating a sub-CA or generating certificates. ‘Key Length’ already contains a meaningful default and does not generally need to be changed unless an application cannot deal with this key length. The ‘validity period’ in the case of a CA is 3650 days (roughly ten years). This long period makes sense because the replacement of a deleted CA involves an enormous administrative effort. Clicking ‘Extended’ opens a dialog for setting different attributes from the X.509 extensions (Figure 26.4. “YaST CA Module — Extended Settings”). These values have rational default settings and should only be changed if you are really sure of what you are doing.

In the third and last step, YaST displays the current settings for confirmation. If you click ‘Create’, the root CA is created and then appears in the overview.

	Tip
In general, it is best not to allow user certificates to be issued by the root CA. It is better to create at least one CA and create the user certificates from there. This has the advantage that the root CA can be kept isolated and secure, for example, on an isolated computer on secure premises. This makes it very difficult to attack the root CA.

A sub-CA is created in exactly the same way as a root CA, except it is first necessary to select the CA in which to create the sub-CA is to be created. After the program starts, select the required CA from the list and click ‘Enter CA’. The first time you enter a CA after the program is started, enter the password, after which you are taken to a dialog in which the key CA information is displayed (Figure 26.2. “YaST CA module - using CA”). Click ‘Extended...’ and select ‘Create Sub-CA’. This opens the same dialog as for creating a root CA.

Figure 26.2. YaST CA module - using CA

	Tip
The validity period for a sub-CA must be fully within the validity period of the “parent” CA. Because a sub-CA is always created after the “parent” CA, the uncorrected standard value leads to an error message. To avoid this, enter a permissible value for the period of validity.

After selecting ‘Certificates’, see the dialog for administering CA certificates and sub-CAs. Reset compromised or otherwise unwanted sub-CAs here using ‘Revoke’. Revocation is not enough to deactivate a sub-CA on its own. Also publish revoked sub-CAs in a CRL. The creation of CRLs is described in Section 26.1.2.5. “Creating CRLs ”.

To create client and server certificates, first enter a CA, as described in  26.1.2.2. “Creating or Revoking a Sub-CA”. User certificates should only be created in sub-CAs to preserve root CA security. After clicking ‘Certificates...’, see the dialog for administering certificates, shown in Figure 26.3. “Certificates of a CA”. The upper part contains a list of existing certificates, while the data for the currently selected certificate appears below.

With ‘Add’, create new client and server certificates and add them to the list of CAs. The dialog for recording data is very similar to the one for creating the CAs and the same principles apply. Additional remarks relate to the e-mail addresses in certificates intended for e-mail signature and encryption. The e-mail address of the sender (the private key owner) should be contained in the certificate for the signature to enable the e-mail address to assign the correct certificate. For certificate assignment during encryption, it is necessary for the e-mail address of the recipient (the public key owner) to be included in the certificate. In addition, in the case of server certificates, the host name of the server must be entered in the ‘Common Name’ field. The default validity period for certificates is 365 days.

	Tip
If certificates for IPsec applications should be created with Windows XP, client certificates must be used. There, the “KeyUsage” extension contains the values expected by Windows.

‘Revoke’ enables you to withdraw compromised or otherwise unwanted certificates. However, revocation alone is not enough to deactivate a certificate. Also publish revoked certificates in a CRL. Section 26.1.2.5. “Creating CRLs ” explains how to create CRLs. Revoked certificates can be completely removed after publication in a CRL with ‘Delete’.

Figure 26.3. Certificates of a CA

The previous sections explained how to create sub-CAs, client certificates, and server certificates. Special settings are used in the extensions of the X.509 certificate. These settings have been given rational defaults for every certificate type and do not normally need to be changed. However, it may be that a particular application has special requirements in relation to the content of these extensions. If you frequently create certificates for an application of this kind, it may make sense to adjust the defaults. Otherwise, start from scratch every time you create a certificate.

The system manages a set of defaults for every CA for the creation of sub-CAs, client certificates and server certificates. To change these defaults, enter the required CA, as described in Section 26.1.2.2. “Creating or Revoking a Sub-CA”. After clicking ‘Extended’, find the ‘Defaults’ option, where you can choose for which type the settings should be changed. After this, reach the dialog for changing the defaults, shown in Figure 26.4. “YaST CA Module — Extended Settings”.

Figure 26.4. YaST CA Module — Extended Settings

The tree structure and all extensions known to the system are displayed on the left. If you click a field here, change the associated value on the right side and set or delete the “critical” marking with ‘critical’. After clicking ‘Next’, see a short summary and save your changes with ‘Save’.

	Tip
All changes to the defaults only affect objects created after this point. Already existing CAs and certificates remain unchanged.

If compromised or otherwise unwanted certificates should be excluded from further use, they must first be revoked. The procedure for this was explained in Section 26.1.2.2. “Creating or Revoking a Sub-CA” (for sub-CAs) and Section 26.1.2.3. “Creating or Revoking User Certificates” (for user certificates). After this, a CRL must be created and published with this information.

The system administers precisely one CRL for every CA. To create or update this CRL, first enter the required CA, as described in Section 26.1.2.2. “Creating or Revoking a Sub-CA” and click ‘CRL...’. The following dialog then displays a summary of the last CRL of this CA. If you have revoked new sub-CAs or certificates since its creation, create a new CRL so this information can be added to the CRL. To create or update the CRL, select ‘Create CRL’. Then specify the period of validity for the new CRL (default: 30 days). Click ‘OK’ for the CRL to be created and displayed. Afterwards, must publish this CRL.

	Tip
Applications that evaluate CRLs reject certificates whose CRL is deleted. As a PKI provider, it is your duty always to create and publish a new CRL before a current CRL lapses (period of validity). YaST does not provide a function for automating this procedure at present.

The executing computer should be configured with the YaST LDAP client for LDAP export. This provides LDAP server information at runtime that can be used when completing dialog fields. Otherwise, although export may be possible, all LDAP data must be entered manually. You must always enter several passwords (see Table 26.3. “Passwords during LDAP Export”).

Certificates, CAs, and CRLs can be exported to LDAP.

If you have set up a repository on the computer for administering CAs, you can use this option to create the CA objects directly as a file at the correct location. Different output formats are available, such as PEM, DER, and PKCS12. In the case of PEM, it is also possible to choose whether a certificate should be exported with or without key and whether the key is to be encrypted. In the case of PKCS12, it is also possible to export the certification path.

Export in file format is performed for certificates, CAs, and CRLs in the same way as described for LDAP in Section 26.1.2.6. “Exporting CA Objects to LDAP ”, except select ‘Export as File’ instead of ‘Export to LDAP’. This then takes you to a dialog for selecting the required output format and for entering the password and file name. The certificate is stored at the required location after you click ‘OK’.

	Tip
You can select any storage location in the file system. This option can also be used to save CA objects on a USB stack as transport medium for example.

YaST also allows certificates (but not CAs or CRLs) to be exported to a floppy. The point of this option is the convenient transport of server certificates from an isolated CA computer to a server that should use these certificates. This YaST function is the counterpart of a special YaST module that only serves to import certificates exported in this way onto the server (see the next section).

For floppy export, first enter the CA containing the certificates to export and select ‘Certificates’. Select the required certificate in the list and export it with ‘Export’+‘Export to Floppy’. The next dialog asks you to insert a floppy and enter the new PKCS12 password. After you click ‘Next’, the certificate is written to the floppy.

If you have exported a server certificate to floppy on an isolated CA management computer with YaST, you can import this certificate on a server as a general server certificate. Do this during installation or at a later point with the YaST module ‘Import General Server Certificate’ in the YaST control center under ‘Security and Users’. The general server certificate is stored in /etc/ssl/servercerts and can be used there by any CA-supported service. When this certificate lapses, it can easily be replaced using the same mechanisms. The only remaining administrative effort required is the restart of the participating services.

After the module has been started, see the data for the current certificate in the description field. For import, select ‘Import’+‘From Floppy’ and insert the appropriate floppy. After entering the certificate password and clicking ‘Next’, the certificate is imported then displayed in the description field.

	Tip
If you select ‘Import’+‘From Hard Disk’ here, you can select the source in the file system. This option can also be used to import certificates from a USB stick as transport medium, for example.