25.3 Setting Up NetIQ Certificate Server

25.3.1 Deciding Which Type of Certificate Authority to Use

NetIQ Certificate Server allows you to create certificates for both servers and end users. Server certificates can be signed by either the Organizational CA or by an external or third-party CA. User certificates can be signed only by the Organizational CA; however, you can import user certificates signed by a third-party CA in PKCS#12 format.

During the Server Certificate object creation process, you are asked which type of certificate authority will sign the Server Certificate object.

The Organizational Certificate Authority is specific to your organization and uses an organizational-specific public key for signing operations. The private key is created when you create the Organizational Certificate Authority.

A third-party certificate authority is managed by a third party outside of the eDirectory tree. An example of a third party certificate authority is VeriSign.

Both types of certificate authorities can be used simultaneously. Using one type of certificate authority does not preclude the use of the other.

Benefits of Using an Organizational Certificate Authority Provided with NetIQ Certificate Server

  • Compatibility. The Organizational Certificate Authority is compatible with NetIQ or Novell applications such as LDAP services. Certificates issued by the Organizational CA are X.509 v3 compliant and can also be used by third-party applications.

  • certificate authorityCost savings. The Organizational Certificate Authority lets you create an unlimited number of public key certificates at no cost; obtaining a single public key certificate through an external Certificate Authority might cost a significant amount of money.

  • Component of a complete and compatible solution. By using the Organizational Certificate Authority, you can use the complete cryptographic system built into eDirectory without relying on any external services. In addition, NetIQ Certificate Server is compatible with a wide range of NetIQ or Novell products.

  • Certificate attribute and content control. An Organizational Certificate Authority is managed by the network administrator, who decides on public key certificate attributes such as certificate life span, key size, and signature algorithm.

  • Simplified management. The Organizational Certificate Authority performs a function similar to external certificate authorities but without the added cost and complexity.

Benefits of Using an External Certificate Authority

  • Liability. An external certificate authority might offer some liability protection if, through the fault of the certificate authority, your private key was exposed or your public key certificate was misrepresented.

  • Availability. An external certificate authority's certificate might be more widely available and more widely trusted by applications outside of eDirectory.

25.3.2 Creating an Organizational Certificate Authority Object

By default, the NetIQ Certificate Server installation process creates the Organizational Certificate Authority (CA) for you. You are prompted to specify an Organizational CA name. When you click Finish, the Organizational CA is created with the default parameters and placed in the Security container.

If you want more control over the creation of the Organizational CA, you can create the Organizational CA manually by using iManager. Also, if you delete the Organizational CA, you need to re‑create it.

During the creation process, you are prompted to name the Organizational Certificate Authority object and to choose a server to host the Organizational CA service (the server the Organizational CA service will run on). In determining the server to host the Organizational CA service, consider the following:

  • Select a server that is physically secure.

    Physical access to the CA server is an important part of the security of the system. If the CA server is compromised, all certificates issued by the CA are also compromised.

  • Select a server that is highly available, stable, and robust.

    If the CA service is not available, certificates cannot be created. This affects installation of new servers because certificates need to be created during install.

  • Select a server that only runs software you trust.

    Running unknown or questionable software might compromise the CA service.

  • Select a server that will not be removed from the tree.

    If the server is removed from the tree, you need to either re-create the CA object by using a backup you made before removing the CA, or you need to create a new CA. If you create a new CA, you might need to replace your existing server and user certificates.

  • Select a server that runs a protocol that is compatible with other servers in your tree.

    Examples are IP.

  • Create an Organization CA with ECDSA certificate.

To create the Organizational Certificate Authority object:

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Server > Configure Certificate Authority.

    If no Organizational Certificate Authority object exists, this opens the Create an Organizational Certificate Authority Object dialog box and the corresponding wizard that creates the object. Follow the prompts to create the object. For specific information on the dialog box or any of the wizard pages, click Help.

    NOTE:Ensure that the CRL file path which is specified here, is in respect with the eDirectory installation path.

  4. After you have finished creating the Certificate Authority, we recommend that you make a backup of the CA’s public/private key pair and store this in a safe and secure place. See Backing Up an Organizational CA.

