3.6 Assigning Certificates to Access Manager Devices

After you assign certificates to devices, the certificates are placed in keystores. Ensure that you update the device so that the certificates are pushed into active use.

This section discusses how you update, renew, and assign certificates to Access Manager devices.

3.6.1 Importing a Trusted Root to the LDAP User Store

When you specify the settings of a user store for an Identity Server configuration, or add a user store, you can import the trusted root certificate to the LDAP user store device.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Local > [User Store].

  2. Under Server Replicas, click the name of the server replica.

    Importing a trusted root

  3. Enable the Use secure LDAP connections option.

    This option allows SSL communication to occur between the Identity Server and the user store.

  4. Click Auto import trusted root.

  5. Click OK to confirm the import.

    Ensure that you have pop-ups enabled, or the browser cannot display the Confirm dialog box.

    Select a trusted certificate

  6. Select one of the certificates in the list.

    You are prompted to choose either a server certificate or a root CA certificate. To trust one certificate, choose Server Certificate. Choose Root CA Certificate to trust any certificate signed by that certificate authority.

  7. Specify an alias, then click OK.

    You use the alias to identify the certificate in Access Manager.

  8. On the User Store page, click OK.

  9. Restart the Identity Server.

3.6.2 Managing Identity Server Certificates

The Identity Server stores certificates in keystores and trust stores. Keystores can hold only one certificate; trust stores can hold multiple trusted roots. After you install the Identity Server, you should replace the default certificates in the keystore. You should create an SSL certificate for the Identity Server and use it to replace the predefined test-connector certificate that comes with Access Manager. You can also replace the test-provider and test-consumer certificates in the Provider Introductions SSL Connector and Consumer Introductions SSL Connector keystores. The steps for replacing the signing, encryption, provider, and consumer certificates are similar.

You can also add trusted roots to the Trust Store used by the Identity Server, delete imported trusted roots, or auto-import them from a server. The Trust Store is the certificate container for CA certificates that the Identity Server has been configured to trust. It needs to contain the trusted root for the identity providers, service providers, and embedded service providers that it has been configured to trust.

You can also access the OCSP trust store to add OCSP server certificates. Online Certificate Status Protocol is a method used for checking the revocation status of a certificate. For this feature, you must set up an OCSP server. The Identity Server sends an OCSP request to the OCSP server to determine if a certain certificate has been revoked. The OCSP server replies with the revocation status. If this revocation checking protocol is used, the Identity Server does not cache or store the information in the reply, but sends a request every time it needs to check the revocation status of a certificate. The OCSP reply is signed by the OCSP server. To verify that it was signed by the correct OCSP server, the OCSP server certificate needs to be added to this trust store. The OCSP server certificate itself is added to the trust store, not the CA certificate

  1. In the Administration Console, click Devices > Identity Servers > Edit > Security.

  2. To replace a certificate in a keystore:

    1. Click the keystore link that contains the certificate you want to replace:

      Encryption: Displays the encryption certificate keystore. The encryption certificate is used to encrypt specific fields or data in the assertions.

      Signing: Displays the signing certificate keystore. Click this option to access the keystore and replace the signing certificate as necessary. The signing certificate is used to sign the assertion or specific parts of the assertion.

      SSL: Displays the SSL connector keystore. Click this option to access the keystore and replace the SSL certificate as necessary. This certificate is used for SSL connections.

      Provider: Displays the identity provider keystore. Click this option to access the keystore and replace the identity provider certificate.

      Consumer: Displays the identity consumer keystore. Click this option to access the keystore and replace the identity consumer certificate as necessary.

    2. Click Replace.

      A keystore stores only one certificate at a time. When you replace a certificate, you overwrite the existing one.

    3. In the Replace dialog box, click the Select Certificate icon and browse to select the certificate you created in Section 3.2, Creating Certificates.

    4. Click OK.

    5. Click OK in the Replace dialog box.

    6. Restart Tomcat, as prompted by the system.

      The system restarts Tomcat for you if you click Restart Now at the prompt. If you want to restart at your convenience, select Restart Later and then manually restart Tomcat.

      Linux: Enter the following command:

      /etc/init.d/novell-tomcat5 restart

      Windows: Enter the following commands:

      net stop Tomcat5

      net start Tomcat5

  3. To modify the trusted roots in the Trust Store:

    1. Click the name of the trust store that you want to manage.

      NIDP Trust Store: Contains the trusted root certificates of all the providers that the Identity Server trusts.

      OCSP Trust Store: Contains the certificates of the OCSP servers that the Identity Server trusts.

    2. To add a trusted root that you have saved in a file, click Add.

    3. To remove a trusted root, select the trusted root, then click Delete.

    4. To download the trusted root from the server, click Auto-Import From Server, specify the DNS or IP address of the server, enter the port, then click OK.

    5. Select the certificate to add, specify an alias, then click OK.

    6. Update the Identity Server configuration on the Servers page, as prompted.

3.6.3 Assigning Certificates to an Access Gateway

The Access Gateway can be configured to use certificates for SSL communication with three types of entities:

  • Identity Server: The Access Gateway uses the Embedded Service Provider to communicate with the Identity Server. The Access Manager CA automatically generates the required certificates for secure communication when you set up a trusted relationship with the Identity Server. To manage these certificates in the Administration Console, click Access Gateways > [Configuration Link] > Service Provider Certificates. For more information, see Managing Embedded Service Provider Certificates in the Novell Access Manager 3.1 SP2 Access Gateway Guide.

  • Client browsers: You can enable SSL communication between the client browsers and the Access Gateway. When setting up this feature, you can either have the Access Manager CA automatically generate a certificate key or you can select a certificate key you have already imported (or created) for the reverse proxy. To manage this certificate in the administration console, click Access Gateways > [Configuration Link] > [Name of Reverse Proxy]. For more information, see Managing Reverse Proxies and Authentication in the Novell Access Manager 3.1 SP2 Access Gateway Guide.

  • Protected Web servers: You can enable SSL communication between the Access Gateway and the Web servers it is protecting. This option is only available if you have enabled SSL communication between the browsers and the Access Gateway. You can enable SSL or mutual SSL. To manage these certificates in the Administration Console, click Access Gateways > [Configuration Link] > [Name of Reverse Proxy] > [Name of Proxy Service] > Web Servers. For more information, see Configuring the Web Servers of a Proxy Service in the Novell Access Manager 3.1 SP2 Access Gateway Guide.

