Chapter 26. Security in the Network

Table of Contents

26.1. X.509 Certification with YaST
26.2. VPN with SUSE LINUX
26.3. Masquerading and Firewalls
26.4. SSH — Secure Shell, the Safe Alternative
26.5. Network Authentication — Kerberos
26.6. Installing and Administering Kerberos
26.7. Security and Confidentiality


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.

26.1. X.509 Certification with YaST

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

26.1.1. The Principles of Digital Certification

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:

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 public key is circulated by the key owner for use by third parties. 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 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. X.509 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 (
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. Blocking X.509 Certificates

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. Repository for Certificates and CRLs

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. Proprietary PKI

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.

26.1.2. YaST Modules for CA Management

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. Creating a Root CA

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

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.


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. Creating or Revoking a Sub-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

YaST CA module - using CA

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 “Creating CRLs ”. Creating or Revoking User Certificates

To create client and server certificates, first enter a CA, as described in “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.


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 “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

Certificates of a CA Changing Standard 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 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 “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

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.


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

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 “Creating or Revoking a Sub-CA” (for sub-CAs) and Section “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 “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.


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. 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 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.

Exporting CA to LDAP

To export a CA, enter the CA as described in Section “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. A corresponding user object is then sought in the LDAP tree and the certificate is saved there with the attributes “userCertificate” (PEM format) and “userPKCS12” (PKCS12 format).

Exporting CRL to LDAP

Enter the CA containing the CRL to export and select CRL.... If desired, then create a new CRL and export this with Export+To LDAP. 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 “certificateRevocationList” attribute. 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 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 “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.


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. Exporting Certificates to Floppy

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. Importing General Server Certificates

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.


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.