These templates define the profile of the certificates that will be issued by the ADSS Local CA (s) and ADSS Key Manager. Default templates exist for various key purposes. New templates can also be defined according to business needs.

ADSS Server also supports the ETSI Qualified Certificates extension. The term Qualified Certificate is used to describe a certificate with a certain qualified status issued in accordance with the EU Signature Directive and National Signature Laws. This means that appropriate quality levels have been satisfied both in terms of the Certification Authority issuing these certificates and the certificate issuing process itself. Furthermore, Qualified Certificates are issued exclusively to Natural and Legal persons.
 
The following screen shows the default certificate templates also indicating the purpose of each of these:


A new template can be created by clicking the New button. The templates can be viewed/updated by selecting a template by clicking the View/Update button. A Make a Copy button replicates the selected template.  



The following is a description of the above certificate template attributes.  Note that some of these attributes can be specified as overridable in the Certificate Profile - see ADSS Certification Service for details:

Items

Description

Template ID

An Operator-defined unique Template ID for easier human recognition within the ADSS Operator Console. Once a Template ID is created, it cannot be changed. 

Template Name

An Operator-defined unique name for easier human recognition within the ADSS Operator Console.

Template Description

This can be used to describe the Template in more detail. This is for information purposes only.

Certificate Purpose

It contains a list of standard certificate purposes. Select a purpose for which the certificate will be generated using this template.

Validity Period (Months)

It contains the time period that for how long a certificate will be valid from its creation date.

Signature Algorithm

This list contains a list of supported Signature Algorithms; select one of the Signature algorithm for this certificate template.

Key Usages

Key usage extensions define the purpose of the public key contained in a certificate. it can be used to restrict the public key to as few or as many operations as needed

Note: digitalSignature and nonRepudiation bits are necessary for certain type of certificates and these must be selected in those cases.

Extended Key Usages

Extended Key Usage (EKU) further refines key usage extensions. An extended key usage extension is either critical or non-critical. Critical implies that a certificate using system MUST understand and be able to process the particular attribute.

Note: The relevant EKU bit must be ON otherwise the certificate will be rejected. e.g If you are using the certificate for Timestamping then the Timestamping bit must be ON otherwise timestamps created with a certificate that have no Timestamping EKU in it, will be rejected.

NoCheck

This extension is specific to OCSP response signing certificates. IF set to TRUE then OCSP certificate revocation will not be checked by the OCSP client applications.

Certificate Extensions

Certificate extension field permits any number of additional fields to be added to the certificate. Certificate extensions provide a way of adding information such as alternative subject names and usage restrictions to certificates.

Basic Constraints Type

It contains three attributes i.e. CA, End Entity & Empty. 

  • If CA is selected then you have to specify a certificate Path Length i,e. the maximum number of intermediate CA certificates, that can be in the path from the CA to an End Entity certificate. A path length of -1 can be used to indicate that any number of CA certificates are allowable in the path.
  • If End Entity is selected then the Path Length field will be disabled because there is no path length in the End Entity certificate.
  • If Empty is selected, basic constraint extension will not be the part of issued certificate

Authority Key Identifier (AKI)

Authority Key Identifier (AKI) extension adds the hash of the issuer's public key in the target certificate.

Subject Key Identifier (SKI)

Subject Key Identifier (SKI) extension adds the hash of the issued public key in the target certificate.

CRL Distribution Point (CDP)

A CRL (Certificate Revocation List) Distribution Point identifies where CRLs for the certificate can be downloaded. CDP addresses can be configured in the module Manage CA(s).

Authority Information Access (AIA)

Authority Information Access (AIA) is a certificate extension that contains information useful for verifying the trust status of a certificate. This information potentially includes Uniform Resource Locators (URLs) where the issuing CA’s certificate can be retrieved, as well as a location of an Online Certificate Status Protocol (OCSP) responder configured to provide status for the certificate in question. The AIA extension can potentially contain HTTP, LDAP, or file URLs. The AIA address  can be configured in the module Manage CA(s).

Issuer Alternative Name

If the issuing CA has the Subject Alternative Name (SAN) extension, then those SAN will be added as Issuer Alternative Name in the CRL which are enabled in its certificate template.

For example, if iPAddress and directoryName are enabled in SAN extension, then it will be added as Issuer Alternative Name in the CRL. 

Subject Alternative Name

The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an internet electronic mail address, and DNS name. Other options exist, including completely local definitions. Multiple name forms, and multiple instances of each name form, may be included.


