30.5 Troubleshooting Certificate Issues

30.5.1 Resolving the JCC Communication between Devices and Administration Console

When the secret key in the jcc.keystore file is updated, Identity Server or Access Gateway stops communicating with Administration console.

To workaround this issue, perform the following steps on the affected devices:

  1. Log in to Identity Server or Access Gateway and navigate to the JCC folder:

    Linux: /opt/novell/devman/jcc/conf

    Windows: \Program Files\Novell\devman\jcc\conf

  2. Verify if the jcc.keystore.original file exists.

  3. If the jcc.keystore.original file exists, then:

    1. Replace jcc.keystore with jcc.keystore.original.

    2. Replace keystore_info.xml with keystore_info.xml.original.

  4. If the jcc.keystore.original file does not exist, then:

    1. Navigate to the JCC directory.

      Linux: /opt/novell/devman/jcc

      Windows: \Program Files\Novell\devman\jcc

    2. Run the following reimport command:

      • On Identity Server:

        Linux: conf/reimport_nidp.sh jcc

        Windows: conf\reimport_nidp.bat jcc

      • On Access Gateway:

        Linux: conf/reimport_ags.sh jcc

        Windows: conf\reimport_ags.bat jcc

  5. Restart JCC

    Linux: /etc/init.d/novell-jcc restart

    Windows: Navigate to Control Panel > Administrative Tools > Services, then restart the JCCServer service.

  6. Restart the affected devices.

30.5.2 Resolving Certificate Import Issues

Use the following sections to resolve issues created when a full certificate chain is not imported in to Access Manager:

Importing an External Certificate Key Pair

The Access Manager Certificate Authority requires that all certificate key pairs in .pfx format contain the complete certificate chain. If a key pair was created with multiple CAs and the exported certificate does not contain the complete certificate chain, the file cannot be imported into Access Manager. When you try to import such a certificate, the following error message is displayed:

"Error importing certificate key pair: Error: Error: -1403

When exporting the certificate key pair, ensure that you include all the certificates in the certification path.

To ensure that your certificate contains all the intermediate certificates and contains them in the right order, import the certificate into Internet Explorer or Firefox.

  • For Internet Explorer, click Tools > Internet Options > Content > Certificates > Personal > Import.

  • For Firefox, click Tools > Options > Advanced > Encryption > View Certificates > Your Certificates > Import.

Make sure the browser contains the public key for all the intermediate CAs. Then select the certificate and export the certificate in .pfx format. In Internet Explorer, you must select to include all the certificates in the chain. In Firefox, all the certificates in the chain are automatically included.

If you receive an error when importing the certificate, the error comes from either NICI or PKI. For a description of these error codes, see Novell Certificate Server Error Codes and Novell International Cryptographic Infrastructure.

Resolving a -1226 PKI Error

When you create a certificate signing request, send it to a third-party issuer to be signed, and receive the server certificate from the third-party issuer. You sometimes receive a -1226 error when you try to import the signed certificate. You receive this error when the issuer does not send the trusted roots required to validate the issuer of the server certificate.

Use one of the following options to resolve this issue:

  • If the issuer included the trusted root and any intermediate certificates in a separate file or files, specify these files during the import by clicking the + character that allows you to add a trusted root or an intermediate certificate.

  • If the issuer did not send you any additional files, you can go to the issuer’s Web site, download them, then specify these files during the import by clicking the + character that allows you to add a trusted root or an intermediate certificate.

  • You can try importing the certificate into Internet Explorer, which has the trusted roots from all major CAs, then export the certificate with the required chain of trusted roots. See Using Internet Explorer to Add a Trusted Root Chain.

When the Full Certificate Chain Is Not Returned During an Automatic Import of the Trusted Root

Access Manager allows you to automatically import the trusted root under the following conditions:

  • When enabling SSL communication between Access Gateway and the Web server, you can automatically import the root CA from the Web server.

  • When setting up the user stores for Identity Server and adding the server replicas, you can automatically import the root CA of the LDAP server.

If there are multiple certificates in the chain, sometimes the server does not send all the certificates in the chain. When this happens, the following message is displayed:

The root CA certificate was not returned by the server. It might be necessary
to manually import the root CA certificate and possible intermediate CA
certificates in order to complete the chain.

To correct this problem, you need to manually import the missing entries. The easiest method to obtain all the certificates in the chain, including the root CA, is to import the server certificate into Internet Explorer, then export the chain and import it into Access Manager. If Access Manager already has some of the certificates, it skips their import and imports only the missing certificates.

For instructions on this process, see Using Internet Explorer to Add a Trusted Root Chain.

Using Internet Explorer to Add a Trusted Root Chain

