Home > Manage CAs > Local CAs

Local CAs

Configuring a CA

The local CAs configured in Manage CAs module can automatically certify the keys being generated by the certification service. The Local CAs can also certify keys which are manually generated by ADSS Server operators using the ADSS Key Manager module.

The following diagram illustrates the use of the local CA module in both cases:


Note that when business client applications request certification services, it is assumed that there are end-users that are interacting with the application. The expected scenario is that as a user registers to use the business application for the first time, the application will then request the generation of a key and certificate for this end-user so they can for example in future sign transaction data or summary documents, etc. The interaction between end-users and the business application is a matter for the application and thus outside the scope of ADSS Server. The application may use a variety of means to authenticate the user, e.g. username/password, mobile phones, one-time password, two-factor tokens, even TLS certificates.

If it is required to generate certificates as per CA/B Forum and WebTrust Guidelines, then enable following properties in Global Settings > Advanced Settings > General page:
 Enable CA validation check
 . Debian weak Keys 
​The ADSS Server Developers Guide explains the XML schema used for both the certification service request messages and certification service response messages.  It also describes Java and .Net APIs that can be used to build the client application.To configure an ADSS Server local CA, first generate (or import) a key pair for use as a 'Local CA'. The key pair must be assigned the purpose Cert/CRL Signing within the ADSS Key Manager module. The Local CA public key will then need to be certified using either a self-signed certificate or a certificate issued by higher-level CA. This Local CA can then be configured for online certification using the Manage CAs module. The following is the screen where you can configure the CAs.

By clicking the New/Edit button, the following screen will be shown where you can configure your Local CAs:

The items in the above screen are described below:

Item Description
CA Certificate Info:  Defines the following: 
Status A CA may be marked either Active or Inactive.  As suggested by its name, an Inactive CA will not be used to issue/renew/revoke certificates until its status is later changed to Active.
Mark it the default CA If selected, this identifies this Local CA as the default to be used for generating certificates within ADSS Server.
CA Friendly Name An operator-defined unique name for easy management of certificate authorities 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 CA in more detail (e.g. in which circumstances will this CA will be used). This is for information purposes only.
CA Certificate
The drop-down menu will only show the certificates within the ADSS Key Manager that have their key usage extension marked for Cert/CRL signing (i.e. Key Usage = cRLSign, keyCertSign).  These certificates are the certificates for the keys that were given a purpose of Certificate/CRL Signing when they were created by Key Manager.

Select the certificate that you want to configure as a CA. This CA 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:
  • Issue the Certificate
    Select this option if you wish to issue the target certificates beyond the CA's expiry date.

  • Use CA's Expiry Date/Time
    By selecting this option, ADSS Server will silently set the CA's expiry date (Valid To) in the target certificate (Valid To) if user provided the target certificate validity period beyond the CAs expiry date.

  • Return Error
    When this option is selected then an error message will be returned to the user if the user provided the target certificate's expiry date is beyond the CA's expiry date.
Note: If the user provides a time period for target certificate that is not beyond the CAs expiry date/time then the target certificate will be generated using the user provided date/time regardless of which option is selected.
Certificate Extensions: 
Defines the following: 

If CA/B forum and WebTrust guidlines enabled in the ADSS Server then click here for instructions to configure allowed policies for the CAs.
CDP Address (HTTP)
The address configured here will be used within the CDP extension field of certificates issued by this CA.

Currently operator can configure only one CDP address for a CA, click here for more details on configuring more than one CDP Addresses for a CA.
CDP Address (LDAP)
The address configured here will be used within the CDP extension field of certificates issued by this CA.
AIA Address (OCSP)
The address configured here will be placed within the AIA extension field of certificates issued by this CA and can be used to check the certificate revocation status over OCSP. Multiple addresses can be added by clicking on '+' button.
AIA Address (CA Issuers)
The address configured here will be placed within the AIA extension field of certificates issued by this CA.  It can be used to access certificates that were issued to this CA and other information about this CA (e.g. online validation services and CA Policy data). Multiple addresses can be added by clicking on '+' button.
Issuer Alternative Name OID (otherName)
This field is used to define the Issuer Alternative Name of type otherName. Specify the OID in the first field and its value in the second (Value) field.

Make sure that the Issuer Alternative Name checkbox is checked in the respective certificate template in order to put this extension in the issued certificate.
There are multiple scenarios by which we can define the Issuer Alternative Name of type otherName. These are as follows: 
  1. If Issuer Alternative Name OID is configured in Manage CA and also enabled in certificate template, then:
    • We can add configured Manage CA OID in issuer SAN (other SAN values retained) and put it as an IAN in end entity certificate. 
    • We can put OID and configured value in Manage CA as IAN in end entity certificate in case where there is no SAN and IAN in issuer certificate.
  2. If Issuer Alternative Name OID is not configured in Manage CA, then, we can add issuer SAN as IAN in end entity certificate as per standard.
Certificate Issuance Reporting Settings:
ADSS Server can report on the issuance and revocation of certificates. When the ADSS Server Local CA chains to an external CA e.g. GlobalSign CA then this option allows each issued and revoked certificate to be reported to the external CA e.g. GlobalSign Cert Safe service.

When this option is selected the following items are also shown:
Account Name 
The Account Name issued for this CA.
Service URL 
The Issuer CA URL i.e. Cert-Safe URL.
TLS Client Authentication
The TLS Client Certificate required for authentication with Issuer CA URL i.e. Cert-Safe service URL.
Certificate Transparency Settings:
Certificate Transparency helps identifying TLS Server certificates which have been mistakenly issued by a certification authority or maliciously acquired from an otherwise unimpeachable certification authority. This approach requires CAs to publicly publish information about their issued certificates so that anyone can check whether a certificate has been properly issued. Certificate Transparency (CT) does not stop fraudulent certificates being created, but it enables them to be quickly and easily detected. When this license controlled option is enabled for a CA, it manages the TLS Server certificates issuance and interacts with certificate transparency log servers.

