ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 16. Managing X.509 Certification</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.network_security.html" title="Part III. Network Security"><link rel="prev" href="cha.security.vpnserver.html" title="Chapter 15. Configuring VPN Server"><link rel="next" href="part.apparmor.html" title="Part IV. Confining Privileges with Novell AppArmor"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.network_security.html">Network Security</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 15. Configuring VPN Server" href="cha.security.vpnserver.html"><span>◀</span></a> </strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 16. Managing X.509 Certification"><div class="titlepage"><div><div><h2 class="title"><a name="cha.security.yast_ca"></a>Chapter 16. Managing X.509 Certification<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.security.yast_ca">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.security.yast_ca.html#sec.security.yast_ca.intro">16.1. The Principles of Digital Certification</a></span></dt><dt><span class="sect1"><a href="cha.security.yast_ca.html#sec.security.yast_ca.module">16.2. YaST Modules for CA Management</a></span></dt></dl></div><a class="indexterm" name="id592577"></a><a class="indexterm" name="id592586"></a><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>
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 wish
to pass personal data to third parties.
</p><p>
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. For more
detailed information, refer to
<a class="ulink" href="http://www.ietf.org/html.charters/pkix-charter.html" target="_top">http://www.ietf.org/html.charters/pkix-charter.html</a>.
</p></div><div class="sect1" title="16.1. The Principles of Digital Certification"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.yast_ca.intro"></a>16.1. The Principles of Digital Certification<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.intro">¶</a></span></h2></div></div></div><a class="indexterm" name="id592628"></a><p>
Digital certification uses cryptographic processes to encrypt data,
protect the data from access by unauthorized people. The user data is
encrypted using a second data record, or <span class="emphasis"><em>key</em></span>. 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
(<span class="emphasis"><em>public key method</em></span>). Keys always occur in pairs:
</p><div class="variablelist"><dl><dt><span class="term">Private Key</span></dt><dd><p>
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.
</p></dd><dt><span class="term">Public Key</span></dt><dd><p>
The key owner circulates the public key for use by third parties.
</p></dd></dl></div><div class="sect2" title="16.1.1. Key Authenticity"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.intro.keyauth"></a>16.1.1. Key Authenticity<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.intro.keyauth">¶</a></span></h3></div></div></div><p>
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.
</p><p>
Trustworthy organizations that issue and sign public key certificates
are usually part of a certification infrastructure that is also
responsible for the other aspects of certificate management, such as
publication, withdrawal, and renewal of certificates. An infrastructure
of this kind is generally referred to as a <span class="emphasis"><em>public key
infrastructure</em></span> or <span class="emphasis"><em>PKI</em></span>. One familiar PKI
is the <span class="emphasis"><em>OpenPGP</em></span> standard in which users publish
their certificates themselves without central authorization points.
These certificates become trustworthy when signed by other parties in
the <span class="quote">“<span class="quote">web of trust.</span>”</span>
</p><p>
The <span class="emphasis"><em>X.509 Public Key Infrastructure</em></span> (PKIX) is an
alternative model defined by the <span class="emphasis"><em>IETF</em></span> (Internet
Engineering Task Force) that serves as a model for almost all
publicly-used PKIs today. In this model, authentication is made by
<span class="emphasis"><em>certificate authorities</em></span> (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.
</p><p>
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 <span class="emphasis"><em>certification practice
statement</em></span> (CPS) that defines the procedures for certificate
management. This should ensure that the PKI only issues trustworthy
certificates.
</p></div><div class="sect2" title="16.1.2. X.509 Certificates"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.intro.x509"></a>16.1.2. X.509 Certificates<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.intro.x509">¶</a></span></h3></div></div></div><a class="indexterm" name="id592768"></a><p>
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.
</p><p>
The extensions can contain any additional information. An application is
only required to be able to evaluate an extension if it is identified as
<span class="emphasis"><em>critical</em></span>. 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.
</p><p>
<a class="xref" href="cha.security.yast_ca.html#tab.yast.ca.intro.x509" title="Table 16.1. X.509v3 Certificate">Table 16.1</a>
shows the fields of a basic X.509 certificate in version 3.
</p><div class="table"><a name="tab.yast.ca.intro.x509"></a><p class="title"><b>Table 16.1. X.509v3 Certificate</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#tab.yast.ca.intro.x509">¶</a></span></p><div class="table-contents"><table summary="X.509v3 Certificate" border="1"><colgroup><col><col></colgroup><thead><tr><th>
<p>
Field
</p>
</th><th>
<p>
Content
</p>
</th></tr></thead><tbody><tr><td>
<p>
Version
</p>
</td><td>
<p>
The version of the certificate, for example, v3
</p>
</td></tr><tr><td>
<p>
Serial Number
</p>
</td><td>
<p>
Unique certificate ID (an integer)
</p>
</td></tr><tr><td>
<p>
Signature
</p>
</td><td>
<p>
The ID of the algorithm used to sign the certificate
</p>
</td></tr><tr><td>
<p>
Issuer
</p>
</td><td>
<p>
Unique name (DN) of the issuing authority (CA)
</p>
</td></tr><tr><td>
<p>
Validity
</p>
</td><td>
<p>
Period of validity
</p>
</td></tr><tr><td>
<p>
Subject
</p>
</td><td>
<p>
Unique name (DN) of the owner
</p>
</td></tr><tr><td>
<p>
Subject Public Key Info
</p>
</td><td>
<p>
Public key of the owner and the ID of the algorithm
</p>
</td></tr><tr><td>
<p>
Issuer Unique ID
</p>
</td><td>
<p>
Unique ID of the issuing CA (optional)
</p>
</td></tr><tr><td>
<p>
Subject Unique ID
</p>
</td><td>
<p>
Unique ID of the owner (optional)
</p>
</td></tr><tr><td>
<p>
Extensions
</p>
</td><td>
<p>
Optional additional information, such as <span class="quote">“<span class="quote">KeyUsage</span>”</span> or
<span class="quote">“<span class="quote">BasicConstraints</span>”</span>
</p>
</td></tr></tbody></table></div></div><br class="table-break"></div><div class="sect2" title="16.1.3. Blocking X.509 Certificates"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.intro.crl"></a>16.1.3. Blocking X.509 Certificates<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.intro.crl">¶</a></span></h3></div></div></div><a class="indexterm" name="id593060"></a><p>
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 <span class="emphasis"><em>certificate revocation list</em></span>
(CRL).
</p><p>
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 <span class="emphasis"><em>online
certificate status protocol</em></span> (OCSP). The authenticity of the
CRLs is ensured with the signature of the issuing CA.
<a class="xref" href="cha.security.yast_ca.html#tab.yast.ca.intro.crl" title="Table 16.2. X.509 Certificate Revocation List (CRL)">Table 16.2</a>
shows the basic parts of a X.509 CRL.
</p><div class="table"><a name="tab.yast.ca.intro.crl"></a><p class="title"><b>Table 16.2. X.509 Certificate Revocation List (CRL)</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#tab.yast.ca.intro.crl">¶</a></span></p><div class="table-contents"><table summary="X.509 Certificate Revocation List (CRL)" border="1"><colgroup><col><col></colgroup><thead><tr><th>
<p>
Field
</p>
</th><th>
<p>
Content
</p>
</th></tr></thead><tbody><tr><td>
<p>
Version
</p>
</td><td>
<p>
The version of the CRL, such as v2
</p>
</td></tr><tr><td>
<p>
Signature
</p>
</td><td>
<p>
The ID of the algorithm used to sign the CRL
</p>
</td></tr><tr><td>
<p>
Issuer
</p>
</td><td>
<p>
Unique name (DN) of the publisher of the CRL (usually the issuing
CA)
</p>
</td></tr><tr><td>
<p>
This Update
</p>
</td><td>
<p>
Time of publication (date, time) of this CRL
</p>
</td></tr><tr><td>
<p>
Next Update
</p>
</td><td>
<p>
Time of publication (date, time) of the next CRL
</p>
</td></tr><tr><td>
<p>
List of revoked certificates
</p>
</td><td>
<p>
Every entry contains the serial number of the certificate, the time
of revocation, and optional extensions (CRL entry extensions)
</p>
</td></tr><tr><td>
<p>
Extensions
</p>
</td><td>
<p>
Optional CRL extensions
</p>
</td></tr></tbody></table></div></div><br class="table-break"></div><div class="sect2" title="16.1.4. Repository for Certificates and CRLs"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.intro.repository"></a>16.1.4. Repository for Certificates and CRLs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.intro.repository">¶</a></span></h3></div></div></div><a class="indexterm" name="id593288"></a><p>
The certificates and CRLs for a CA must be made publicly accessible
using a <span class="emphasis"><em>repository</em></span>. 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 <a class="xref" href="cha.security.ldap.html" title="Chapter 4. LDAP—A Directory Service">Chapter 4, <i>LDAP—A Directory Service</i></a>.
Chapter <i>The Apache HTTP Server</i> (↑Reference) contains information about
the HTTP server.
</p></div><div class="sect2" title="16.1.5. Proprietary PKI"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.intro.ldap"></a>16.1.5. Proprietary PKI<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.intro.ldap">¶</a></span></h3></div></div></div><a class="indexterm" name="id593331"></a><p>
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 <span class="quote">“<span class="quote">official</span>”</span> or commercial PKI.
</p></div></div><div class="sect1" title="16.2. YaST Modules for CA Management"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.yast_ca.module"></a>16.2. YaST Modules for CA Management<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module">¶</a></span></h2></div></div></div><a class="indexterm" name="id593365"></a><p>
YaST provides two modules for basic CA management. The primary
management tasks with these modules are explained here.
</p><div class="sect2" title="16.2.1. Creating a Root CA"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.module.rootca"></a>16.2.1. Creating a Root CA<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module.rootca">¶</a></span></h3></div></div></div><a class="indexterm" name="id593389"></a><p>
The first step when setting up a PKI is to
create a root CA. Do the following:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Start YaST and go to <span class="guimenu">Security and
Users</span>+<span class="guimenu">CA Management</span>.
</p></li><li><p>
Click <span class="guimenu">Create Root CA</span>.
</p></li><li><p>
Enter the basic data for the CA in the first dialog, shown in
<a class="xref" href="cha.security.yast_ca.html#fig.yast.ca.ca_basic" title="Figure 16.1. YaST CA Module—Basic Data for a Root CA">Figure 16.1</a>.
The text fields have the following meanings:
</p><div class="figure"><a name="fig.yast.ca.ca_basic"></a><p class="title"><b>Figure 16.1. YaST CA Module—Basic Data for a Root CA</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast.ca.ca_basic">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_ca_basic.png" width="100%" alt="YaST CA Module—Basic Data for a Root CA"></td></tr></table></div></div></div><br class="figure-break"><div class="variablelist"><dl><dt><span class="term"><span class="guimenu">CA Name</span>
</span></dt><dd><p>
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.
</p></dd><dt><span class="term"><span class="guimenu">Common Name</span>
</span></dt><dd><p>
Enter the name for use in referring to the CA.
</p></dd><dt><span class="term"><span class="guimenu">E-Mail Addresses</span>
</span></dt><dd><p>
Several e-mail addresses can be entered that can be seen by the CA
user. This can be helpful for inquiries.
</p></dd><dt><span class="term"><span class="guimenu">Country</span>
</span></dt><dd><p>
Select the country where the CA is operated.
</p></dd><dt><span class="term"><span class="guimenu">Organisation</span>, <span class="guimenu">Organisational Unit</span>,
<span class="guimenu">Locality</span>, <span class="guimenu">State</span>
</span></dt><dd><p>
Optional values
</p></dd></dl></div><p>
Proceed with <span class="guimenu">Next</span>.
</p></li><li><p>
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 fields have the following meaning:
</p><div class="variablelist"><dl><dt><span class="term"><span class="guimenu">Key Length</span>
</span></dt><dd><p>
<span class="guimenu">Key Length</span> 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.
</p></dd><dt><span class="term"><span class="guimenu">Valid Period (days)</span>
</span></dt><dd><p>
The <span class="guimenu">Valid Period</span> 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.
</p></dd></dl></div><p>
Clicking <span class="guimenu">Advanced Options</span> opens a dialog for
setting different attributes from the X.509 extensions
(<a class="xref" href="cha.security.yast_ca.html#fig.yast.ca.extensions" title="Figure 16.4. YaST CA Module—Extended Settings">Figure 16.4, “YaST CA Module—Extended Settings”</a>). These values have rational
default settings and should only be changed if you are really sure of
what you are doing. Proceed with <span class="guimenu">Next</span>.
</p></li><li><p>
Review the summary. YaST displays the current settings for
confirmation. Click <span class="guimenu">Create</span>. The root CA is created
then appears in the overview.
</p></li></ol></div><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
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.
</p></td></tr></table></div></div><div class="sect2" title="16.2.2. Changing Password"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.module.changepw"></a>16.2.2. Changing Password<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module.changepw">¶</a></span></h3></div></div></div><p>
If you need to change your password for your CA, proceed as follows:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Start YaST and open the CA module.
</p></li><li><p>
Select the required root CA and click <span class="guimenu">Enter CA</span>.
</p></li><li><p>
Enter the password if you entered a CA the first time. YaST displays
the CA key information in the <span class="guimenu">Description</span> tab (see
<a class="xref" href="cha.security.yast_ca.html#fig.yast.ca.usage" title="Figure 16.2. YaST CA Module—Using a CA">Figure 16.2</a>).
</p></li><li><p>
Click <span class="guimenu">Advanced</span> and select <span class="guimenu">Change CA
Password</span>. A dialog box opens.
</p></li><li><p>
Enter the old and the new password.
</p></li><li><p>
Finish with <span class="guimenu">OK</span>
</p></li></ol></div></div><div class="sect2" title="16.2.3. Creating or Revoking a Sub-CA"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.module.subca"></a>16.2.3. Creating or Revoking a Sub-CA<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module.subca">¶</a></span></h3></div></div></div><a class="indexterm" name="id593837"></a><p>
A sub-CA is created in exactly the same way as a root CA.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
The validity period for a sub-CA must be fully within the validity
period of the <span class="quote">“<span class="quote">parent</span>”</span> CA. A sub-CA is always created
after the <span class="quote">“<span class="quote">parent</span>”</span> CA, therefore, the default value leads
to an error message. To avoid this, enter a permissible value for the
period of validity.
</p></td></tr></table></div><p>
Do the following:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Start YaST and open the CA module.
</p></li><li><p>
Select the required root CA and click <span class="guimenu">Enter CA</span>.
</p></li><li><p>
Enter the password if you are entering a CA for the first time. YaST
displays the CA key information in the tab
<span class="guimenu">Description</span> (see
<a class="xref" href="cha.security.yast_ca.html#fig.yast.ca.usage" title="Figure 16.2. YaST CA Module—Using a CA">Figure 16.2</a>).
</p><div class="figure"><a name="fig.yast.ca.usage"></a><p class="title"><b>Figure 16.2. YaST CA Module—Using a CA</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast.ca.usage">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_ca_usage.png" width="100%" alt="YaST CA Module—Using a CA"></td></tr></table></div></div></div><br class="figure-break"></li><li><p>
Click <span class="guimenu">Advanced</span> and select <span class="guimenu">Create
SubCA</span>. This opens the same dialog as for creating a root CA.
</p></li><li><p>
Proceed as described in
<a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.rootca" title="16.2.1. Creating a Root CA">Section 16.2.1, “Creating a Root CA”</a>.
</p><p>
It is possible to use one password for all your CAs. Enable
<span class="guimenu">Use CA Password as Certificate Password</span> to give
your sub-CAs the same password as your root CA. This helps to reduce
the amount of passwords for your CAs.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note: Check your Valid Period"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left">Check your Valid Period</th></tr><tr><td colspan="2" align="left" valign="top"><p>
Take into account that the valid period must be lower than the valid
period in the root CA.
</p></td></tr></table></div></li><li><p>
Select the <span class="guimenu">Certificates</span> tab. Reset compromised or
otherwise unwanted sub-CAs here, using <span class="guimenu">Revoke</span>.
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
<a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.crl" title="16.2.6. Creating CRLs">Section 16.2.6, “Creating CRLs”</a>.
</p></li><li><p>
Finish with <span class="guimenu">OK</span>
</p></li></ol></div></div><div class="sect2" title="16.2.4. Creating or Revoking User Certificates"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.module.clientserver"></a>16.2.4. Creating or Revoking User Certificates<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module.clientserver">¶</a></span></h3></div></div></div><a class="indexterm" name="id594071"></a><p>
Creating client and server certificates is very similar to creating CAs
in <a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.rootca" title="16.2.1. Creating a Root CA">Section 16.2.1, “Creating a Root CA”</a>. 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 hostname of the server must be entered in the
<span class="guimenu">Common Name</span> field. The default validity period for
certificates is 365 days.
</p><p>
To create client and server certificates, do the following:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Start YaST and open the CA module.
</p></li><li><p>
Select the required root CA and click <span class="guimenu">Enter CA</span>.
</p></li><li><p>
Enter the password if you are entering a CA for the first time. YaST
displays the CA key information in the <span class="guimenu">Description</span>
tab.
</p></li><li><p>
Click <span class="guimenu">Certificates</span> (see
<a class="xref" href="cha.security.yast_ca.html#fig.yast.ca.cert" title="Figure 16.3. Certificates of a CA">Figure 16.3</a>).
</p><div class="figure"><a name="fig.yast.ca.cert"></a><p class="title"><b>Figure 16.3. Certificates of a CA</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast.ca.cert">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_ca_cert.png" width="100%" alt="Certificates of a CA"></td></tr></table></div></div></div><br class="figure-break"></li><li><p>
Click <span class="guimenu">Add</span>+<span class="guimenu">Add Server
Certificate</span> and create a server certificate.
</p></li><li><p>
Click <span class="guimenu">Add</span>+<span class="guimenu">Add Client
Certificate</span> and create a client certificate.
Do not forget to enter an e-mail address.
</p></li><li><p>
Finish with <span class="guimenu">OK</span>
</p></li></ol></div><p>
To revoke compromised or otherwise unwanted certificates, do the
following:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Start YaST and open the CA module.
</p></li><li><p>
Select the required root CA and click <span class="guimenu">Enter CA</span>.
</p></li><li><p>
Enter the password if you are entering a CA for the first time. YaST
displays the CA key information in the <span class="guimenu">Description</span>
tab.
</p></li><li><p>
Click <span class="guimenu">Certificates</span> (see
<a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.subca" title="16.2.3. Creating or Revoking a Sub-CA">Section 16.2.3, “Creating or Revoking a Sub-CA”</a>.)
</p></li><li><p>
Select the certificate to revoke and click <span class="guimenu">Revoke</span>.
</p></li><li><p>
Choose a reason to revoke this certificate
</p></li><li><p>
Finish with <span class="guimenu">OK</span>.
</p></li></ol></div><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
Revocation alone is not enough to deactivate a certificate. Also
publish revoked certificates in a CRL.
<a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.crl" title="16.2.6. Creating CRLs">Section 16.2.6, “Creating CRLs”</a> explains how to
create CRLs. Revoked certificates can be completely removed after
publication in a CRL with <span class="guimenu">Delete</span>.
</p></td></tr></table></div></div><div class="sect2" title="16.2.5. Changing Default Values"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.module.defaults"></a>16.2.5. Changing Default Values<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module.defaults">¶</a></span></h3></div></div></div><a class="indexterm" name="id594399"></a><p>
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.
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Start YaST and open the CA module.
</p></li><li><p>
Enter the required root CA, as described in
<a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.subca" title="16.2.3. Creating or Revoking a Sub-CA">Section 16.2.3, “Creating or Revoking a Sub-CA”</a>.
</p></li><li><p>
Click <span class="guimenu">Advanced</span>+<span class="guimenu">Edit
Defaults</span>.
</p></li><li><p>
Choose the type the settings to change. The dialog for changing the
defaults, shown in <a class="xref" href="cha.security.yast_ca.html#fig.yast.ca.extensions" title="Figure 16.4. YaST CA Module—Extended Settings">Figure 16.4, “YaST CA Module—Extended Settings”</a>,
then opens.
</p><div class="figure"><a name="fig.yast.ca.extensions"></a><p class="title"><b>Figure 16.4. YaST CA Module—Extended Settings</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast.ca.extensions">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_ca_extensions.png" width="100%" alt="YaST CA Module—Extended Settings"></td></tr></table></div></div></div><br class="figure-break"></li><li><p>
Change the associated value on the right side and set or delete the
critical setting with <span class="guimenu">critical</span>.
</p></li><li><p>
Click <span class="guimenu">Next</span> to see a short summary.
</p></li><li><p>
Finish your changes with <span class="guimenu">Save</span>.
</p></li></ol></div><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
All changes to the defaults only affect objects created after this
point. Already-existing CAs and certificates remain unchanged.
</p></td></tr></table></div></div><div class="sect2" title="16.2.6. Creating CRLs"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.module.crl"></a>16.2.6. Creating CRLs<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module.crl">¶</a></span></h3></div></div></div><a class="indexterm" name="id594589"></a><p>
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 <a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.subca" title="16.2.3. Creating or Revoking a Sub-CA">Section 16.2.3, “Creating or Revoking a Sub-CA”</a>
(for sub-CAs) and
<a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.clientserver" title="16.2.4. Creating or Revoking User Certificates">Section 16.2.4, “Creating or Revoking User Certificates”</a> (for
user certificates). After this, a CRL must be created and published with
this information.
</p><p>
The system maintains only one CRL for each CA. To create or update this
CRL, do the following:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Start YaST and open the CA module.
</p></li><li><p>
Enter the required CA, as described in
<a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.subca" title="16.2.3. Creating or Revoking a Sub-CA">Section 16.2.3, “Creating or Revoking a Sub-CA”</a>.
</p></li><li><p>
Click <span class="guimenu">CRL</span>. The dialog that opens displays a summary
of the last CRL of this CA.
</p></li><li><p>
Create a new CRL with <span class="guimenu">Generate CRL</span> if you have
revoked new sub-CAs or certificates since its creation.
</p></li><li><p>
Specify the period of validity for the new CRL (default: 30 days).
</p></li><li><p>
Click <span class="guimenu">OK</span> to create and display the CRL. Afterwards,
you must publish this CRL.
</p></li></ol></div><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
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.
</p></td></tr></table></div></div><div class="sect2" title="16.2.7. Exporting CA Objects to LDAP"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.module.exportldap"></a>16.2.7. Exporting CA Objects to LDAP<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module.exportldap">¶</a></span></h3></div></div></div><a class="indexterm" name="id594723"></a><p>
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
<a class="xref" href="cha.security.yast_ca.html#tab.yast.ca.ldap.password" title="Table 16.3. Passwords during LDAP Export">Table 16.3, “Passwords during LDAP Export”</a>).
</p><div class="table"><a name="tab.yast.ca.ldap.password"></a><p class="title"><b>Table 16.3. Passwords during LDAP Export</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#tab.yast.ca.ldap.password">¶</a></span></p><div class="table-contents"><table summary="Passwords during LDAP Export" border="1"><colgroup><col><col></colgroup><thead><tr><th>
<p>
Password
</p>
</th><th>
<p>
Meaning
</p>
</th></tr></thead><tbody><tr><td>
<p>
LDAP Password
</p>
</td><td>
<p>
Authorizes the user to make entries in the LDAP tree.
</p>
</td></tr><tr><td>
<p>
Certificate Password
</p>
</td><td>
<p>
Authorizes the user to export the certificate.
</p>
</td></tr><tr><td>
<p>
New Certificate Password
</p>
</td><td>
<p>
The PKCS12 format is used during LDAP export. This format forces
the assignment of a new password for the exported certificate.
</p>
</td></tr></tbody></table></div></div><br class="table-break"><p>
Certificates, CAs, and CRLs can be exported to LDAP.
</p><div class="variablelist"><dl><dt><span class="term">Exporting a CA to LDAP</span></dt><dd><p>
To export a CA, enter the CA as described in
<a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.subca" title="16.2.3. Creating or Revoking a Sub-CA">Section 16.2.3, “Creating or Revoking a Sub-CA”</a>. Select
<span class="guimenu">Extended</span>+<span class="guimenu">Export to
LDAP</span> 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 <span class="quote">“<span class="quote">caCertificate</span>”</span>.
</p></dd><dt><span class="term">Exporting a Certificate to LDAP</span></dt><dd><p>
Enter the CA containing the certificate to export then select
<span class="guimenu">Certificates</span>. Select the required certificate from
the certificate list in the upper part of the dialog and select
<span class="guimenu">Export</span>+<span class="guimenu">Export to
LDAP</span>. 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
<span class="quote">“<span class="quote">userCertificate</span>”</span> (PEM format) and
<span class="quote">“<span class="quote">userPKCS12</span>”</span> (PKCS12 format).
</p></dd><dt><span class="term">Exporting a CRL to LDAP</span></dt><dd><p>
Enter the CA containing the CRL to export and select
<span class="guimenu">CRL</span>. If desired, create a new CRL and click
<span class="guimenu">Export</span>. 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
<span class="guimenu">Export to LDAP</span> and enter the respective LDAP data.
To do this at regular intervals, select the <span class="guimenu">Repeated
Recreation and Export</span> radio button and change the interval,
if appropriate.
</p></dd></dl></div></div><div class="sect2" title="16.2.8. Exporting CA Objects as a File"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.module.exportfile"></a>16.2.8. Exporting CA Objects as a File<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module.exportfile">¶</a></span></h3></div></div></div><a class="indexterm" name="id594977"></a><p>
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.
</p><p>
Export a file in the same way for certificates, CAs as with LDAP,
described in
<a class="xref" href="cha.security.yast_ca.html#sec.security.yast_ca.module.exportldap" title="16.2.7. Exporting CA Objects to LDAP">Section 16.2.7, “Exporting CA Objects to LDAP”</a>, except
you should select <span class="guimenu">Export as File</span> instead of
<span class="guimenu">Export to LDAP</span>. This then takes you to a dialog for
selecting the required output format and entering the password and
filename. The certificate is stored at the required location after
clicking <span class="guimenu">OK</span>.
</p><p>
For CRLs click <span class="guimenu">Export</span>, select <span class="guimenu">Export to
file</span>, choose the export format (PEM or DER) and enter the
path. Proceed with <span class="guimenu">OK</span> to save it to the respective
location.
</p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
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 USB
stick. The <code class="filename">/media</code> directory generally holds any
type of drive except the hard drive of your system.
</p></td></tr></table></div></div><div class="sect2" title="16.2.9. Importing Common Server Certificates"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.yast_ca.module.floppyimport"></a>16.2.9. Importing Common Server Certificates<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.yast_ca.module.floppyimport">¶</a></span></h3></div></div></div><a class="indexterm" name="id595060"></a><p>
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 <span class="emphasis"><em>common server certificate</em></span>. Do this
during installation or at a later point with YaST.
</p><div class="note"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Note"><tr class="head"><td width="32"><img alt="[Note]" src="admon/note.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
You need one of the PKCS12 formats to import your certificate
successfully.
</p></td></tr></table></div><p>
The general server certificate is stored in
<span class="command"><strong>/etc/ssl/servercerts</strong></span> 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.
</p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left"></th></tr><tr><td colspan="2" align="left" valign="top"><p>
If you select <span class="guimenu">Import</span> here, you can select the source
in the file system. This option can also be used to import certificates
from a transport medium, such as a USB stick.
</p></td></tr></table></div><p>
To import a common server certificate, do the following:
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Start YaST and open <span class="guimenu">Common Server Certificate</span>
under <span class="guimenu">Security and Users</span>
</p></li><li><p>
View the data for the current certificate in the description field
after YaST has been started.
</p></li><li><p>
Select <span class="guimenu">Import</span> and the certificate file.
</p></li><li><p>
Enter the password and click <span class="guimenu">Next</span>. The certificate
is imported then displayed in the description field.
</p></li><li><p>
Close YaST with <span class="guimenu">Finish</span>.
</p></li></ol></div></div></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.network_security.html">Network Security</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 15. Configuring VPN Server" href="cha.security.vpnserver.html"><span>◀</span></a> </strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018