3.1 Understanding How Access Manager Uses Certificates

Access Manager allows you to manage centrally stored certificates used for digital signatures and data encryption. eDirectory resides on the Administration Console and is the main certificate store for all of the Access Manager components. If you use a Novell Certificate Server, you can create certificates there and import them into Access Manager.

By default, all Access Manager components (Identity Server, Access Gateway and SSL VPN) trust the local Access Manager certificate authority (CA). However, if the Identity Server is configured to use an SSL certificate signed externally, the trust store of the Embedded Service Provider for each component must be configured to trust this new CA.

Certificate management commands issued from a secondary Administration Console can work only if the primary console is also running properly. Other commands can work independently of the primary console.

You can create and distribute certificates to the following components:

Identity Server: Uses certificates and trust stores to provide secure authentication to the Identity Server and enable encrypted content from the Identity Server portal via HTTPS. Certificates also provide secure communications between trusted Identity Servers and user stores.

Liberty and SAML 2.0 protocol messages that are exchanged between identity and service providers often need to be digitally signed. The Identity Server uses the signing certificate included with the metadata of a trusted provider to validate signed messages from the trusted provider. For protocol messages to be exchanged between providers through SSL, each provider must trust the CA of the other provider. You must import the public key of the CA used by the other provider.

The Identity Server also has a trust store for OCSP (Online Certificate Status Protocol) certificates, which is used to check the revocation status of a certificate.
Access Gateway: Uses server certificates and trusted roots to protect Web servers, provide single sign-on, and enable the product’s data confidentiality features, such as encryption. They are used for background communication with the Identity Server and policy engine and to establish trust between the Identity Server and the Access Gateway.
SSL VPN: Uses server certificates and trusted roots to secure access to non-HTTP applications.

To ensure the validity of X.509 certificates, Access Manager supports both Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) methods of verification.

When X509 authentication is configured as the authentication contract, it works even after you revoke the certificate for the X509 mutual authentication. When you access the nidp login page from the client browser and select the revoked certificate, browser does not throw an error message telling that the certificate has been revoked. You can either issue a CRL or wait until the next CRL issuance date. The revoked certificates will work until the next CRL issuance date.

If you do not want to wait and issue a CRL now, perform the following steps:

Navigate to Roles and Tasks > NetIQ Certificate Server > Configure Certificate Authority > CRL.
Click CRL.
Under Next CRL Issuance, click Issue Now.
Click OK.
Restart the Identity Server.

Access Manager stores the certificates that a device has been configured to use in trust stores and keystores. This section describes the following certificate features:

3.1.1 Process Flow

You can install and distribute certificates to the Access Manager components and configure how the components use certificates. This includes central storage, distribution, and expired certificate renewal. Figure 3-1 illustrates the primary administrative actions for certificate management in Access Manager:

Figure 3-1 Certificate Management

Generate a certificate signing request (CSR). See Section 3.2.4, Generating a Certificate Signing Request.
Send the CSR to the external certificate authority (CA) for signing.

A CA is a third-party or network authority that issues and manages security credentials and public keys for message encryption. The CA’s certificate is held in the configuration store of the computers that trust the CA.
Import the signed certificate and CA chain into the configuration store. See Importing Public Key Certificates (Trusted Roots).
Assign certificates to devices. See Assigning Certificates to Access Manager Devices.

If you are unfamiliar with public key cryptography concepts, see “Public Key Cryptography Basics” in the Novell Certificate Server 3.1.1 Guide.

See Section A.0, Certificates Terminology for information about certificate terminology.

3.1.2 Access Manager Trust Stores

A trust store contains trusted roots, which are public certificates of known, trusted certificate authorities. Access Manager creates the trust stores listed below for the devices that it manages. The trust stores are created when you import a device into the Administration Console. If you have not imported a particular device type, the trust store for that device type does not exist. If you have imported multiple devices of the same type, the Administration Console creates an instance of the trust store for each device.

When a certificate has been created by a root CA, the trust store needs to contain only the public certificate of the CA. However, some certificates are created by an intermediate CA, which has been issued by a root CA. When intermediate CAs are involved, all the public certificates of the CAs in the chain need to be included in the trust store.

