Applies to SUSE Linux Enterprise Server 12 SP5

18 Managing X.509 Certification #

An increasing number of authentication mechanisms are based on cryptographic procedures. Digital certificates that assign cryptographic keys to their owners play an important role in this context. These certificates are used for communication and can also be found, for example, on company ID cards. The generation and administration of certificates is mostly handled by official institutions that offer this as a commercial service. In some cases, however, it may make sense to carry out these tasks yourself. For example, if a company does not want to pass personal data to third parties.

YaST provides two modules for certification, which offer basic management functions for digital X.509 certificates. The following sections explain the basics of digital certification and how to use YaST to create and administer certificates of this type.

18.1 The Principles of Digital Certification #

Digital certification uses cryptographic processes to encrypt and protect data from access by unauthorized people. The user data is encrypted using a second data record, or key. The key is applied to the user data in a mathematical process, producing an altered data record in which the original content can no longer be identified. Asymmetrical encryption is now in general use (public key method). Keys always occur in pairs:

Private Key: The private key must be kept safely by the key owner. Accidental publication of the private key compromises the key pair and renders it useless.
Public Key: The key owner circulates the public key for use by third parties.

18.1.1 Key Authenticity #

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 actually belongs to the assumed owner. The assignment of users to public keys is confirmed by trustworthy organizations with 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 organizations that issue and sign public key certificates are usually part of a certification infrastructure. This is responsible for the other aspects of certificate management, such as publication, withdrawal, and renewal of certificates. An infrastructure of this kind is generally called 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 X.509 Public Key Infrastructure (PKIX) is an alternative model defined by the IETF (Internet Engineering Task Force) that serves as a model for almost all publicly-used PKIs today. In this model, authentication is made by certificate authorities (CA) in a hierarchical tree structure. The root of the tree is the root CA, which certifies all sub-CAs. The lowest level of sub-CAs issue user certificates. The user certificates are trustworthy by certification that can be traced to the root CA.

The security of such a PKI depends on the trustworthiness of the CA certificates. To make certification practices clear to PKI customers, the PKI operator defines a certification practice statement (CPS) that defines the procedures for certificate management. This should ensure that the PKI only issues trustworthy certificates.

18.1.2 X.509 Certificates #

An X.509 certificate is a data structure with several fixed fields and, optionally, 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 requires the PKI (the issuing CA) to create and distribute a new certificate before expiration.

The extensions can contain any additional information. An application is only required to be able to evaluate an extension if it is identified as critical. If an application does not recognize a critical extension, it must reject the certificate. Some extensions are only useful for a specific application, such as signature or encryption.

Table 18.1 shows the fields of a basic X.509 certificate in version 3.

Table 18.1: X.509v3 Certificate #

Field	Content
Version	The version of the certificate, for example, v3
Serial Number	Unique certificate ID (an integer)
Signature	The ID of the algorithm used to sign the certificate
Issuer	Unique name (DN) of the issuing authority (CA)
Validity	Period of validity
Subject	Unique name (DN) of the owner
Subject Public Key Info	Public key of the owner and the ID of the algorithm
Issuer Unique ID	Unique ID of the issuing CA (optional)
Subject Unique ID	Unique ID of the owner (optional)
Extensions	Optional additional information, such as “KeyUsage” or “BasicConstraints”

18.1.3 Blocking X.509 Certificates #

If a certificate becomes untrustworthy before it has expired, it must be blocked immediately. This can become necessary if, for example, the private key has accidentally been made public. Blocking certificates is especially important 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 using a certificate revocation list (CRL).

These lists are supplied by the CA to public CRL distribution points (CDPs) at regular intervals. The CDP can optionally be named as an extension in the certificate, so a checker can fetch a current CRL for validation purposes. One way to do this is the online certificate status protocol (OCSP). The authenticity of the CRLs is ensured with the signature of the issuing CA. Table 18.2 shows the basic parts of a X.509 CRL.

Table 18.2: X.509 Certificate Revocation List (CRL) #

Field	Content
Version	The version of the CRL, such as v2
Signature	The ID of the algorithm used to sign the CRL
Issuer	Unique name (DN) of the publisher of the CRL (usually the issuing CA)
This Update	Time of publication (date, time) of this CRL
Next Update	Time of publication (date, time) of the next CRL
List of revoked certificates	Every entry contains the serial number of the certificate, the time of revocation, and optional extensions (CRL entry extensions)
Extensions	Optional CRL extensions

18.1.4 Repository for Certificates and CRLs #

The certificates and CRLs for a CA must be made publicly accessible using a repository. Because the signature protects the certificates and CRLs from being forged, the repository itself does not need to be secured in a special way. Instead, it tries to grant the simplest and fastest access possible. For this reason, certificates are often provided on an LDAP or HTTP server. Find explanations about LDAP in Chapter 5, LDAP—A Directory Service. Chapter 33, The Apache HTTP Server contains information about the HTTP server.