The following procedure works only when Internet Explorer contains the trusted root certificate of the issuer of your certificate.

  1. In Internet Explorer, click Tools > Internet Options > Content > Certificates.

  2. Click Import and import your server certificate into the Other People tab.

  3. Click Other People, then double-click your certificate.

  4. Click Certification Path.

    • If the Certification Path shows that the certificate is OK, you now have the full certificate chain available for export. Click OK, then continue with Step 5.

    • If the Certification Path is not OK, you cannot use this method. Click OK, then contact your issuer for the certificate chain.

  5. Select the certificate, then click Export > Next.

  6. Select Cryptographic Message Syntax Standard - PKCS #7 Certificates (.P7B) as the format and select Include all certificates in the certification path if possible to include the certificate chain.

  7. Click Next, then specify a filename and path for the file.

  8. Click Next > Finish.

  9. Use this P7B file to import your server certificate into Access Manager.

30.5.3 Mutual SSL with X.509 Produces Untrusted Chain Messages

When you set up an X.509 contract for mutual SSL authentication, you must ensure that Identity Server trust store (NIDP-truststore) contains the trusted root from each CA that has signed the client certificates. If a client has a certificate signed by a CA that is not in Identity Server Trust Store, authentication fails.

To add a certificate to Identity Server Trust Store:

  1. In Administration Console Dashboard, click Devices > Identity Servers > Edit > Security > NIDP Trust Store.

  2. Click either Add or Auto-Import From Server and follow the prompts.

30.5.4 Certificate Command Failure

Certificate commands are generated when you upgrade Administration Console. Ensure that they have completed successfully.

  1. To determine whether a certificate command has failed, click Security > Command Status.

  2. Note the destination trust store or keystore of the failed command.

  3. Click Troubleshooting > Certificates.

    The Certificates page displays all the keystores and trust stores configured for Access Manager.

  4. Select the store, then click Re-push certificates.

    This sends all assigned certificates to the store. You can re-push certificates multiple times without causing any problems.

30.5.5 Cannot Log In with Certificate Error Messages

After an upgrade, if users cannot log in to the access protected resources, and the failure messages contain certificate error messages, manually push the certificates from Administration Console to Access Gateway.

To re-push a certificate:

  • For a reverse proxy certificate, go to the Reverse Proxy page, select a different certificate, click OK, return to the Reverse Proxy page, select the correct certificate, then click OK.

  • For a Web server certificate, go to the Web Server page, select a different SSL mutual certificate, click OK, return to the Web Server page, select the correct certificate, click OK, then apply the changes.

30.5.6 When a User Accesses a Resource, the Browser Displays Certificate Errors

When you configure Identity Server to use SSL (the HTTPS protocol), the browser must be configured to trust the CA that created the certificate for Identity Server. If you use a well-known CA, the browser is usually already configured to trust certificates from the CA. If you use a less-known CA or the Access Manager CA to create the certificate, you need to import the public key of the trusted root certificate into the browsers to establish the trust. For the Access Manager CA, this certificate is called configCA.

For instructions on how to export the public key of a trusted root certificate, see Viewing Trusted Root Details.

To import a public key into the browser, access the certificate options, then follow the prompts:

  • For Internet Explorer, click Tools > Internet Options > Content > Certificates > Trusted Root Certification Authorities > Import.

  • For Firefox, click Tools > Options > Advanced > Encryption > View Certificates > Authorities > Import.

30.5.7 Canceling Certificates Modification Results in Errors

An Access Gateway has the following issue when the certificate modifications are canceled:

If you make certificate changes on the Reverse Proxy or the Web Servers page, click the Configuration Panel link, and then cancel the changes on the Configuration page, the Reverse Proxy is configured with an invalid certificate.

To correct the problem, return to the page and select the old certificate. As soon as you exit the page, the certificate is pushed to the device. Because you did not change the certificate, you do not need to restart the Embedded Service Provider.

30.5.8 A Device Reports Certificate Errors

After you restore a device, especially Administration Console, the device might report certificate errors. To fix these errors, you need to re-push the certificates from Administration Console to the device:

  1. Click Troubleshooting > Certificates.

  2. Select the store that is reporting errors, then click Re-push certificates.

    You can select multiple stores at the same time.

  3. (Optional) To verify that the re-push of the certificates was successful, click Security > Command Status.

30.5.9 Renewing the expired eDirectory certificates

The Secondary Administration Console stops working when the eDirectory certificates expire. When a certificate is about to expire, Access Manager shows a warning message when you log in to Administration Console. You can check whether a certificate is expired on the Certificate Details page. See Section 14.1, Viewing Certificate Details.

To workaround this issue manually renew the eDirectory certificates. For more information, see renewing the certificates.

30.5.10 Cannot Replace Expired Certificates

When you enable signing certificate per SAML service provider, expired certificate cannot be replaced with an existing certificate in the signing key store.

For example:

Certificate 1 with alias name Cert1 is assigned to Service Provider 1 and Certificate 2 with alias name Cert2 is assigned to Service Provider 2. If Cert1 has expired and the user wants to use Cert2 instead of Cert1, the user cannot replace Cert1 with Cert2 because Cert2 is already existing in the signing key store.

To workaround this issue, perform the following steps:

  1. Add Cert2 with a different name (Cert4) and alias name Cert1.

  2. Select Cert1, click Replace and select Cert4 (certificate created in the previous step).