When this option is selected the following items are also shown:
Log Server Address
This specify the address of a log server. Log Servers are used to store information about the issued TLS Server Certificate by a particular CA. These accept a yet to be issued certificate from a CA and return an SCT (Signed Certificate Timestamp); a proof that the certificate has been received by the Log Server.
Log Server Public Key
Log Server(s) generate the Signed Certificate Timestamp(SCT) against the CA request and log server public key is use to verify it.
List of Configured Log Servers
Set the order for the addresses of log servers where the TLS Server Certificate will be stored.
Number of SCTs required
This defines the number of log servers required to approve the request. The total number of log servers may be equal to or greater than this number. This number cannot be zero as at least one log server is required. 

In case the number is 2 or greater, then at least two log servers must provide the SCTs.
Use another CA for 
Pre-certificate Signing
By enabling this option, a pre-signing certificate can be selected from the drop down menu. The drop-down menu will only show the certificates within the ADSS Key Manager that have certificate transparency in the certificate EKU (Extended key usage extension). 

The pre-certificate is constructed from the certificate to be issued by adding a special poison extension. The pre-certificate are submitted to the log servers to get SCTs embedded in the real certificate. 
Delegate the Pre-certificate logging process to other entities
By enabling this option, ADSS CA Server delegates a client application to interact with log server instead of interacting with the log server directly. Upon receiving a TLS Server Certification request from client application, ADSS CA Server creates a pre-certificate and returns this pre-certificate and its chain along with log server information to the client in order to get the required SCT (Signed Certificate Timestamp) from the log server. The client application will log this chain with the log server to get the SCT and provide it to ADSS Server that will embed it in the original certificate and return this certificate to the client application. 

Note: This option is useful when ADSS CA Server is working in a highly secured environment and have no access to external servers. 
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 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 automatically pick-up the emergency CRLs and provide real-time certificate status information.
Hashing Algorithm Select the Hashing Algorithm that will be used as part of the CRL signing.
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.
Keep expired revoked certificates in the CRL from If this option is enabled and a time is specified, the CA will keep all the revoked certificates in the CRL that were expired at the exact time (as specified) or after that time.

ADSS supports the following extensions in a CRL: 
  1. CRL Number: It is included in the CRL by default. 
  2. AKI (Authority Key Identifier): It is included in the CRL by default. 
  3. IAN (Issuer Alternative Name): If the issuing CA has the Subject Alternative Name (SAN) extension, then that SAN will be added as Issuer Alternative Name in CRL. 
  4. ExpiredCertsOnCRL: It is included when 'Keep expired revoked certificates in the CRL from' checkbox is enabled in CRL Settings. 
LDAP Publishing Settings:
Defines the following: 

Note: OpenLDAP and Apache DS v2.0.0.AM25 are tested. 
Publish CRL in LDAP Enable this if it is required to publish the CRL on LDAP Server.
Publish Issued Certificates in LDAP Enable this if it is required to publish the Issued certificate on LDAP Server.
CRL Publishing LDAP Server
Set the LDAP Server URL e.g.
  • localhost
  • dc1.main.domain.com
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.
Set the password that will be used to authenticate the user to the LDAP server.
Publish CRL
This button provides an option to immediately manually publish a CRL to the configured file path. 

These settings can be saved by clicking the Save button.

As stated previously, the ADSS Local CA certificate may be a self-signed certificate (i.e. in this case the ADSS Local CA is a Root CA) or a delegated certificate issued by some external CA (i.e. in this case the ADSS Local CA is a Subordinate CA). The configured CA certificate can be viewed by selecting the CA and then by clicking on the View Certificate button. The configured CA certificate can be changed in edit mode to any other CA certificate having key Purpose Cert/CRL signing.

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 CA:

    {drive}:\\{installation path}\console\server\webapps\console\crls\CAname1.crl


3. Configure the following address for the CDP in the CRL Publishing Settings for the local CA:


Prerequisites to publish Certificates in an LDAP Directory
As "Distinguished Name" will be extracted dynamically from the AA certificate, so the user will not provide it. The Identity/Attribute Certificates will be published if this DN structure is present in the LDAP Directory.
OpenLDAP and Apache DS.

Issued Certificates 

By clicking on the Issued Certificate button after selecting the CA, the following screen will be displayed where all the certificates issued by this CA 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 activated 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 CA(s) only. Systems that are polling outside the ADSS Server, but using the CAs configured in ADSS Server, have to download the CRL in order the get the latest revocation information.

If a certificate got renewed then it's old certificate will be marked revoked and a new certificate will be generated, in order to check the latest and revoked certificates against a particular alias, just expand the certificate by clicking on '+' button then all the old revoked certificates will be shown as child.

​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:

By 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.

Import Certificates 

By clicking on the Import Certificates button, the following screen will be displayed where user can browse to the issued certificate(s) detail file or to certificate(s) zip file issued by the selected Local CA:

Click here for detailed instructions on how to import a CA (as Local CA) and its issued certificates into ADSS Server along with the required structure of Certificate Detail file and Certificate ZIP file:

System Properties

Clicking on the Delete button on Issued Certificates main page will generate following scenarios :

  1. To 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. 
  2. To delete the key pair and certificates from HSM a property ENABLE_PKCS11_KEY_DELETION is introduced in Global Settings > Advanced Settings > Certification. If this property is set to TRUE, the key pair and relevant certificates would be deleted from HSM. If this property is set to FALSE, the key pair and certificates would only be deleted from ADSS Server database but not from HSM. Default value for this property is TRUE.

See also