NOTE:You can have only one Organizational CA for your eDirectory tree.

eDirectory allows the administrator to specify the RSA key size, Elliptic Curve and certificate to be used when the default server certificates are generated. These parameters can be specified using the following three attributes on the CA object:

  • ndspkiDefaultRSAKeySize: Specify the key size for the RSA server certificates. You can specify up to 8192 bit RSA encryption in this field.

    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.

  • ndspkiDefaultECCurve: Specify the curve for the EC limit for the server certificates. You can specify any one of the following EC:

    • P256

    • P384

    • P521

  • ndspkiDefaultCertificateLife: Specify the certificate life for the default server certificates. You can specify the server certificate life in years. For example, if you specify 4 in this field, your server certificate life will be set to 4 years. Certificate server ensures that the default server certificates have a minimum validity of 1 year and maximum validity does not exceed the CA’s expiry date.

    NOTE:

    • ndspkiDefaultCertificateLife attribute is only applicable for server certificates.

    • If you pass the old default values while configuring a new eDirectory server, the above mentioned parameters remain unset.

    • The above parameters do not affect the existing default certificates. While upgrading the eDirectory server to 9.2 after specifying these parameters on the CA, the existing default server certificates are not re-created.

If you specify these parameters while configuring a new eDirectory tree, the Organizational CA certificates are also created with these parameters. For more information, see the NetIQ eDirectory Installation Guide.

25.3.3 Subordinate Certificate Authority

NetIQ Certificate Server has added support for a Subordinate Certificate Authority. This feature allows the Organizational CA to be subordinate to either a third-party CA or to a CA in another eDirectory tree. You still can have only one Organizational CA in your eDirectory tree.

The following are some of the reasons to have a Subordinate CA:

  • Allows the Organizational CA to become part of an existing third-party PKI

  • Allows multiple trees to share a common PKI Trusted Root (or Trust Anchor)

  • Allows for greater security of the Root CA by having the CA reside on a more secure system

  • Provides less risk by having the Root CA reside in a tree that is more tightly managed (for example, in a tree protected from rogue-administrators/users)

Creating a Subordinate Certificate Authority

In order to create a Subordinate CA, you must first delete the existing Organizational CA (see Deleting the Organizational CA). You must already have a PKCS#12 file containing the public/private keys and the certificate chain for the Subordinate CA. You can either obtain this file directly from a third-party CA or use Creating PKCS#12 Files for a Subordinate CA to learn how to create one. In order to create the Subordinate CA, connect to the tree in iManager and use the Configure Certificate Authority task, using the Import creation method.

