To generate a new key press the New button in the main Service Keys page. A form is presented:

The configuration items are as follows:

Items

Description

Key Alias

Define a name (alias) for the new key. This name has to be unique within the ADSS system.

If the Crypto source is Azure Key Vault HSM, then only these characters are supported for key alias:

A-Z, a-z, 0-9 and hyphen "-".

Purpose

Select the certificate purpose for this key pair. The list of certificate purposes is populated based on the certificate templates generated in the Certificate Templates area. A list of default certificate purposes certificate templates is shown below:
Attribute Authority - used to create an Attribute Authority to be configured in the list of Local Attribute Authorities in Manage CAs module.  Local Attribute Authority will issue attribute certificates through the ADSS Certification Service.

Document Signing – used in the ADSS Signing Service (e.g. for signing documents as part of Watched Folder mode signing)

Code Signing – used to digitally sign source code of different applications

EV Code Signing – It is Extended Validation Code Signing which includes all the benefits of standard code signing with rigorous vetting process. 

Verification Response Signing – for signing ADSS Verification Service Response messages

OCSP Request Signing – used by ADSS Server for signing OCSP request messages sent to an OCSP responder 

OCSP Response Signing – used for signing ADSS OCSP Service Response messages

When operating in FIPS 201 compliant mode, the ADSS Server operator must ensure that the length of the OCSP response signing key must be at least as large as, or larger than, the key length used by the CA that issued the target certificate (i.e. certificate being validated) 

TLS Client Authentication Template – used by ADSS Server for TLS client authentication when communicating with other service providers.

TLS Server Authentication – used by ADSS Server for TLS server authentication (e.g. when communicating with client applications)

EV TLS Server Authentication – It is Extended Validation version for TLS Server Authentication with more rigorous authentication process.  

TLS Client Authentication – used by ADSS Server for TLS client authentication while communicating with other applications over TLS. 

Cert/CRL Signing – used to issue certificates/CRLs, this key can be selected for use as the ADSS Local CA key

CSCA Certificate – Its a root certificate in an E-Passport infrastructure that issues Document Signer, Master List Signer and other certificates. 

DS Certificate – It is used to compute signature over personal and bio-metric data held on E-Passport chips. 

RA Certificate – used by RA Service clients (devices) to encrypt the PKCS#10/CSR requests before sending them to RA Service over SCEP. 

Log Signing – used for signing log records

Timestamp Response Signing – used for signing ADSS Timestamp Service Response messages

XKMS Response Signing – used for signing ADSS XKMS Service Response messages

XKMS Request Signing – used for signing ADSS XKMS Service Request messages

SCVP Response Signing – used for signing ADSS SCVP Service Response messages

When operating in FIPS 201 compliant mode, the ADSS Server operator must ensure that the length of the SCVP response signing key must be at least as large as, or larger than, the key length used by the CA that issued the target certificate (i.e. certificate being validated).

SCVP Request Signing  – used for signing ADSS SCVP Service Request messages

Master List Signing – It is used to sign the master lists that contain CSCA and link certificates. 

DRM Agent – used for DRM Agent certificates

Rights Issuer – used for Rights Issuer certificates

IP Sec Signing  – used for IPSec Signing certificates

Code Signing – used for code signing certficates

Email Signing – used for email signing certificates.

Document Encryption - used for document encryption certificates, e.g. used by Go>Sign applet to encrypt data for later decryption by the ADSS Decryption Service

Qualified Certificates - used for generating qualified certificates according to the ETSI Qualified Certificate Profile (ETSI TS 101 862).

Key Encryption Key (KEK) - used for encrypting the keys

Data Encryption Key (DEK) - used for encrypting the data 

HMAC Key - used for generating an HMAC key used for protecting database records within the ADSS Server database to ensure system integrity.

Country Verifying CA (CVCA) – it is a root CA of a country in an E-Passport (Extended Access Control) infrastructure that is used to issue certificates to Document Verifiers. 

Document Verifying CA (DVCA) – These are sub-CAs that issue certificates to Inspection Systems in an E-Passport infrastructure. 