3.6.4 Assigning Certificates to J2EE Agents

To enable the J2EE agent for SSL, you must set up the following trust relationships:

  • The J2EE server with the Identity Server

  • The J2EE agent with the Identity Server

For instructions on setting up these certificates, see Configuring SSL Certificate Trust in the Novell Access Manager 3.1 SP2 J2EE Agent Guide.

3.6.5 Configuring SSL for Authentication between the Identity Server and Access Manager Components

By default, all Access Manager components (Identity Server, Access Gateway, SSL VPN, and J2EE agents) trust the certificates signed by the local CA. However, if the Identity Server is configured to use an SSL certificate signed externally, the trusted store of the service provider for each component must be configured to trust this new CA. Import the public certificate of the CA into the following trust stores:

  • For an Access Gateway, click Devices > Access Gateways > Edit > Service Provider Certificates > Trusted Roots.

  • For a J2EE agent, click Devices > J2EE Agents > Edit > Trusted Roots.

  • For an SSL VPN server, click Devices > SSL VPNs > Edit > SSL VPN Certificates > Trusted Root.

If an Access Gateway, a J2EE agent, or an SSL VPN server is configured to use an SSL certificate signed externally, the trusted store of the Identity Server must be configured to trust this new CA. Import the public certificate of the CA into the Identity Server configuration that the component is using for authentication.

In the Administration Console, click Devices >Identity Servers > Edit > Security > NIDP Trust Store and add the certificate to the Trusted Roots list.

NOTE:Whenever you replace certificates on a device, you must update the Identity Server configuration (by clicking Update Servers on the Servers page), or restart the Embedded Service Provider.

3.6.6 Changing a Non-Secure (HTTP) Environment to a Secure (HTTPS) Environment

If you are running in a non-secure staging environment, and you’re ready to move to production, you must perform the following steps to enable security.

  1. Change the Identity Server configuration protocol to HTTPS. (See Configuring Secure Communication on the Identity Server in the Novell Access Manager 3.1 SP2 Setup Guide.)

  2. Replace the test certificates with your own. (See Using Access Manager Certificates or Using Externally Signed Certificates in the Novell Access Manager 3.1 SP2 Setup Guide.)

  3. Update all devices that are trusting this Identity Server configuration.

    This causes the Embedded Service Provider to reimport the metadata of the Identity Server.

  4. (Conditional) If you have set up federation, reimport metadata for trusted service and identity providers. (See Managing Metadata in the Novell Access Manager 3.1 SP2 Identity Server Guide.)

  5. Change the Access Gateway configuration to HTTPS. (See Configuring the Access Gateway for SSL in the Novell Access Manager 3.1 SP2 Setup Guide.)

3.6.7 Creating Keystores and Trust Stores

A keystore is storage file containing keys, certificates, and trusted roots. Access Manager agents can access them to retrieve certificates, keys, and trusted roots as needed. A trust store is a keystore containing only trusted roots. Intermediate CAs and end entity public certificates can be part of a trust store.

Access Manager comes with predefined stores for certificate management. However, in certain situations you might need to create a keystore or trust store. For example, if you are using JBoss keystore certificates that you need to import into Access Manager, you must create a keystore and assign it to the JBoss agent. It is probable that the keystore already exists on the JBoss file system, as created and configured by JBoss. Creating it again through Access Manager does not delete the existing keystore. This does allow Access Manager to recognize the existing keystore and add or remove the certificates. Access Manager cannot manage certificates that were created before the keystore is created in Access Manager.

The easiest way to create a keystore is to do so when you are adding the certificate to the keystore. If you want to create a trust store, the steps are identical, except you select trusted roots from the Trusted Roots page, rather than the certificates from the Certificates page.

A keystore stores only one certificate at a time. When you replace a certificate, you overwrite the existing one.

  1. In the Administration Console, click Security > Certificates.

  2. Import the certificate, if you have not done so already. See Importing a Private/Public Key Pair.

  3. Click the certificate name.

  4. In the Certificate Details page, click Add Certificate to Keystores.

  5. On the Add Certificate to Keystores dialog box, click the Select Keystore button to browse for key stores.

  6. On the Keystore page, click New.

    Creating a new key store

  7. Fill in the following fields:

    Keystore name: Specifies the name of the keystore. This maps to a name that the server communication recognizes to identify the keystore on the device.

    Keystore type: Specifies whether to use Java, PEM, or PKCS12.

    Keystore password: Specifies the password to revise the keystore settings.

    Device: Specifies the device (by IP) to which you assign the keystore. The device can be an Identity Server or SSL VPN. You cannot assign one keystore to multiple devices.

    Directory: Specifies the directory where PKCS12 or PEM files are stored.

    For example, /var/opt/novell/keystores/.

    File: Specifies the path and filename of the Java keystore (JKS).

    For example, /var/opt/novell/keystores/myKeystore.keystore.

    Description: Describes the keystore.

  8. Click OK.

    This creates the keystore.

  9. (Optional) On the Keystore page, assign a certificate to the new keystore by selecting the store’s check box.

  10. Click OK in the Add Certificate to Keystores dialog box.