25.2 NetIQ Certificate Server Components

This section describes the components of NetIQ Certificate Server.

25.2.1 NetIQ Certificate Server

NetIQ Certificate Server consists of the PKI server component and a plug-in module to iManager. iManager is the administration interface for Certificate Server.

Certificate Server allows you to do the following tasks:

  • Establish an Organizational Certificate Authority that is specific to your eDirectory tree and your organization.

  • Request, manage, and store public key certificates and their associated private keys in the eDirectory tree.

Using 8192 Bit RSA Keys in Certificates

Using the Certificate Server, you can select the key size as part of any certificate creation procedure. eDirectory supports key sizes up to 8192 bits. If you plan to use X.509 certificates with a 8192 bit RSA public key for your applications, the applications must support 8192 bit RSA keys. Otherwise, your applications may not function as expected.

IMPORTANT:Using an X.509 certificate with 8K bit RSA public keys for establishing TLS connection impacts the performance of your eDirectory servers. NetIQ does not recommend configuring eDirectory servers to use RSA certificates with 8K bit keys because TLS session establishment can be computation intensive for the servers and it may cause significant system slowdown when TLS sessions are established concurrently.

Ensure that you upgrade all the servers in your eDirectory tree to 9.1 before creating a CA certificate with a 8192 bits RSA public key.

NOTE:Ensure that you are using eDirectory 9.1, iManager 3.1 and eDirectory 9.1 PKI Plug-in before configuring a server certificate with 8192 bit RSA public key.

Using ECDSA Certificates

The Certificate Server supports the use and management of Elliptic Curve Digital Signature Algorithm (ECDSA) certificates and keys in the same way as it supports the RSA certificates.

An ECDSA key pair whose security is comparable to an RSA key is significantly smaller than the RSA key and significantly improves the performance when used in establishing TLS connections. ECDSA makes use of elliptic curve cryptography (ECC). ECC generates keys through elliptic curves. The technology can be used in conjunction with most public key encryption methods, such as RSA and Diffie-Hellman. Using ECC-based signatures with digital certificates provide added size and performance advantages.

eDirectory supports ECDSA certificates with keys with the following curves:

  • P-256

  • P-384

  • P-521

In Suite B mode, the Certificate Server adheres to RFC 5759. This RFC specifies that every Suite B certificate and CRL must be signed using ECDSA with keys generated using either P-256 or P-384 curves.

The signing CA's key must be on P-256 or P-384 curve if the certificate contains a key on P-256 curve. If the certificate contains a key on P-384 curve, the signing CA's key must be on P-384 curve. Any certificate and CRL must be hashed using SHA-256 or SHA-384, matched to the size of the signing CA's key.

After installing NetIQ Certificate Server, you manage it by using iManager.

You can use iManager to perform the following tasks:

Create an Organizational Certificate Authority for Your Organization

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. If the tree has a subordinate CA certificate, and if you upgrade the server hosting subCA to eDirectory 9.1, ECDSA CA certificates are not generated. Administrator has to import a subordinate CA ECDSA certificate with the same subject name as the subordinate CA RSA certificate. If the server acting as a CA is on eDirectory 9.1, eDirectory creates the ECDSA certificates for the Organizational CA. eDirectory automatically creates ECDSA certificates for servers if the Organization CA has a ECDSA certificate.

For more information on creating an Organizational CA, see Creating an Organizational Certificate Authority Object.

Create a Server Certificate Object for Each Cryptography-Enabled Application

The Certificate Server installation creates default Server Certificate objects.

  • SSL CertificateDNS - server_name

  • A certificate for each IP address configured on the server (IP AG xxx.xxx.xxx.xxx - server_name)

  • A certificate for each DNS name configured on the server (DNS AG www.example.com - server_name)

  • SSL EC CertificateDNS - server_name

  • A certificate for each IP address configured on the server (IP EC AG xxx.xxx.xxx.xxx - server_name)

  • A certificate for each DNS name configured on the server (DNS EC AG www.example.com - server_name)

NOTE:eDirectory does not automatically create SSL CertificateIP. SSL CertificateDNS contains all the IPs listed in the Subject Alternative 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.

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 Creating Default Server Certificate Objects.

By default, eDirectory creates ECDSA certificates if the Organization CA has an ECDSA certificate.

Create a User Certificate

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 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 Creating a User Certificate.

Create a Trusted Root Container

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

Create a Trusted Root Object

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

Create Certificates For External Users and Servers

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.

Validate Certificates

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

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.

Manage Certificate Revocation Lists

A Certificate Revocation List (CRL) is a published list of revoked certificates and the reason the certificates were revoked.

NetIQ 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 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, NetIQ 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 NetIQ 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. When a server that holds Organization CA is upgraded to eDirectory 9.1, the upgrade process automatically creates CRL distribution points. Also, eDirectory provides separate CRL configuration objects for RSA and ECDSA certificates.

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.

Export Private Keys and Certificates

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 Exporting a User Certificate and Private Key.

Import Private Keys and Certificates

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.

Create an SAS Service Object

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 the Other tab.

For more information on creating a SAS service object, see Creating an SAS Service Object.

25.2.2 Novell International Cryptographic Infrastructure

Novell International Cryptographic Infrastructure (NICI) is the underlying cryptographic infrastructure that provides the cryptography for NetIQ Certificate Server, NetIQ Modular Authentication Services (NMAS), and other applications.

NICI must be installed on the server in order for NetIQ Certificate Server to work properly. NICI does not ship with NetIQ Certificate Server. In most cases NICI is provided and installed when NetIQ 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 NetIQ Downloads Web site.