The Administration Console creates a trust store in the file system of the device that is assigned to the trust store.

Linux: /opt/novell/devman/jcc/certs/<device>
Windows Server 2008 Identity Server: \Program Files (x86)\novell\devman\jcc\certs\ <device>
Windows Server 2008 Access Gateway Service: \Program Files\novell\devman\jcc\certs\<device>

The <device> can be idp (for the Identity Server), esp (for the Embedded Service Providers, including Access Gateways, J2EE agents, and SSL VPN servers), or sslvpn (for the SSL VPN server).

To view the trust stores:

In the Administration Console, click Security > Trusted Roots.
Select a trusted root, then click Add Trusted Roost to Trust Stores.
Click the Select Keystore icon.

The list can include the following trust stores:

Trust Store: This Identity Server trust store contains the trusted root certificates of all the providers that it trusts. Liberty and SAML 2.0 protocol messages that are exchanged between identity and service providers often need to be digitally signed. A provider uses the signing certificate included with the metadata of a trusted provider to validate signed messages from the trusted provider. The trusted root of the CA that created the signing certificate for the provider needs to be in this trust store.

To use SSL for exchanging messages between providers, each provider must trust the SSL certificate authority of the other provider. You must import the root certificate chain for the other provider. Failure to do so causes numerous system errors.

This trust store is also used to store the trusted root certificates of the user stores that it has been configured to use.

OCSP Trust Store: The Identity Server uses this trust store for OCSP (Online Certificate Status Protocol) certificates. OCSP is a method used for checking the revocation status of a certificate. To use 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.

SSL VPN Trust Store: This trust store is used by the traditional SSL VPN server that is configured as a protected resource of the Access Gateway. The trust store contains the trusted root certificate of the Identity Server that the Access Gateway has been configured to trust.

ESP Trust Store (SSL VPN): This trust store is used by an SSL VPN server that is ESP-enabled. It contains the trusted root certificate of the Identity Server that it has been configured to trust. It usually contains one certificate unless you have modified the SSL VPN server to trust one Identity Server, and then modify the SSL VPN server to trust a different Identity Server. If you are using certificates generated by the Access Manager CA, the root certificate of this CA is automatically added to this trust store. If the Identity Server is using a certificate generated by an external CA, you need to add the trusted root certificate of that CA to this trust store.

ESP Trust Store (Access Gateway): The Access Gateway ESP trust store contains the trusted root certificate of the Identity Server that it has been configured to trust. It usually contains one certificate unless you configure the Access Gateway to trust one Identity Server, and then modify the Access Gateway to trust a different Identity Server. If you are using certificates generated by the Access Manager CA, the root certificate of this CA is automatically added to this trust store. If the Identity Server is using a certificate generated by an external CA, you need to add the trusted root certificate of that CA to this trust store.

Proxy Trust Store: When SSL is set up between the Access Gateway and its Web servers, the Access Gateway uses this trust store for the trusted root certificates of the Web servers.

This trust store does not use the default location:
- Access Gateway Appliance: /opt/novell/apache2/cacerts
- 3.1 SP4 Access Gateway Service: /opt/novell/apache2/cacerts
- Windows Access Gateway Service: \Program Files\Novell\apache\cacerts
ESP Trust Store (J2EE Agent): The agent ESP trust store contains the trusted root certificate of the Identity Server that it has been configured to trust. It usually contains one certificate unless you configure the agent to trust one Identity Server, and then modify the agent to trust a different Identity Server. If you are using certificates generated by the Access Manager CA, the root certificate of this CA is automatically added to this trust store. If the Identity Server is using a certificate generated by an external CA, you need to add the trusted root certificate of that CA to this trust store.
Click Cancel twice.

3.1.3 Access Manager Keystores

A keystore is a location, such as a file, containing keys and certificates. Access Manager components can access the keystore to retrieve certificates and keys as needed. Keystores for Access Manager are already defined for the components.

The Administration Console creates a keystore in the file system of the device that is assigned to the keystore. The operating system of the device determines the location:

