Local AAs
The Attribute authorities configured in Manage CAs module can automatically certify the keys being generated by the certification service.
To configure the ADSS AA Service, first generate (or import) a key pair for use as a 'Local AA'. The key pair must be assigned the purpose Attribute Authority within the ADSS Key Manager module. The Local AA public key will then need to be certified using either a self-signed certificate or a certificate issued by higher-level AA. This Local AA can then be configured for online certification using the Manage CAs module. The following is the screen where you can configure the AA(s).
By clicking the New/Edit button, the following screen will be shown where you can configure your Local AA(s).
The items in the above screen are described below:
| Item | Description |
| AA Certificate Info: | Defines the following: |
| Status |
An AA may be marked either Active or Inactive. As suggested by its name, an Inactive AA will not be used to issue/renew/revoke certificates until its status is later changed to Active. |
| Mark it the default AA |
If selected, this identifies this Local AA as the default to be used for generating certificates within ADSS Server |
| AA Friendly Name |
An operator-defined unique name for easy management of AA within ADSS Server. This is only for human identification purposes and not used within the certification request/response messages. |
| Description |
This can be used to describe the AA in more detail (e.g. in which circumstances will this AA will be used). This is for information purposes only. |
| AA Certificate | The drop-down menu will only show the certificates within the ADSS Key Manager that have their key usage extension marked for attribute Cert/CRL signing (i.e. Key Usage = digitalSignature, nonRepudiation, keyEncipherment). These certificates are the certificates for the keys that were given a purpose of Attribute Authority when they were created by Key Manager. Select the certificate that you want to configure as a AA. This AA will be used as the Certificate and CRL issuer. |
| Certificate Validity Settings |
This option is used to define the validity time/date procedure of a certificate according to the issuer's certificate validity date/time. The possible values are:
|
| Certificate Extensions: |
Defines the following: |
| CDP Address (HTTP) |
The address configured here will be used within the CDP extension field of certificates issued by this AA. |
| CDP Address (LDAP) |
The address configured here will be used within the CDP extension field of certificates issued by this AA. |
| AIA Address (OCSP) |
The address configured here will be placed within the AIA extension field of certificates issued by this AA and can be used to check the certificate revocation status over OCSP. |
| AIA Address (AA Cert) |
The address configured here will be placed within the AIA extension field of certificates issued by this AA. It can be used to access certificates that were issued to this AA and other information about this AA (e.g. online validation services and AA Policy data) |
| CRL Settings: | Defines the following: |
| CRL Validity Period | Specify the time in minutes to calculate the CRL validity period (Next Update). |
| Generate and Publish CRL Automatically |
If this checkbox is enabled then the target AA will publish its CRL automatically at the end of the CRL Publishing Period. |
| CRL Publishing Period |
Specify the time in minutes after which the CRL will be published. This time must be less than the value specified in the "CRL Validity Period" field. |
| Publish Emergency CRLs |
Emergency CRLs are published immediately when a revocation/reinstatement event occurs rather than waiting for the next scheduled CRL e.g. when a certificate is revoked, an emergency CRL is published so that latest information is available to the CRL and OCSP responders. The ADSS OCSP Service can be set to poll for emergency CRLs and provide real-time certificate status information from these. |
| Hashing Algorithm |
Select the Hash Algorithm to be used when signing the CRL. |
| CRL Publishing File Path |
This is the path to the location where published CRLs will be stored. This is a mandatory field if one of the above check boxes are checked as you have to specify the address in the file system where you want to publish the CRL. Otherwise the field is optional. |
| LDAP Publishing Settings: | Sets the address of the LDAP server where the CRL and issued certificates will be published if these options are selected. When selected the following options are shown: |
| CRL Publishing LDAP Server |
Set the LDAP Server URL e.g. LDAP://dc1.main.domain.com/ |
| Port |
Set the port number of the LDAP server. The default port is 10389. |
| Bind DN/User |
Set the username or Distinguished name (DN) that will be used to login to the LDAP server. |
| Password |
Write the password that will be used to authenticate the user on the LDAP server |
| [Button] Publish CRL |
This button provides a facility to immediately manually publish a CRL to the configured file path. |
These settings can be saved by clicking the Save button.
The ADSS Local AA certificate may be a self-signed certificate (i.e. in this case the ADSS Local AA is a Root AA) or a delegated certificate issued by some external AA (i.e. in this case the ADSS Local AA is a Subordinate AA). The configured AA certificate can be viewed by selecting the AA and then by clicking on the View Certificate button. The configured AA certificate can be changed in edit mode to any other AA certificate having key purpose Attribute Authority.
Configuring CRL Publishing Location using Tomcat
If you wish to create a CRL publishing location and immediately access this within different ADSS Server services then this can be done using Tomcat. This is recommended only for test purposes. For production systems an external web accessible folder is recommended.
1. Create a directory for CRLs at the following location within the ADSS Server installation area:
{drive}:\\{installation path}\console\server\webapps\console\crls
2. Configure this path in the CRL Publishing settings for the local AA:
{drive}:\\{installation path}\console\server\webapps\console\crls\AAname1.crl
3. Configure the following address for the CDP in the CRL Publishing Settings for the local AA:
Prerequisites to publish Attribute Certificates in an LDAP Directory
- Custom Partitions in LDAP: The partitions in LDAP directory should contain an entry/hierarchy similar to the Certificate's RDN Structure.
- Issuer Certificate DN: To publish Attribute Certificate with a BaseCertID, the Issuer Certificate/CRL must be published on its RDN partition of LDAP Directory.
- ExtensibleObject Class: This objectclass is defined in RFC 2252 to allow flexibility of adding and modifying attributes on the LDAP Server. The extensibleObject object class must be a part of LDAP schema of LDAP Server. The objectClass (extensibleObject) optionally hold all supported attributeTypes defined in LDAP schema of LDAP Server. ExtensibleObject Class is by default supported in LDAP release 3.
- attribute_cert_pmi Schema: LDAP Server doesn't support few attributes and object classes, attribute_cert_pmi schema defines the "attributeCertificate" attribute type which is required to publish the Attribute Certificates on the LDAP Directory. To import the schema/ldif file in configured LDAP Server, get the zip file "attribute_cert_pmi" from the path given below, [ADSS-Server-Installation-Dir]\support\attribute_cert_pmi.zip
By clicking on the Issued Certificate button after selecting the AA, the following screen will be displayed where all the certificates issued by this AA are shown:
This screen shows certificates issued by Key Manager, Certification Service and Manual Certification while the Certification Service's Issued Certificate sub module only shows the certificates issued by the Certification Service.You can select a certificate, and then either View, Revoke or Delete it. A certificate revoked with the certificateHold instruction code can be reinstated later on by using the Reinstate button. Once a certificate is revoked, an instant revocation entry will be made in the database instead of issuing an emergency CRL on each revocation. Publishing CRLs is costly if they are published too frequently. To decrease the cost of resources, the idea of instant revocation is introduced. It works for the locally configured AA(s) only. Systems that are polling outside the ADSS Server, but using the AAs configured in ADSS Server, have to download the CRL in order the get the latest revocation information.
If an issued certificate is required to be deleted and the same certificate alias is required to be used for the new certificate then operator need to restart the ADSS Core, Console and Service instances from Windows NT Services panel or UNIX daemon.
You can select a certificate, and then either View, Revoke or Delete it. Clicking on Revoke button will show the following screen where invalidity date, revocation code and hold instruction code can be provided before revoking the certificate:
Clicking on the Search button on Issued Certificates main page will display following screen:
If "_" character is used in the search then it will act as wildcard.
System Properties
Clicking on the Delete button on Issued Certificates main page will delete valid certificates i.e. with status (Valid, Revoked, NotYetValid). A new property ENABLE_VALID_CERTIFICATE_DELETION is introduced in Global Settings > Advanced Settings > General. When this property is set to true the ADSS Server will delete any certificate irrespective of its status. If this property is set to FALSE, only expired certificates would be deleted and it also serves the backward compatibility. The default value of this property is TRUE.If a certificate deletion request comes through certification service interface, ADSS Server will check ENABLE_VALID_CERTIFICATE_DELETION property first and decide to take actions according to the value of the property.
See also