The certificate revocation list (CRL) is a list of revoked certificates that contains the reasons for the certificate's revocation, the date of it's issuance, and the entity that issued it. When a potential user attempts to access the OpenSSO Enterprise server, first access is allowed or denied based on the CRL entry for the root certificate included with the request. When the SAML v2 Service receives the incoming XML request, it parses the issuer Distinguished Name (DN) from the root certificate and retrieves the value defined by the com.sun.identity.crl.cache.directory.searchattr attribute in the Advanced properties of the Sites and Server tab. For more information, see Advanced in Sun OpenSSO Enterprise 8.0 Administration Reference. If the attribute value is CN and the issuer DN is, for example, CN="Entrust.net Client Certification Authority", OU=..., the SAML v2 Service uses Entrust.net Client Certification Authority to retrieve the CRL from the LDAP directory which acts as the CRL repository.
With this action, one of the following will occur:
If the LDAP directory returns a CRL that is not valid, the SAML v2 Service retrieves the value of the IssuingDistributionPointExtension attribute (usually an HTTP or LDAP URI) from the CRL and uses it to get new CRL from the certificate authority. If the certificate authority returns a valid CRL, it is saved to the LDAP directory and to memory and used for certificate validation.
If the LDAP directory returns no CRL but the certificate that is being validated has a defined CRL Distribution Point Extension, the SAML v2 Service retrieves it's value (usually an HTTP or LDAP URI) and uses the value to get a new CRL from the certificate authority. If the certificate authority returns a valid CRL, it is saved to the LDAP directory and to memory and used for certificate validation.
If the certificate authority returns a valid CRL, it is saved to the LDAP directory and to memory and used for certificate validation.
Currently, Certificate Revocation List Checking works only with an instance of Sun Directory Server.
After the CRL is loaded into memory and the root certificate validation is successful, the single sign-on process continues with validation of the signed XML message. The following are procedures to set up the SAML v2 Service for CRL checking.
CRL checking currently only works in the case of XML-based signature validation; for example, service provider side POST Artifact profile, or SOAP based logout. CRL checking does not work in the case of URL string based signature validation, XML signing, XML encryption or decryption.
A local instance of Directory Server must be designated as the CRL repository. It can be the same directory in which the OpenSSO Enterprise schema is stored or it can be standalone. The Java Development Kit (JDK) must be version 1.5 or higher.
Create one entry in Directory Server for each certificate authority.
For example, if the certificate authority's subjectDN is CN="Entrust.net Client Certification Authority",OU="www.entrust.net/GCCA_CPS incorp. by ref. (limits lib.)",O=Entrust.net and the base DN for Directory Server is dc=sun,dc=com, create an entry with the DN cn="Entrust.net Client Certification Authority",ou=people,dc=sun,dc=com.
If the certificate authority's subjectDN does not contain uid or cn attributes, do the following:
Create a new object class.
For example, sun-am-managed-ca-container.
Populate the new object class with the following attributes:
objectclass
ou
authorityRevocationList
caCertificate
certificateRevocationList
crossCertificatePair
Add the following entry (modified per your deployment) to Directory Server.
dn: ou=1CA-AC1,dc=sun,dc=com objectClass: top objectClass: organizationalunit objectClass: iplanet-am-managed-ca-container ou: 1CA-AC1
You will publish the appropriate CRL to the entry created in the last step.
Publish the appropriate CRL to the corresponding LDAP entry.
This part can be done automatically by OpenSSO Enterprise or manually. If the certificate being validated has a CRL Distribution Point Extension value, the publishing of the CRL is done automatically. If the certificate being validated has an IssuingDistributionPointExtension value, the initial publishing of the CRL must be done manually but future updates are done in runtime. If the certificate being validated has neither of these values, updates must be done manually at all time. See To Manually Populate a Directory Server with a Certificate Revocation List for information on manual population.
Configure OpenSSO Enterprise in the console to point to the instance of Directory Server designated as the CRL repository.
In the OpenSSO Enterprise Console, click the Configuration tab.
Click Servers and Sites tab.
Click the Server Name.
Click Security tab.
Click Inheritance Settings.
Uncheck the following properties:
LDAP Search Base DN
LDAP Server Bind Password
LDAP Server Bind Username
LDAP Server Host Name
LDAP server port number
Search Attributes
SSL Enabled
Click Save and then Back to Server Profile.
Click Certificate Revocation List Caching.
Configure the following attributes. See Certificate Revocation List Caching in Sun OpenSSO Enterprise 8.0 Administration Reference for definitions of the properties:
LDAP Server Host Name
LDAP Server Port Number
SSL Enabled
LDAP Server Bind User Name
LDAP Server Bind Password
LDAP Search Base DN
Search Attributes
Click Save.
Restart the web container.
Import all the certificate authority certificates into the cacerts keystore under the java.home/jre/lib/secure directory using the keytool utility.
Certificates must be imported as trustedcacert. More information on keytool can be found at http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/keytool.html.
Use your browser to get the initial CRL from the certificate authority manually.
Save the initial CRL file in the binary DER format to your local machine.
Convert the DER file to the text-based PEM format and finally LDAP Data Interchange Format (LDIF) using the following command:
ldif -b certificaterevocationlist;binary crl.ldif
The ldif command is available in your Directory Server installation.
The crl.ldif file contains text similar to the following:
certificaterevocationlist;binary:: MIH7MIGmMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBA YTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUE tJMRwwGgYDVQQDExNEb0QgQ2xhc3MgMyBSb290IENBFw0wNzA1MDExNDMzMDNaFw0wNzA1MDExNz UzMDNaMBQwEgIBTxcNMDcwNDI3MTY1NzMzWjANBgkqhkiG9w0BAQUFAANBADUd7lBe7JeQKQnKCK GddnsCXqii7EitbPuYT55M4Nn3qBgPFSG8bX9H5XBGTB4iofb3h0Y9DCqe10vc8dBM0
Do one of the following to define the LDAP entry in which the CRL will be stored.
For an existing entry, specify the DN in the LDIF file.
# entry-id: famouseCA dn: CN=famouseCA,ou=People,dc=sun,dc=com certificaterevocationlist;binary:: MIH7MIGmMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBA YTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUE tJMRwwGgYDVQQDExNEb0QgQ2xhc3MgMyBSb290IENBFw0wNzA1MDExNDMzMDNaFw0wNzA1MDExNz UzMDNaMBQwEgIBTxcNMDcwNDI3MTY1NzMzWjANBgkqhkiG9w0BAQUFAANBADUd7lBe7JeQKQnKCK GddnsCXqii7EitbPuYT55M4Nn3qBgPFSG8bX9H5XBGTB4iofb3h0Y9DCqe10vc8dBM0
For a new entry, specify the DN and object classes in the LDIF file.
# entry-id: tester200 dn: CN=famouseCA,ou=People,dc=sun,dc=com sn: famouseCA cn: famouseCA employeeNumber: 1001 telephoneNumber: 555-555-5555 postalAddress: 555 Test Drive iplanet-am-modifiable-by: cn=Top-level Admin Role,dc=iplanet,dc=com mail: famouseCA@test.com givenName: Test inetUserStatus: Active uid: tester200 objectClass: iplanet-am-user-service objectClass: inetAdmin objectClass: iPlanetPreferences objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: iplanet-am-managed-person objectClass: inetuser objectClass: top userPassword: {SSHA}E3TJ4DT7IoOLETVny1ktxUGWNTpBYq8tj3C1Sg== creatorsName: cn=puser,ou=dsame users,dc=iplanet,dc=com modifiersName: cn=puser,ou=dsame users,dc=iplanet,dc=com createTimestamp: 20031125043253Z modifyTimestamp: 20031125043253Z certificaterevocationlist;binary:: MIH7MIGmMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBA YTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUE tJMRwwGgYDVQQDExNEb0QgQ2xhc3MgMyBSb290IENBFw0wNzA1MDExNDMzMDNaFw0wNzA1MDExNz UzMDNaMBQwEgIBTxcNMDcwNDI3MTY1NzMzWjANBgkqhkiG9w0BAQUFAANBADUd7lBe7JeQKQnKCK GddnsCXqii7EitbPuYT55M4Nn3qBgPFSG8bX9H5XBGTB4iofb3h0Y9DCqe10vc8dBM0G8=
Run one of the following ldapmodify commands based on whether you are adding the LDIF file to an existing entry or creating a new entry.
To add a CRL to an existing LDAP entry (using an LDIF file with a specified DN), use the following command:
ldapmodify -r -h Directory Server_host -p Directory Server_port -f ldif-file -D cn=Directory Manager -w password
To add a CRL to a new LDAP entry (using an LDIF file with a specified DN and object classes), use the following command:
ldapmodify -a -h Directory Server_host -p Directory Server_port -f ldif-file -D cn=Directory Manager -w password