18.1.5 Proprietary PKI #

YaST contains modules for the basic management of X.509 certificates. This mainly involves the creation of CAs, sub-CAs, and their certificates. The services of a PKI go far beyond simply creating and distributing certificates and CRLs. The operation of a PKI requires a well-conceived administrative infrastructure allowing continuous update of certificates and CRLs. This infrastructure is provided by commercial PKI products and can also be partly automated. YaST provides tools for creating and distributing CAs and certificates, but cannot currently offer this background infrastructure. To set up a small PKI, you can use the available YaST modules. However, you should use commercial products to set up an “official” or commercial PKI.

18.2 YaST Modules for CA Management #

YaST provides two modules for basic CA management. The primary management tasks with these modules are explained here.

18.2.1 Creating a Root CA #

After a default installation, SUSE Linux Enterprise Server contains already a root CA named YaST_Default_CA. Use this module to create additional root CAs. The first step when setting up a PKI is to create a root CA. Do the following:

Start YaST and go to Security and Users › CA Management.
Click Create Root CA.
Enter the basic data for the CA in the first dialog, shown in Figure 18.1. The text boxes have the following meanings:
Figure 18.1: YaST CA Module—Basic Data for a Root CA #

CA Name
Enter the technical name of the CA. Directory names, among other things, are derived from this name, which is why only the characters listed in the help can be used. The technical name is also displayed in the overview when the module is started.
Common Name
Enter the name for use in referring to the CA.
E-Mail Addresses
Several e-mail addresses can be entered that can be seen by the CA user. This can be helpful for inquiries.
Country
Select the country where the CA is operated.
Organization, Organizational Unit, Locality, State
Optional values
Proceed with 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. The text boxes have the following meaning:
Key Length
Key Length contains a meaningful default and does not generally need to be changed unless an application cannot deal with this key length. The higher the number the more secure your password is.
Valid Period (days)
The Valid Period in the case of a CA defaults to 3650 days (roughly ten years). This long period makes sense because the replacement of a deleted CA involves an enormous administrative effort.
Clicking Advanced Options opens a dialog for setting different attributes from the X.509 extensions (Figure 18.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. Proceed with Next.
Review the summary. YaST displays the current settings for confirmation. Click Create. The root CA is created 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 sub-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.

18.2.2 Changing Password #

If you need to change your password for your CA, proceed as follows:

Start YaST and open the CA module.
Select the required root CA and click Enter CA.
Enter the password if you entered a CA the first time. YaST displays the CA key information in the Description tab (see Figure 18.2).
Click Advanced and select Change CA Password. A dialog opens.
Enter the old and the new password.
Finish with OK

18.2.3 Creating or Revoking a Sub-CA #

A sub-CA is created in the same way as a root CA.

Note

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

Do the following:

Start YaST and open the CA module.
Select the required root CA and click Enter CA.
Enter the password if you are entering a CA for the first time. YaST displays the CA key information in the tab Description (see Figure 18.2).
Figure 18.2: YaST CA Module—Using a CA #
Click Advanced and select Create SubCA. This opens the same dialog as for creating a root CA.
Proceed as described in Section 18.2.1, “Creating a Root CA”.
It is possible to use one password for all your CAs. Enable Use CA Password as Certificate Password to give your sub-CAs the same password as your root CA. This helps to reduce the amount of passwords for your CAs.
Note: Check your Valid Period
Take into account that the valid period must be lower than the valid period in the root CA.
Select the Certificates tab. Reset compromised or otherwise unwanted sub-CAs here, using Revoke. Revocation alone is not enough to deactivate a sub-CA. You must also publish revoked sub-CAs in a CRL. The creation of CRLs is described in Section 18.2.6, “Creating Certificate Revocation Lists (CRLs)”.
Finish with OK.

18.2.4 Creating or Revoking User Certificates #

Creating client and server certificates is very similar to creating CAs in Section 18.2.1, “Creating a Root CA”. The same principles apply here. In certificates intended for e-mail signature, the e-mail address of the sender (the private key owner) should be contained in the certificate to enable the e-mail program 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 the case of server and client certificates, the host name of the server must be entered in the Common Name field. The default validity period for certificates is 365 days.

To create client and server certificates, do the following:

Start YaST and open the CA module.
Select the required root CA and click Enter CA.
Enter the password if you are entering a CA for the first time. YaST displays the CA key information in the Description tab.
Click Certificates (see Figure 18.3).
Figure 18.3: Certificates of a CA #
Click Add › Add Server Certificate and create a server certificate.
Click Add › Add Client Certificate and create a client certificate. Do not forget to enter an e-mail address.
Finish with OK

To revoke compromised or otherwise unwanted certificates, do the following:

Start YaST and open the CA module.
Select the required root CA and click Enter CA.
Enter the password if you are entering a CA for the first time. YaST displays the CA key information in the Description tab.
Click Certificates (see Section 18.2.3, “Creating or Revoking a Sub-CA”).
Select the certificate to revoke and click Revoke.
Choose a reason to revoke this certificate.
Finish with OK.

Note

Revocation alone is not enough to deactivate a certificate. Also publish revoked certificates in a CRL. Section 18.2.6, “Creating Certificate Revocation Lists (CRLs)” explains how to create CRLs. Revoked certificates can be completely removed after publication in a CRL with Delete.

18.2.5 Changing Default Values #

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 you have special requirements for these extensions. In this case, it may make sense to adjust the defaults. Otherwise, start from scratch every time you create a certificate.

Start YaST and open the CA module.
Enter the required root CA, as described in Section 18.2.3, “Creating or Revoking a Sub-CA”.
Click Advanced › Edit Default.
Choose type of certificate to change and proceed with Next.
The dialog for changing the defaults as shown in Figure 18.4, “YaST CA Module—Extended Settings” opens.
Figure 18.4: YaST CA Module—Extended Settings #
Change the associated value on the right side and set or delete the critical setting with critical.
Click Next to see a short summary.
Finish your changes with Save.

Note

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

18.2.6 Creating Certificate Revocation Lists (CRLs) #

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

The system maintains only one CRL for each CA. To create or update this CRL, do the following:

Start YaST and open the CA module.
Enter the required CA, as described in Section 18.2.3, “Creating or Revoking a Sub-CA”.
Click CRL. The dialog that opens displays a summary of the last CRL of this CA.
Create a new CRL with Generate CRL if you have revoked new sub-CAs or certificates since its creation.
Specify the period of validity for the new CRL (default: 30 days).
Click OK to create and display the CRL. Afterward, you must publish this CRL.

Note

Applications that evaluate CRLs reject every certificate if the CRL is not available or has expired. As a PKI provider, it is your duty always to create and publish a new CRL before the current CRL expires (period of validity). YaST does not provide a function for automating this procedure.

18.2.7 Exporting CA Objects to LDAP #

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 18.3, “Passwords during LDAP Export”).

