Certificate Templates
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:
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.
|
| 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:
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:
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:
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:
directoryName:
Check this option if you want to bind directory name(es) with the certificate as an alternative extension. Here is the business rule:
|
| 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.
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.
|
| 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:
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.
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