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, SSL VPN, and J2EE agents) 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.
J2EE Agent: Uses certificates and trust stores to establish trust between the J2EE Agent and the Identity Server, and for SSL between the J2EE server and the Identity Server.
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.
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:
You can install and distribute certificates to the Access Manager product 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.
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 2003: \Program Files\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
> .Select a trusted root, then click
.Click the
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.
SSLVPN 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.
This trust store does not use the default location; it is located in the /etc/opt/novell/sslvpn/certs directory.
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 EPS 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/conf/keys
Linux 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
l twice.A keystore is a location, such as a file, containing keys and certificates. Access Manager components and agents 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 2003: \Program Files\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 keystores:
In the Administration Console, click
> .Click the name of a certificate, then click
.Click the
icon.Access Manager creates keystores for the following devices:
Click
twice.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 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/conf/keys
Linux Access Gateway Service: /opt/novell/apache2/certs
Windows Access Gateway Service: \Program Files\Novell\apache\certs
Access Manager creates the following keystores for each J2EE Agent:
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 J2EE agent 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.
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.
SSLVPN 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.
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.