This section describes the components of Novell Certificate Server.
Novell Certificate Server consists of the PKI server component, a plug-in module to iManager and a snap-in module to ConsoleOne. iManager and ConsoleOne are the administration points for Novell Certificate Server.
Novell Certificate Server allows you to request, manage, and store public key certificates and their associated key pairs in the eDirectory tree, and to establish an Organizational Certificate Authority that is specific to your eDirectory tree and your organization.
Novell Certificate Server derives all supported cryptography and signature algorithms, as well as supported key sizes, from Novell International Cryptographic Infrastructure (NICI). Therefore, a single version of Novell Certificate Server can be used in installations throughout the world.
After installing Novell Certificate Server, you manage it by using:
ConsoleOne running on a client
NOTE:ConsoleOne is an older management tool. You cannot manage some of the newer functionality of Novell Certificate Server through ConsoleOne. We recommend that you use iManager to manage Novell Certificate Server.
This guide provides information only on how to administer Novell Certificate Server using iManager.
You can use iManager to perform the following tasks:
eDirectory 8.8 supports key sizes up to 4096 bits. However, in order to use key sizes larger than 2048 bits, you must upgrade all of the servers in your eDirectory Tree to eDirectory 8.8 and upgrade all clients to NICI 2.7.0 or later. For more information on upgrading NICI, see the Novell International Cryptographic Infrastructure 2.7 Administration Guide. Also, if you plan to use 4 KB certificates with your applications, the applications must support 4 KB keys or they do not work properly.
Note that 4 KB keys take significantly more time to generate and use.
Certificate Server lets you select the key size as part of any certificate creation procedure.
During the installation, you can elect to create an Organizational Certificate Authority (CA) if one does not already exist in the eDirectory tree. You can also create or re‑create the Organizational CA after the installation is completed.
The Organizational CA object contains the public key, private key, certificate, certificate chain, and other configuration information for the Organizational CA. The Organizational CA object resides in the Security container in eDirectory.
After a server is configured to provide the certificate authority service, it performs that service for the entire eDirectory tree.
For more information on creating an Organizational CA, see Section 3.2, Creating an Organizational Certificate Authority Object.
The Certificate Server installation creates default Server Certificate objects.
SSL CertificateIP - server_name
SSL CertificateDNS - server_name
A certificate for each IP address configured on the server (IPAGxxx.xxx.xxx.xxx - server_name)
A certificate for each DNS name configured on the server (DNSAGwww.example.com - server_name)
You can create other Server Certificate objects after the installation is completed.
The Server Certificate object contains the public key, private key, certificate, and certificate chain that enables SSL security services for server applications. Server Certificate objects can be signed by either the Organizational CA or by an external CA.
A server can have many Server Certificate objects associated with it. Any cryptography-enabled applications running on a particular server can be configured to use any one of the Server Certificate objects for that server. Multiple applications running on a given server can use the same Server Certificate object; however, a Server Certificate object cannot be shared between servers.
You can create Server Certificate objects only in the container where the server resides. If the Server object is moved, all Server Certificate objects belonging to that server must be moved as well. You should not rename a Server Certificate object. You can determine which Server Certificate objects belong to a server by searching for the server's name in the Server Certificate Object Name or by looking at the host server field when viewing the Server Certificate object in iManager.
NOTE:The key pair stored in the Server Certificate object is referenced by the name you enter when the key pair is created. The key pair name is not the name of the Server Certificate object. When configuring cryptography-enabled applications to use key pairs, you reference those keys by their key pair name, not by the Server Certificate object name.
If the default Server Certificate objects become corrupted or invalid, use the Create Default Certificates Wizard to replace the old default certificates. For information on how to access the Create Default Certificates Wizard, see Section 4.2.2, Creating Default Server Certificate Objects.
Users have access to their own user certificates and private keys, which can be used for authentication, data encryption/decryption, digital signing, and secure e-mail. One of the most common uses is sending and receiving digitally signed and encrypted e-mail using the S/MIME standard.
Generally, only the CA administrator has sufficient rights to create user certificates. However, only the user has rights to export or download the private key from eDirectory. Any user can export any other user's public key certificate.
The user certificate is created from thetab of the user's property page and is signed by the Organizational CA. Certificates and private keys created by other CAs can be imported after being created.
Multiple certificates can be stored on the user's object.
For more information on creating a user certificate, see Section 3.6.1, Creating a User Certificate.
A trusted root provides the basis for trust in public key cryptography. Trusted roots are used to validate certificates signed by other CAs. Trusted roots enable security for SSL, secure e-mail, and certificate-based authentication.
A Trusted Root Container is an eDirectory object that contains Trusted Root objects.
The default Trusted Root Container is CN=trusted roots.CN=security.
For more information on creating a Trusted Root Container, see Section 3.6.2, Creating a Trusted Root Container.
A Trusted Root object is an eDirectory object that contains a CA's Trusted Root certificate that is known to be authentic and valid. The Trusted Root Certificate can be exported and used as needed. Applications that are configured to use the Trusted Root Certificate consider a certificate valid if it has been signed by one of the CAs in the Trusted Root Container.
The Trusted Root object must reside in a Trusted Root Container.
For more information on creating a Trusted Root object see Section 3.6.3, Creating a Trusted Root Object.
The CA administrator can use the Organizational CA to sign certificates for users and servers outside of eDirectory. Such certificates are requested using a PKCS#10 Certificate Signing Request (CSR) provided to the CA administrator in an out-of-band fashion.
Given a CSR, the CA administrator can issue the certificate by using the Issue Certificate tool in iManager. The resulting certificate is not stored in an object in eDirectory. It must be returned to the requestor in an out-of-band fashion.
Novell Certificate Server allows you to check the validity of any certificate in the eDirectory tree. The certificate validation process checks each certificate in the certificate chain back to the trusted root certificate and returns a status of Valid or Invalid.
To check the validity of certificates for the Organizational CA, see Section 4.1.10, Validating the Organizational CA's Certificates.
To check the validity of certificates for a server, see Section 4.2.12, Validating a Server Certificate.
To check the validity of certificates for a user, see Section 4.3.7, Validating a User Certificate.
To check the validity of certificates for a Trusted Root, see Section 4.6.5, Validating a Trusted Root Object.
Certificates are considered valid if they pass a predefined set of criteria including whether the current time is within the validity period of the certificate, whether it has not been revoked, and whether it has been signed by a CA that is trusted.
When validating user certificates or intermediate CA certificates in CN=trusted roots.CN=security signed by external CAs, the external CA’s certificate must be stored in a Trusted Root object in order for the certificate validation to be successful.
A Certificate Revocation List (CRL) is a published list of revoked certificates and the reason the certificates were revoked.
Novell Certificate Server provides a system for managing CRLs. This is an optional system, but it must be implemented if you want to be able to revoke certificates created by the Organizational CA. For more information on managing CRLs, see Section 4.7, Certificate Revocation List (CRL) Tasks.
During the Certificate Server installation, a CRL container is created if the user has the appropriate rights to create it. If not, the CRL container can be created manually by someone with the appropriate rights after the installation is completed.
A CRL Configuration object can be created in the CRL container. The object contains the configuration information for the CRL objects that are available in the eDirectory tree. Normally, you have only one CRL Configuration object in your tree. You might need multiple CRL Configuration objects if you are creating or rolling over a new Organizational CA, but only one CRL Configuration object can be used to create new certificates.
A CRL object, also known as a distribution point, can be created in any container in the eDirectory tree. However, Novell CRL objects usually reside in a CRL container. A CRL object is automatically created for you when you create a CRL Configuration object. The CRL object contains a CRL file, which contains the detailed CRL information. For a Novell CRL object, the CRL file is automatically created and updated whenever the server issues a new one. For other CRL objects, you must import a CRL file from a third-party CA.
Deleting a CRL Configuration object is possible, but it is not recommended. When a CRL Configuration object is deleted, the server quits creating the CRL files. If a CRL file already exists in the location specified in the CRL object, certificate validation continues to use it until it expires. After it expires, all certificates that have a CRL distribution point that references that CRL file fail validation.
If you delete a CRL object, it is re-created the next time the server generates the CRL file. If you delete a CRL object that you created using iManager and import it, then it is gone permanently and any certificates that reference it are considered invalid.
The general rule is to not delete a CRL container, CRL Configuration object, CRL object, or CRL file until one issue date after the last certificate that contains a related distribution point has expired.
User, server, and CA keys can be marked as exportable when they are created. If a key is exportable, it can be extracted and put in a file along with the associated certificate. The file is written in an industry standard format (PFX or PKCS #12), which allows it to be transported to other platforms. It is encrypted with a user-specified password to protect the private key.
Exporting private keys and certificates can be done to obtain a backup copy of the key, to move the key to a different server, or to share the key between servers.
For more information on exporting private keys and certificates, see Section 4.3.6, Exporting a User Certificate and Private Key.
You can choose to import a key rather than create a new one at the time a server certificate, a user certificate, or a CA object is created. The key and its associated certificates must be in PFX or PKCS #12 format.
You might choose to import a key rather than create a new one for a CA object to recover from a server failure, to move the Organizational CA from one server to another, or for a CA that is subordinate to another CA.
You might choose to import a user certificate or private key if it has been signed by a third-party CA.
You might choose to import a key rather than create a new one for a Server Certificate object to recover from a server failure, to move the key and certificate to another server, or to share the key and certificate with another server.
The SAS service object facilitates communication between a server and its server certificates. If you remove a server from an eDirectory tree, you also need to delete the SAS service object associated with that server. If you want to put the server back into the tree, you must create the SAS service object to go with that server. If you do not, you cannot create new server certificates.
The SAS service object is automatically created as part of the server health check. You should not need to create it manually.
You can create a new SAS service object only if there is not a properly named SAS service object in the same container as the server object. For example, for a server named WAKE, you will have a SAS service object named SAS Service - WAKE. The utility adds the DS pointers from the Server object to the SAS object, and from the SAS object to the Server object, as well as set up the correct ACL entries on the SAS service object.
If a SAS service object already exists with the proper name, you cannot create a new one. The old SAS service object’s DS pointers might be wrong or missing, or the ACLs might not be correct. In this case, you can delete the corrupt SAS service object and use iManager to create a new one. If there are server certificates that belong to this server, you need to link them to the SAS service object manually by using thetab.
For more information on creating a SAS service object, see Section 3.6.4, Creating an SAS Service Object.
Novell International Cryptographic Infrastructure (NICI) is the underlying cryptographic infrastructure that provides the cryptography for Novell Certificate Server, Novell Modular Authentication Services (NMAS™), and other applications.
NICI must be installed on the server in order for Novell Certificate Server to work properly. NICI does not ship with Novell Certificate Server. In most cases NICI is provided and installed when Novell Certificate Server is bundled with another product, such as Open Enterprise Server (OES) or eDirectory. If you need a newer version of NICI, you can download it from the Novell Downloads Web site.
For instructions on installing Novell Certificate Server when it is included with another Novell product, see the installation guide for that product.
For instructions on setting up Novell Certificate Server, see Section 3.0, Setting Up Novell Certificate Server.
For information about administering Novell Certificate Server, see Section 4.0, Managing Novell Certificate Server.
For the latest online documentation for this and other Novell products, see the NetIQ Documentation Web site.
For additional information about this and other security products and technologies, see the NetIQ Web site.