rfc822Name:
Check this option if you want to bind the email address(s) with the certificate as an alternative extension. Here are the business rules:

  • If rfc822Name option is checked and a PKCS#10 is received in the request and it contains the subject alternative name extension with rfc822Name then all electronic mail addresses found in PKCS#10 will be bound to this certificate. Email addresses found in the distinguished name will be skipped.
  • If rfc822Name option is checked and a PKCS#10 is received in the request and it does not contain the rfc822Name extension but distinguished name contains the email addresses then all email addresses found from the DN will be bound to the certificate.
  • If rfc822Name option is checked and only DN is provided in the certificate request then then all email addresses found in the DN will be bound to the certificate.


dNSName:
Check this option if you want to bind the domain name address(s) with the certificate as an alternative extension. Here are the business rules:

  • If dNSName option is checked and a PKCS#10 is received in the request and it contains the subject alternative name extension with dNSName then all domain names found in PKCS#10 will be bound to this certificate. dNSName names found in the distinguished name will be skipped.
  • If dNSName option is checked and a PKCS#10 is received in the request and it does not contain the dNSName extension but distinguished name contains the CN then all common names like (.com, .org, .net etc) will be bound to the certificate. Plain common names (John Doe, Joseph Smith etc) will not be bound as dnsName.
  • If dNSName option is checked and only DN is provided in the certificate request and distinguished name contains the CN then all common names like (.com, .org, .net etc) will be bound to the certificate. Plain common names (John Doe, Joseph Smith etc) will not be bound as dnsName.


iPAddress:
Check this option if you want to bind the IP address(s) with the certificate as an alternative extension. Here is the business rule:

  • If iPAddress option is checked and a PKCS#10 is received in the request and it contains the subject alternative name extension with iPAddress then all IP address(s)found in PKCS#10 will be bound to this certificate. iPAddress names found in the distinguished name will be skipped.


otherName:
Check this option if you want to bind any custom value as an alternative extension. The otherName OID entries provided by the RA in the certificate request message are used in the generated certificate. Here is the business rule:

  • PKCS#10 MUST contain the otherName as a key pair value to bind any custom value with the certificate.


directoryName:
Check this option if you want to bind directory name(es) with the certificate as an alternative extension. Here is the business rule:

  • If directoryName option is checked and a PKCS#10 is received in the request and it contains the subject alternative name extension with directoryName then all Directory Name(s) found in PKCS#10 will be bound to this certificate.

Name Constraints

The Name constraint option will only be visible if 'CA' attribute is selected in 'Basic Constraint' drop down. The Name Constraint extension is used in CA certificates which specifies those constraints which will apply on Subject DN and Subject Alternative Names of subsequent certificates in CA path. These Constraints can be applied in the form of Permitted and Excluded name list ,where at least one list i.e. permitted or excluded must be present in the extension. 


Permitted Names:

If a constraint is stated in permitted names list, the subsequent certificates should comply with this list and must contain only those names in their Subject DN and Subject Alternative Name (SAN) which are permitted. Following options are available in Permitted Name List.

  • rfc822Name
  • dNSName
  • iPAddress
  • Directory Name


Excluded Names:

If a constraint is stated in excluded names list, then the subsequent certificates must not have those names in their Subject DN and Subject Alternative Name (SAN). Following options are available in Excluded Name List.

  • rfc822Name
  • dNSName
  • iPAddress
  • Directory Name

Private Key Usage Period

This field indicates the period of the use of private key corresponding to the certified public key. The operator can select the time period (i.e. days, months, years) from the drop-down and enter the required number in the field. 

Name Change

This extension is used in a CSCA and its link certificates used in an E-Passport infrastructure. It is only visible if you have the E-Passport license and if CSCA Certificate is selected in Certificate Purpose drop-down field. By enabling this extension, the operator can change Distinguished Name (DN) while rekey of a CSCA certificate.


It is recommended that Subject DN of a CSCA certificate should not be changed unnecessarily as it can have adverse effect on relaying parties..


Document Type

This extension is added to Document Signer (DS) certificates in an E-Passport infrastructure. It is visible only if you have the E-Passport license and if DS Certificate is selected in Certificate Purpose drop-down field. It is a mandatory field for a DS Certificate and operator can enter the document type in this field e.g. "P" for passport. 

Multiple document types can be added as comma-separated list in the Document Type field where each document type can contain a maximum of one or two letters.

Custom Extensions

Custom Extensions can be added in the certificates generated by the ADSS Server. In Certificate Template one or more custom extensions can be configured. At the time of certificate generation, if the CSR contains any custom extensions, then it must match with the OID's configured in certification template. If they match the extensions will be added in the certificate, otherwise custom extensions received in CSR will be ignored.  

Extension OID:

The OID of extension will be provided in 'Extension OID' field and can be added in List of Extensions by clicking the Add button. The extension can be marked as critical or non-critical by checking Critical checkbox. 