Creating PKCS#12 Files for a Subordinate CA

  1. Create a Server Certificate object (or KMO) and a PKCS#10 CSR with ECDSA and RSA keys.

    1. Launch iManager.

    2. On the Roles and Tasks menu, click NetIQ Certificate Server > Create Server Certificate.

    3. Select the server that will eventually host the CA, specify a certificate nickname, select the Custom creation method, then click Next.

    4. Select External Certificate Authority, then click Next.

    5. Select the algorithm and a key size and make sure that Allow Private Key to Be Exported is selected, then click Next.

      IMPORTANT:If you want to use both RSA and ECDSA certificates in your eDirectory environment, repeat this step for the certificate that you want to use. NetIQ recommends that you use a key size of 2048 bits for RSA and 384 bits for ECDSA.

    6. Click the Edit button to the right of the Subject name field and edit the Subject name to reflect the subordinate CA and tree, select the Signature algorithm (NetIQ recommends that you use a stronger algorithm than SHA-1), then click Next.

    7. Verify that the summary is correct, then click Finish.

    8. Click Save Certificate Signing Request, then follow the prompts to save the CSR to a file.

  2. Get the CSR signed to create a certificate.

    1. If the Subordinate CA is to be part of a third-party PKI, have the third-party CA create the certificate from the CSR.

      or

      If the Subordinate CA is to be signed by a CA in another eDirectory tree, continue with Step 2.b.

      NOTE:In case of ECDSA, the CSR can be signed only by ECDSA CA.

    2. Launch iManager.

    3. On the Roles and Tasks menu, click NetIQ Certificate Server > Issue Certificate.

    4. Select the file containing the CSR, then click Next.

    5. Select a key type of Certificate Authority, deselect Enable Extended Key Usage and click Next.

    6. Select the Certificate Authority Certificate type and then select either the Unspecified or a Specific Path length and click Next.

    7. Verify the subject name and edit it if necessary. Specify a validity period (5-10 years is recommended), then click Next.

    8. Select a format for the certificate, then click Next.

    9. Click Finish.

    10. Click Download the issued certificate, then follow the prompts to save the certificate.

  3. Acquire the CA certificates.

    1. If the Subordinate CA is to be part of a third-party PKI, acquire the CA certificates from the third party.

      or

      If the Subordinate CA is to signed by a CA in another eDirectory tree, continue with Step 3.b.

    2. Launch iManager.

    3. On the Roles and Tasks menu, click NetIQ Certificate Server > Configure Certificate Authority.

    4. Click the Certificates tab, then select Self-Signed Certificate.

    5. Click Export.

    6. Do not export the private key and select a format for the certificate, then click Next.

    7. Click Save the Exported Certificate to a File, then follow the prompts to save the certificate.

  4. Import the certificates into the Server Certificate object (or KMO).

    1. Launch iManager.

    2. On the Roles and Tasks menu, click NetIQ Certificate Access > Server Certificates.

    3. Select the server that will eventually host the CA.

    4. Select the Server Certificate object (or KMO) created in Step 1, then click Import.

    5. Select the two files containing the certificates acquired in Step 2 and Step 3, then click OK.

    IMPORTANT:If you want to use both RSA and ECDSA certificates in your eDirectory environment, repeat this step for the certificate that you want to use.

  5. Export the public/private keys to a PKCS#12 file.

    1. Continuing from Step 4.e, click Export, choose to include the private key, then click Next.

    2. Click Save the Exported Certificate to a File, then follow the prompts to save the PKCS#12 file.

    3. Make a copy of this file and store it in a secure place along with the password.

  6. (Optional) Delete the Server Certificate object (or KMO).

  7. Delete the Organizational CA. For more information, see Deleting the Organizational CA.

  8. Import the sub CA certificates and private keys from the PKCS#12 file. For more information, Restoring an Organizational CA.

25.3.4 Restrictions for Creating a Certificate Authority Object

eDirectory 9.0 and above supports both RSA and EC certificates for the CA. The following considerations apply for creating a CA object with RSA and EC certificates:

  • The subject name of RSA and EC certificates must be same.

  • RSA and EC CA must not be in a mixed mode. You can have RSA and EC CA either as a root CA or SubCA. For example, you cannot have RSA CA as a root CA and EC CA as a SubCA or vice versa.

  • eDirectory does not allow you to import self-signed CA certificates generated by a third party application outside of eDirectory.

25.3.5 Configuring the Certificate Authority in Suite B Mode

Before configuring the CA in the Suite B mode, ensure that the server where CA is hosted has NICI 3.0 installed and is configured to run Enhanced Background Authentication.

To configure the CA to operate in the Suite B mode, perform the following steps:

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

  3. On the Roles and Tasks menu, click NetIQ Certificate Server > Configure Certificate Authority.

  4. Select Enable Suite B Mode.

  5. Click OK.

When the CA is in Suite B mode, the Certificate Server does not allow you to create RSA certificates. For information about which ECDSA certificates are supported, see NetIQ Certificate Server Components.

If you add a server with an older version of eDirectory to an eDirectory 9.0 or above tree configured with Suite B, the Certificate Server does not create certificates for the server because the server does not have the Suite B capability. To enable the Suite B capability on these servers, you must upgrade them to eDirectory 9.0 or above.

25.3.6 Creating a Server Certificate Object

Server Certificate objects are created in the container that holds the server's eDirectory object. Depending on your needs, you might create a separate Server Certificate object for each cryptography-enabled application on the server, or you might create one Server Certificate object for all applications used on that server.