Table 18.3: Passwords during LDAP Export #

Password	Meaning
LDAP Password	Authorizes the user to make entries in the LDAP tree.
Certificate Password	Authorizes the user to export the certificate.
New Certificate Password	The PKCS12 format is used during LDAP export. This format forces the assignment of a new password for the exported certificate.

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

Exporting a CA to LDAP: To export a CA, enter the CA as described in Section 18.2.3, “Creating or Revoking a Sub-CA”. Select Extended › Export to LDAP in the subsequent dialog, which opens the dialog for entering LDAP data. If your system has been configured with the YaST LDAP client, the fields are already partly completed. Otherwise, enter all the data manually. Entries are made in LDAP in a separate tree with the attribute “caCertificate”.
Exporting a Certificate to LDAP: Enter the CA containing the certificate to export then select Certificates. Select the required certificate from the certificate list in the upper part of the dialog and select Export › Export to LDAP. The LDAP data is entered here in the same way as for CAs. The certificate is saved with the corresponding user object in the LDAP tree with the attributes “userCertificate” (PEM format) and “userPKCS12” (PKCS12 format).
Exporting a CRL to LDAP: Enter the CA containing the CRL to export and select CRL. If desired, create a new CRL and click Export. The dialog that opens displays the export parameters. You can export the CRL for this CA either once or in periodical time intervals. Activate the export by selecting Export to LDAP and enter the respective LDAP data. To do this at regular intervals, select the Repeated Recreation and Export radio button and change the interval, if appropriate.

18.2.8 Exporting CA Objects as a File #

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 should be encrypted. In the case of PKCS12, it is also possible to export the certification path.

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

For CRLs click Export, select Export to file, choose the export format (PEM or DER) and enter the path. Proceed with OK to save it to the respective location.

Tip

You can select any storage location in the file system. This option can also be used to save CA objects on a transport medium, such as a flash disk. The /media directory generally holds any type of drive except the hard disk of your system.

18.2.9 Importing Common Server Certificates #

If you have exported a server certificate with YaST to your media on an isolated CA management computer, you can import this certificate on a server as a common server certificate. Do this during installation or at a later point with YaST.

Note

You need one of the PKCS12 formats to import your certificate successfully.

The general server certificate is stored in /etc/ssl/servercerts and can be used there by any CA-supported service. When this certificate expires, it can easily be replaced using the same mechanisms. To get things functioning with the replaced certificate, restart the participating services.

Tip

If you select Import here, you can select the source in the file system. This option can also be used to import certificates from removable media, such as a flash disk.

To import a common server certificate, do the following:

Start YaST and open Common Server Certificate under Security and Users
View the data for the current certificate in the description field after YaST has been started.
Select Import and the certificate file.
Enter the password and click Next. The certificate is imported then displayed in the description field.
Close YaST with Finish.