List of Extension:

Extensions added in the template will be displayed in this field. Any extension can be removed from the list by clicking on the Remove button. 

Certificate Policies

The Certificate Policies extension defines one or more policies, each of which consists of an OID and optional qualifiers. The extension can include a URI to the issuer's Certificate Practice Statement or can embed issuer information, such as a user notice in text form. The Certificate Policy provides the information that can be used by a certificate user to decide whether or not to trust a certificate. Certificate policies are also used to establish trust relationships between CAs (i.e. cross certification). When CAs issue cross certificates, one CA assesses and recognizes one or more certificate polices of the other CA.

Currently operator can configure only two certificate polices, click here for more details on configuring more than two certificate policies.


Qualified Certificate Statements

Defines unambiguous identification of the EU Qualified Certificate type of the end user for QES (Qualified Electronic Signatures) creation by means of OID in QCStatements in accordance with IETF RFC 3739 and especially with ETSI EN 319 412-1. This allows the configuration of various aspects of the ETSI Qualified Certificate profile statements, i.e. this is a qualified certificate, Semantics Information, PKI Disclosure Statements, transaction value limit, CA retention period and whether the private key held on a Secure Signature Creation Device (SSCD), typically an evaluated smart card that has achieved a particular security assurance level.

Semantics Information:
Defines an identifier about the semantics of data stored in the certificate i.e. whether the certificate is issued to a natural person or legal person: 

  • Natural person semantics Identifier (0.4.0.194121.1.1)
  • Legal person semantics Identifier (0.4.0.194121.1.2)

When enabled, ADSS CA Server automatically adds the semantic identifier based on the selected configuration i.e. Natural or Legal Person

Private key resides in Secure Signature Creation Service (SSCD):
Defines an Identifier (represented by an OID), made by the CA, stating that the private key associated with the public key in the certificate is stored in a Secure Signature Creation Device according to Annex III of the EU Directive 1999/93/EC [1], as implemented in the law of the country where the CA is established. The private key cannot be exported from the secure device and is under a sole control of a person to whom the qualified certificate was issued.

Transaction Limit:
This impose a limitation on the value of transaction for which this certificate can be used to the specified amount (Monetary Value). Alphabetic or numeric currency code can be used as defined in ISO 4217.

CA Retention Period:
Defines a retention period in years for material information relevant to the use of and reliance on the certificate, that will be archived and can be made available upon request beyond the end of the validity period of the certificate.

PKI Disclosure Statements (PDS):
Defines the URL for the PDS document (a supplemental instrument of disclosure and notice by CA) and language code for this PDF document as defined in ISO 639-1. PDS document is intended to provide PKI participants (subscribers and relying parties) with a short extract of Qualified Certificates for Electronic Seals PKI policy documentation which focuses on key information of interest to users. It assists CA to respond to regulatory requirements and concerns, particularly those related to consumer deployment. Multiple PDS URLs and language codes can be added by using the + button. 

Qualified Certificate of a particular type
Defines the type of qualified certificate i.e. 

  • Certificate for electronic signatures
  • Certificate for electronic seals
  • Certificate for website authentication

This type is used in combination with the Semantic Identifier selected above i.e. Certificate for Electronic Signature used by Natural Person.

ADSS CA Server uses the Qualified Certificate Statements to issue EU Compliant Qualified Certificate. It only checks the following before issuing different qualified certificate types:


When the natural person semantics identifier is included, any serialNumber attribute in the subject field must be present and must contain information defined in ETSI EN 319 412-1 e.g. PASSK-P3000180


When the legal person semantics identifier is included, any organizationIdentifier attribute in the subject field must be present and must contain information defined in ETSI EN 319 412-1 e.g. VATBE-0876866142.


NetScape Certificate Type

Netscape has defined certain certificate extensions for its products. Some of the extensions are now obsolete, and others have been superseded by the extensions defined in the X.509 standard.


Note that the ADSS local CA and Key Manager will use the relevant certificate template when certifying a particular public key. These modules will determine which template to use by identifying the purpose of the key pair and then using the relevant certificate template for that key purpose.


Copy of a Certificate Template is created without the Name and Description and ID of a selected Certificate Template.


Refer to RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, for a further discussion on the above certificate attributes and recommendations for whether these should be marked as 'critical' or 'non-critical'. Critical implies that a certificate using system MUST understand and be able to process the particular attribute.



See also 

Configuring the Certification Service
Directory Integration
Identity Certificates

Attribute Certificates
CV Certificate
CV Certificate Templates
Transactions Log Viewer
Logs Archiving
Alerts
Management Reporting
Optimising ADSS Certification Server Performance
Certification Service Interface URLs