Crypto Profile ID

Select whether to generate and store this key within the ADSS Server database (software mode), Azure Key Vault or to store the key on a hardware security module (HSM) preconfigured within ADSS Server Key Manager as described in the section Crypto Processor Settings.

When a configured hardware crypto profile is Not Available in the ADSS Server Key Manager (i.e. record is shown with orange highlighting) then the relevant crypto profile will not be available here for configurations.

Algorithm

Select the Key Algorithm to be used:

  • RSA
  • ECDSA
  • GOST

Note:

  • For HMAC keys HmacSHA1, HmacSHA256, HmacSHA384, HmacSHA512 or HmacMD5 can be selected.
  • Click here for more details on limitations when ECDSA Key Algorithm is used.

Curve Type

This drop-down allows the operator to select the required curve type to be applied on the key. ADSS Server supports the following curve type: 

  • NIST P
  • SEC2 K
  • Brainpool R
  • Brainpool T

Note:

  • The Curve Type drop-down will be available only when ECDSA algorithm is selected in key algorithm field.
  • Utimaco CryptoServer CP5 HSM does not support SEC2 K curve type.
  • For TLS Server Authentication certificate, only NIST P curve type is supported.

Key Length

Select the key length to be used:

  • The choices for RSA keys are: 1024, 2048, 3072, 4096 and 8192.
  • The choices for ECDSA keys in terms of their respective curve types are:
    • For NIST P: 160, 192, 224, 256, 384 and 521

Note: While creating a TLS Server Authentication certificate in case of NIST P, only 256, 384 and 521 key lengths are supported.

    • For SEC2 K: 256
    • For Brainpool R & Brainpool T: 160, 192, 224, 256, 320, 384 and 512.

Note:

  • In case of E-Passport certificate purposes CVCA or DVCA, following key lengths are supported:
    • For RSA keys: 1024, 1280, 1536, 2048 and 3072
    • For ECDSA keys: NIST P, SEC2 K, Brainpool R and Brainpool T key lengths are supported as mentioned above
  • In case of Azure Key Vault, following key lengths are supported:
    • For RSA keys: 2048, 3072 and 4096 
    • For ECDSA keys: 256, 384 and 521 (only NIST P curve)
  • In case of AWS CloudHSM, following key lengths are supported:
    • For RSA keys: 2048, 3072 and 4096
    • For ECDSA keys: 256 and 384 (only NIST P curve)
  • In case of S/MIME key type, consider the following points:
    • For RSA key pairs, the Certificate Authority (CA) must:
      • Ensure that the modulus size is at least 2048 bits when encoded.
      • Verify that the modulus size, in bits, is evenly divisible by 8.
    • For ECDSA key pairs, the CA must:
      • Confirm that the key represents a valid point on one of the NIST curves: P-256, P-384, or P-521
  • The ECDSA NIST P 521 key length (supported in ADSS Server) cannot be used in Google Chrome and Microsoft Edge due to browser limitation. Currently it's only supported in Firefox
  • This is greyed out for HMAC keys.
  • Support for additional key lengths can be made available upon request - contact sales@ascertia.com.

Description

This should be used to describe the key purpose in more detail (e.g. in which circumstances this key will be used and/or what sort of template the key is assigned, which applications use it etc). This is for information purposes only and avoids operational management issues on systems with lots of keys.

Allow the private key to be exported later

If this option is selected then the private key and associated certificates as a PKCS#12/PFX file can be exported later. This option is only available if you are using software mode, since most HSMs tightly control the export of private keys. This option is disable in case of Azure Key Vault.


As many keys as are needed can be created for a particular key purpose. For certain purposes only one key can be used at any one time, e.g. although many TLS Server Authentication key/certificates can exist only one can be used when an TLS session is established. This key/cert is identified in global settings.

Once the key pair is generated, it is shown in the main Key Manager table where all the important details of the key are displayed.

See also

Creating New Keys

Importing Keys
Creating Certificates
Creating CV Certificates
Searching Keys
5 Ways to Create Certificates