Table of Contents
The security of data, services, and transfers within networks is and always will be an important issue. This chapter provides information about how to prevent unauthorized access to the system and how guard against attacks from the outside.
The establishment of a CA (certification authority) makes it possible to encrypt communications throughout the network, using techniques such as a VPN (virtual private network). Other mechanisms, such as masquerading, firewalls, and Kerberos, can be used to control the exchange of data and the general data traffic. The Secure Shell (SSH) allows users to log in to remote hosts by way of an encrypted connection. Apart from these purely technical instructions, this chapter also includes information about the more general security aspects of a Linux network.
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 not only used for communication, but can also be found on company ID cards, for example. The generation and administration of certificates is mostly handled by “official” institutions that offer this as a commercial service. In different cases, however, it may make sense to carry out these tasks yourself, for example, if a company does not wish to pass personal data to third parties.
SUSE LINUX offers two YaST modules for this purpose, which offer elementary management functions for digital X.509 certificates. The following sections offer an insight into the principles of digital certification and explain how to use YaST to create and administer certificates of this type. However, the topic of digital certification is extremely complex, so the following descriptions can offer only an overview. For more detailed information, refer to http://www.ietf.org/html.charters/pkix-charter.html.
Digital certification uses cryptographic processes to encrypt data, thereby protecting it from access by unauthorized persons. 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:
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.
The public key is circulated by the key owner for use by third parties.
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.
Table 26.1. X.509v3 Certificate
|Version||The version of the certificate, e.g., v3.|
|Serial Number||Unique certificate ID (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 (from...to).|
|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, e.g., “KeyUsage”, “BasicConstraints”, etc.|
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.
Table 26.2. X.509 Certificate Revocation List (CRL)
|Version||The version of the CRL, e.g., 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.|
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.
YaST provides two modules for elementary CA management. The functionality of these two modules is explained below on the basis of the key activities when administering CAs.
The first step when setting up a PKI is to create a root CA. This is achieved using+ in the YaST control center. After the module has been started, first see a list of all existing CAs. 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 enter the name to use to refer to the CA. 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 .
After clicking 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., enter a password in the second dialog. This password is always required when using the CA — when creating a sub-CA or generating certificates. already contains a meaningful default and does not generally need to be changed unless an application cannot deal with this key length. The 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 opens a dialog for setting different attributes from the X.509 extensions (Figure
In the third and last step, YaST displays the current settings for confirmation. If you click, the root CA is created and then appears in the overview.
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 26.2. “YaST CA module - using CA”). Click and select . This opens the same dialog as for creating a root 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
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 18.104.22.168. “Creating CRLs ”., see the dialog for administering CA certificates and sub-CAs. Reset compromised or otherwise unwanted sub-CAs here using . 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
To create client and server certificates, first enter a CA, as described in 22.214.171.124. “Creating or Revoking a Sub-CA”. User certificates should only be created in sub-CAs to preserve root CA security. After clicking , 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, 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 field. The default validity period for certificates is 365 days.
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.
126.96.36.199. “Creating CRLs ” explains how to create CRLs. Revoked certificates can be completely removed after publication in a CRL with .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
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 188.8.131.52. “Creating or Revoking a Sub-CA”. After clicking , find the 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”.
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 . After clicking , see a short summary and save your changes with .
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 184.108.40.206. “Creating or Revoking a Sub-CA” (for sub-CAs) and Section 220.127.116.11. “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 18.104.22.168. “Creating or Revoking a Sub-CA” and click . 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 . Then specify the period of validity for the new CRL (default: 30 days). Click for the CRL to be created and displayed. Afterwards, must publish this CRL.
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”).
Table 26.3. Passwords during LDAP Export
|LDAP Password||This password authorizes the user to make entries in the LDAP tree|
|Certificate Password||This 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.
To export a CA, enter the CA as described in Section 22.214.171.124. “Creating or Revoking a Sub-CA”. Select + 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”.
Enter the CA containing the certificate to export then select userCertificate” (PEM format) and “userPKCS12” (PKCS12 format).. Select the required certificate from the certificate list in the upper part of the dialog and select + . The LDAP data is entered here in the same way as for CAs. A corresponding user object is then sought in the LDAP tree and the certificate is saved there with the attributes “
Enter the CA containing the CRL to export and select certificateRevocationList” attribute.. If desired, then create a new CRL and export this with + . The LDAP data is also entered here in the same way as with CAs. Entries are then made in the LDAP at the same point as the associated CA, but using the “
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 126.96.36.199. “Exporting CA Objects to LDAP ”, except select instead of . 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 .
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. Select the required certificate in the list and export it with + . The next dialog asks you to insert a floppy and enter the new PKCS12 password. After you click , 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 in the YaST control center under . 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+ and insert the appropriate floppy. After entering the certificate password and clicking , the certificate is imported then displayed in the description field.
If you select+ 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.