NOTE:The terms Server Certificate object and Key Material object (KMO) are synonymous. The schema name of the eDirectory object is NDSPKI:Key Material.

When you install Certificate Server, eDirectory automatically creates the Server Certificate object with the default parameters and places it in the container where the target server resides. If you ever need to overwrite or create new default certificates, you can use the Create Default Certificates Wizard. See Creating Default Server Certificate Objects.

If you want more control over the creation of the Server Certificate object, you can create the Server Certificate object manually. You can also create additional Server Certificate objects.

Manually Creating a Server Certificate Object

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Server > Create Server Certificate.

    This opens the Create a Server Certificate dialog box and the corresponding wizard that creates the Server Certificate object. Follow the prompts to create the object. For specific information on the dialog box or any of the wizard pages, click Help.

Hints for Creating Server Certificates

During the Server Certificate object creation process, you are prompted to name the key pair and choose the server that the key pair will be associated with. The Server Certificate object is generated by NetIQ Certificate Server, and its name is based on the key pair name that you choose.

If you choose the Custom creation method, you are also prompted to specify whether the Server Certificate object will be signed by your organization's Organizational Certificate Authority or by an external certificate authority. For information about making this decision, see Deciding Which Type of Certificate Authority to Use.

If you decide to use your organization's Organizational CA, the server that the Server Certificate object is associated with must be able to communicate with the server that hosts the Organizational CA, or it must be the same server. These servers must be running the same protocol (IP).

If you decide to use an external certificate authority to sign the certificate, the server that the Server Certificate object is associated with generates a certificate signing request that you need to submit to the external certificate authority.

After the certificate is signed and returned to you, you need to install it into the Server Certificate object, along with the trusted root for the external Certificate Authority.

After you have created the Server Certificate object, you can configure your applications to use it. (See Configuring Cryptography-Enabled Applications.) Keys are referenced in the application's configuration by the key pair name that you entered when you created the Server Certificate object.

25.3.7 Configuring Cryptography-Enabled Applications

After you have configured NetIQ Certificate Server, you must configure your individual cryptography-enabled applications so that they can use the custom certificates that you created. The configuration procedures are unique to the individual applications, so we recommend that you consult the application's documentation for specific instructions.

25.3.8 Additional Components to Set Up

NetIQ Certificate Server includes some additional components that can be set up to provide additional functionality.

Creating a User Certificate

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Server > Create User Certificate.

    This opens a wizard that helps you create the user certificate. Follow the prompts to create the object. For specific information on the wizard pages, click Help.

Creating a Trusted Root Container

You can create a Trusted Root container anywhere in the eDirectory tree.

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Server > Create Trusted Root Container.

  4. Specify a name for the Trusted Root container.

  5. Browse and select the context for the Trusted Root container.

  6. Click OK.

NOTE:Different applications might require that the Trusted Root container be given a specific name and be in a specific location in the eDirectory tree. NetIQ Certificate Server requires that the Trusted Root container be named Trusted Roots and be located in the Security container. The certificates in this container are used to validate user certificates signed by external CAs and intermediate CA certificates stored in Trusted Root objects. Server certificates and the Organizational CA's certificates use the certificate chain stored in their own objects.

Creating a Trusted Root Object

A Trusted Root object can only reside in a Trusted Root container.

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Server > Create Trusted Root.

    This opens the Create a Trusted Root Object Wizard that helps you create the Trusted Root object. Follow the prompts to create the object. For specific information on the wizard pages, click Help.

NOTE:Any type of certificate can be stored in a Trusted Root object (CA certificates, intermediate CA certificates, or user certificates).

Creating an SAS Service Object

The SAS Service object is automatically created as part of the server health check. You should not need to create it manually. If you need to create it manually, use the following procedure:

  1. Launch iManager.

  2. Log in to the eDirectory tree as an administrator with the appropriate rights.

    To view the appropriate rights for this task, see Entry Rights Needed to Perform Tasks.

  3. On the Roles and Tasks menu, click NetIQ Certificate Server > Create SAS Service Object.

    This opens the Create a SAS Service Object Wizard that helps you create the SAS Service object. Follow the prompts to create the object. For specific information on the wizard pages, click Help.