The following sections outline how OES lets you automate certificate management for OES and all HTTPS services:
By default, HTTPS services on SLES 11 SP4 are configured to use two files that are located in /etc/ssl/servercerts and are protected so that only root and some specific groups can read them:
serverkey.pem: This contains the server’s raw private key.
servercert.pem: This contains the server’s certificates.
OES services, such as Apache, OpenWBEM, and Novell Remote Manager, are also configured to use these certificates.
OES enhances certificate management as follows:
As you install eDirectory and OES, by default all HTTPS services are configured to use eDirectory certificates. This means that eDirectory is established as the Certificate Authority for the tree you are installing into, and it will generate keys and certificates for the server and replace the installed SLES certificates with the eDirectory certificates.
Key and certificate files are installed in the following locations:
Table 23-1 File Locations
|
Location |
Details |
|---|---|
|
/etc/ssl/certs |
This is the default location of trusted root certificates for clients on the server. Most of the applications on the server are configured to use this directory. For example, the LDAP client uses one or more of the trusted certificates in this directory when establishing a secure LDAP connection. The OES installation copies the eDirectory tree CA’s certificate (eDirCACert.pem) here, thereby establishing the CA as a trusted root. Everyone (other) has rights to read the contents of this directory. |
|
/etc/ssl/servercerts |
The standard location for the server’s raw private key (serverkey.pem) and certificates (servercert.pem). Applications on the server, including OES applications, are configured to point to the files in this directory. Only root and some specific groups can read the files in this directory. |
|
/etc/opt/novell/certs |
This directory contains the eDirectory CA certificate in both DER and PEM formats for use by applications that need them. The files are named SSCert.der and SSCert.pem, respectively. For example, when PKI Health Check runs, it installs the CA certificate in the Java Keystore in DER format if the certificate needs replacing. |
The component that generates eDirectory keys and certificates is the NetIQ Certificate Server.
This certificate server provides public key cryptography services that are natively integrated into NetIQ eDirectory. You can use the server to mint, issue, and manage both user and server certificates to protect confidential data transmissions over public communications channels such as the Internet.
For complete information on the NetIQ Certificate Server, see the NetIQ Certificate Server Administration Guide.
When activated, Server Self-Provisioning lets server objects in eDirectory create their own certificates. You must activate this option if you want PKI Health Check to automatically maintain your server certificates.
For more information on this feature, see X.509 Certificate Self-Provisioning
in the NetIQ Certificate Server Administration Guide.
The PKI health check runs whenever the certificate server starts.
If you have enabled Server Self-Provisioning, the health check routine automatically replaces server certificates when any of the following are detected:
The certificates don’t exist.
The certificates have expired.
The certificates are about to expire.
The IP or DNS information on the certificates doesn’t match the server configuration.
The Certificate Authority (CA) that issued the certificate is different from the CA currently configured.
For more information on this feature, see PKI Health Check
in the NetIQ Certificate Server Administration Guide.
The Organizational CA can be configured to act as a sub-CA. This lets multiple trees share a common root certificate. The root certificate can be stored in a physically protected tree. It can also integrate with a third-party PKI. For more information, see Subordinate Certificate Authority
in the NetIQ Certificate Server Administration Guide.