Log in to Administration Console.
Import the trusted root certificate or certificate chain of the certificate authority (CA) into Identity Server trusted root store. Identity Server must trust the CA that created the user certificates.
For more information, see Importing Public Key Certificates (Trusted Roots).
Click Devices > Identity Servers > Edit > Local > Classes > New.
Specify a display name, then select X509Class from the list.
Click Next and specify the following details:
|
Option |
Description |
|---|---|
|
Validations |
Select the validation type. Trust validation occurs if the certificate chain is verified in NIDP Trust Store. In addition to usual certificate validations, Identity Server supports CRL (certificate revocation list) and OCSP (Online Certificate Status Protocol) validations for each authentication request. Access Manager caches CRLs. The status of a newly revoked certificate is not shown until the next cache refresh. For higher security requirements, use OCSP validation with CRL validation. You can select None, CRL, OCSP, OCSP-CRL, or CRL-OCSP validation. In a production environment, select OCSP-CRL or CRL-OCSP validation for the highest security. The default setting is to check OCSP first, then CRL. |
|
CRL Validation |
Checks the CRL. If you enable CRL validations, the CRL distribution point extension is read out of the user’s X.509 certificate. The CRL distribution point contains the URL where the complete CRL can be found, as published by the certificate authority. The system checks the CRL itself and then checks to see if the user certificate is on the revoked list. The system can get the CRL over HTTP and LDAP. If you are not expecting the distribution point in user certificates, you can specify a value in the LDAP URL option to get the CRL. Access Manager supports two schemes for a URL: http:// and ldap://. |
|
OCSP Validation |
If OCSP validation is enabled, the Authority Info Access point (AIA) is read out of the user certificate, which contains the URL for the OCSP responder. A signed OCSP request for the user certificate is sent to OCSP responder. A signed OCSP response is received from the responder that has the revoked status for the user certificate. Alternately, if you are not expecting an AIA in a user certificate, you can specify a value in the OCSP responder URL field. The value you enter here overrides any OCSP responder URLs in a certificate. Access Manager supports two schemes for a URL: http:// and ldap://. |
|
Disable Root CA Revocation Check |
Select to disable checking if a certificate authority has been revoked. This option checks CRL and OCSP for the trusted root certificate in the chain. You can enable or disable this option for X.509 user authentication performance. If you do not select this option, checks performed by Identity Server depends on the certificates that have been added to the Identity Server trust store. If the root certificate and the intermediate certificates in the chain are in the trust store, Identity Server only validates the client (leaf) certificate. If the trust store only contains the root certificate, the browser sends the intermediate and leaf certificates, which are then validated by Identity Server. |
Configure the trust stores.
NIDP Trust Store: This trust store must contain the trusted root certificate of the certificate authorities that signed your user certificates. Click this link to add certificates to the trust store.
OCSP Trust Store: This trust store must contain the signing certificate of the OCSP servers you want to trust. Click this link to add certificates to the trust store. You must add the signing certificate, not the trusted root certificate, for this feature to work.
Under Trusted Roots for Validation, click New and add the trusted roots that you want to use in the authentication. Access Manager uses these trusted roots to validate the user’s identity.
If you do not specify any trusted root, Access Manager validates the user’s certificate against the default Access Manager trusted root. For more information, see Restricting the X.509 Authentication to a Specific Certificate Authority.
Select Force browser restart on logout.
Some browsers, such as Internet Explorer, keep the SSL session active until the user closes the browser. When the user logs in with the certificate on a smart card, removes the card, and logs out without closing the browser, the SSL session remains active. Another user can use the existing session if the machine is accessible. Selecting this options ensures that the session gets closed after a user logs out.
Select Read certificate from http header and specify the header name. This configuration is required when Identity Server is configured as a public resource behind a reverse proxy other than an Access Manager Access Gateway reverse proxy. If the proxy is configured to send the user certificate to Identity Server as part of HTTP header in the PEM encoded data, Identity Server can read this header value and completes X.509 authentication.
For example, if Identity Server is behind Apache, add the following advanced Apache configuration with the rewrite module to send the user certificate to Identity Server through a custom header called SSL-Client-Cert.
SSLVerifyClient optional_no_ca
SSLVerifyDepth 10
RequestHeader set SSL-Client-Cert "%{SSL_CLIENT_CERT}s“
Click Next.
Continue with Configuring Attribute Mappings.