Novell Certificate Server consists of the PKI server component, a snap-in module to ConsoleOne, and a plug-in module to Novell iManager. ConsoleOne and Novell iManager 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 will manage it using:
Through ConsoleOne and Novell iManager, you can perform the following tasks:
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.
During the installation, you can elect to create a Server Certificate object. 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 created 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 filed when viewing the Server Certificate object in ConsoleOne.
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.
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 the Security tab of the user's property page and is signed by the Organizational CA. Certificates created by other CAs can only be imported after having been created.
Multiple certificates can be stored on the user's object.
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.
You must create the Trusted Root Container in the Security 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 will 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.
The CA administrator can use the Organizational CA to sign certificates for users and servers that reside in other trees. Such certificates are requested using a 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 using the Issue Certificate tool in ConsoleOne or Novell 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. This feature checks each certificate in the certificate chain back to the trusted root certificate and returns a status of Valid or Invalid.
Certificates are considered valid if they pass a pre-defined 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 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. The Trusted Root object must be in a Trusted Root Container named Trusted Roots and it must be located in the Security container.
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.
You can choose to import a key rather than create a new one at the time a Server 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 or to move the Organizational CA from one server to another.
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. Likewise, 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 will not be able to create new server certificates.
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 will add 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 ConsoleOne or Novell iManager to create a new one. If there are server certificates that belong to this server, you will need to link them up to the SAS service object manually by using the Other tab from ConsoleOne.
Novell International Cryptographic Infrastructure (NICI) is the underlying cryptographic infrastructure that provides the cryptography for Novell Certificate Server, Novell Modular Authentication Service, 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. The proper version of NICI might be provided when Novell Certificate Server is bundled with another product, such as NetWare or eDirectory, or you might need to download a newer version of NICI from Novell's Software Download Web site. When Novell Certificate Server is bundled with other products, you might be required to install NICI manually, or NICI might be automatically installed. Refer to the product's installation guide for more information.
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 Setting Up Novell Certificate Server .
For information about administering Novell Certificate Server, see Managing Novell Certificate Server .
For the latest online documentation for this and other Novell products, see the Product Documentation Web site.
For additional information about this and other Novell security products and technologies, see the Novell Security Web site.