Configuring the Directory Server
Configuring Security in the Directory Server
Getting SSL Up and Running Quickly
To Accept SSL-Based Connections Using a Self-Signed Certificate
Enabling SSL and StartTLS in QuickSetup
Configuring Key Manager Providers
Using the JKS Key Manager Provider
To Sign the Certificate by Using an External Certificate Authority
To Configure the JKS Key Manager Provider
Using the PKCS #12 Key Manager Provider
Using the PKCS #11 Key Manager Provider
Configuring Trust Manager Providers
Using the Blind Trust Manager Provider
Using the JKS Trust Manager Provider
Using the PKCS #12 Trust Manager Provider
Configuring Certificate Mappers
Using the Subject Equals DN Certificate Mapper
Using the Subject Attribute to User Attribute Certificate Mapper
Using the Subject DN to User Attribute Certificate Mapper
Using the Fingerprint Certificate Mapper
Configuring SSL and StartTLS for LDAP and JMX
Configuring the LDAP and LDAPS Connection Handlers
To Enable a Connection Handler
To Specify a Connection Handler's Listening Port
To Specify a Connection Handler's Authorization Policy
To Specify a Nickname for a Connection Handler's Certificate
To Specify a Connection Handler's Key Manager Provider
To Specify a Connection Handler's Trust Manager Provider
To Enable SSL-Based Communication
Enabling SSL in the JMX Connection Handler
SASL Options for the ANONYMOUS Mechanism
SASL Options for the CRAM-MD5 Mechanism
SASL Options for the DIGEST-MD5 Mechanism
SASL Options for the EXTERNAL Mechanism
SASL Options for the GSSAPI Mechanism
SASL Options for the PLAIN Mechanism
Configuring SASL Authentication
Configuring SASL External Authentication
Configuring SASL DIGEST-MD5 Authentication
Configuring SASL GSSAPI Authentication
To Configure Kerberos V5 on a Host
To Specify SASL Options for Kerberos Authentication
Example Configuration of Kerberos Authentication Using GSSAPI With SASL
Troubleshooting Kerberos Configuration
Testing SSL, StartTLS, and SASL Authentication With ldapsearch
A trust manager provider can improve security whenever SSL or StartTLS is used by thwarting attempts to use forged certificates and foiling man-in-the-middle attacks. The two primary use cases for trust manager providers are as follows:
A client presents its own certificate to the directory server during the SSL or StartTLS negotiation process, potentially for use in SASL EXTERNAL authentication.
The directory server attempts to establish an SSL-based connection to an external system, for example for the purpose of synchronization or for proxied or chained operations.
The trust manager has no impact on the strength of the encryption, so only the directory server and its peer will be able to understand the communication. Any third-party observer will be unable to decipher the exchange. However, the trust manager is responsible for ensuring that the peer is who it claims to be so that confidential information is not inadvertently exposed to one peer masquerading as another.
The trust manager considers a number of factors to determine whether a peer certificate should be trusted. This topic describes some of the most common criteria that are taken into account during this process.
One of the simplest trust mechanisms is the validity period for the certificate. All certificates have a specific window during which they should be considered valid, bounded by "notBefore" and "notAfter" time stamps. If the current time is beyond the "notAfter" time stamp, the certificate is expired and trust managers reject it. Similarly, certificates are also typically rejected if the current time is before the "notBefore" time stamp. Most often, the "notBefore" time stamp is set to the time that the certificate was signed, but there are cases in which a certificate might be issued that is not immediately valid. In those cases, it is important to ensure that the peer is not granted access too early.
Another very important factor in deciding whether to trust a peer certificate is the peer certificate chain. When one system presents its certificate to another, it does not present its certificate only, but a chain of certificates that describes all entities involved in the process. When a trust manager is attempting to determine whether to trust a peer, the trust manager first looks in its trust store to determine whether it contains the peer certificate. If that certificate is found, the peer will be trusted (barring rejection for another reason, such as being outside the validity period). If the peer's certificate is not found, the trust manager looks at the next certificate in the chain, which will be the certificate that was used to sign the peer's certificate (also called the issuer certificate). If the trust store contains the issuer's certificate, the server will trust that issuer certificate and will also implicitly trust any certificate that it has signed. This process continues up the certificate chain (looking at the certificate that signed the issuer certificate, and so on) until one of the certificates is found in the trust store or until the root of the chain is reached (in which case, the root certificate will be self-signed and therefore will be its own issuer). If none of the certificates in the peer chain is contained in the trust store, the peer's certificate is rejected.
This process makes it much easier to manage an environment with a large number of certificates (for example, one in which there is a large number of servers or in which many clients use SASL EXTERNAL authentication). It is not necessary for the trust store to have each individual peer certificate. The trust store can contain only one of the certificates in the peer chain. For example, if all of the certificates that might legitimately be presented to the server were signed by the same issuer, it is necessary to have only that issuer's certificate in the trust store in order to implicitly trust any of the peers.
In some environments, there might be other elements taken into account when deciding to trust a peer certificate chain. For example, there might be a certificate revocation list (CRL) that contains a list of all of the certificates that have been revoked and should no longer be considered valid even if they are still within their validity period and were signed by a trusted issuer. This can be useful, for example, if the certificate belonged to an employee that has left the company or if the private key for the certificate has been compromised. The Online Certificate Status Protocol (OCSP, as described in RFC 2560 also provides a similar mechanism, in which the trust manager might ask an OCSP server whether a given certificate is still valid. The directory server currently does not support using CRLs or OCSP when attempting to determine whether a peer certificate chain should be trusted.