Linux: /opt/novell/devman/jcc/certs/<device>
Windows Server 2008 Identity Server: \Program Files (x86)\novell\devman\jcc\certs\ <device>
Windows Server 2008 Access Gateway Service: \Program Files\novell\devman\jcc\certs\<device>

The <device> can be idp (for the Identity Server), esp (for the Embedded Service Providers, including Access Gateways, and SSL VPN servers), or sslvpn (for the SSL VPN server).

To view the keystores:

In the Administration Console, click Security > Certificates.
Click the name of a certificate, then click Add Certificate to Keystores.
Click the Select Keystore icon.

Access Manager creates keystores for the following devices:
Click Cancel twice.

Identity Server Keystores

Access Manager creates the following keystores for each Identity Server cluster configuration:

Signing: Contains the certificate that is used for signing the assertion or specific parts of the assertion.

Encryption: Contains the certificate that is used to encrypt specific fields or data in assertions.

SSL Connector: Contains the certificate that the Identity Server uses for SSL connections. If multiple devices are installed on the same machine, the Identity Server uses the COMMON_TOMCAT_CLUSTER keystore.

Provider Introductions SSL Connector: Contains the certificate that you configure when you set up the Identity Server to provide introductions to service providers that are trusted members of a service domain. The subject name of this certificate needs to match the DNS name of the service domain.

Consumer Introductions SSL Connector: Contains the certificate that you configure when you set up the Identity Server to consume authentications provided by other identity providers that are trusted members of a service domain. The subject name of this certificate needs to match the DNS name of the service domain.

Access Gateway Keystores

Access Manager creates the following keystores for each Access Gateway or cluster:

Signing: Contains the certificate that is used for signing the assertion or specific parts of the assertion.

Encryption: Contains the certificate that is used to encrypt specific fields or data in assertions.

ESP Mutual SSL: Contains the certificate that is used for SSL when you have established SSL communication between the Access Gateway and the Identity Server. The public key (trusted root) of the certificate authority that created the certificate needs to be in the Identity Server’s trust store.

Proxy Key Store: Contains the certificate that is used for SSL when you have enabled SSL between a reverse proxy and the browsers. The public key (trusted root) of the certificate authority that created the certificate needs to be in browser’s trust store for the SSL connection to work without warnings. If you create multiple reverse proxies and enable them for SSL, each reverse proxy needs a certificate, and the subject name of the certificate needs to match the DNS name of the reverse proxy.

This keystore does not use the default location:

Access Gateway Appliance: /opt/novell/apache2/certs
3.1 SP4 Access Gateway Service: /opt/novell/apache2/certs
Windows Access Gateway Service: \Program Files\Novell\apache\certs

SSL VPN Keystores

Access Manager creates the following keystores for each SSL VPN server or cluster:

Signing: Contains the certificate that is used for signing the assertion or specific parts of the assertion.

Encryption: Contains the certificate that is used to encrypt specific fields or data in assertions.

ESP Mutual SSL: Contains the certificate that is used for SSL when you have established SSL communication between the ESP-enabled SSL VPN server and the Identity Server. The public key (trusted root) of the certificate authority that created the certificate needs to be in the Identity Server’s trust store.

SSL VPN Secure Tunnel: Contains the certificate that encrypts the data exchanged between SSL VPN client and the SSL VPN server, after the SSL VPN connection is made.

This keystore does not use the default location; it is located in the /etc/opt/novell/sslvpn/certs directory.

SSL Connector: Contains the certificate that encrypts authentication information between the SSL VPN client browser and the SSL VPN server.

Keystores When Multiple Devices Are Installed on the Administration Console

Access Manager creates the following keystore when the Identity Server and the SSL VPN server are installed on the Administration Console.

COMMON_TOMCAT_CLUSTER: Contains the certificate that is used for SSL connections.

The location of this keystore depends upon which device was installed last: the Identity Server or the SSL VPN server. If the Identity Server was installed last, the keystore is in the idp directory. If the SSL VPN server was installed last, the keystore is in the sslvpn directory.