X.509 certificate

A typical X.509 certificate contains the following elements (this is a non-exhaustive list):

Public Key
Subject
Email address
Issuer
Serial Number
Not Before
Not After
Key Usage
Extended Key Usage

Some of the main elements of an X.509 certificate will be discussed.

Public Key

The public key is the key that external recipients use to validate a signature. A public key is the non-secret part of a key pair and is associated with a private key. If a message should be encrypted, the public key of the recipient is used for encryption. The public key is also used to verify a digital signature.

Subject

The subject of a certificate contains the name of the “owner” of the certificate and optionally an email address (or sometimes multiple email addresses).

Email address

The email address for which the certificate was issued. A certificate can contain multiple email addresses.

Issuer

The issuer contains the subject name of the issuer of this certificate. The issuer and subject of a root certificate are normally equal because root certificates are normally self-signed.

Serial Number

Every certificate should have a serial number. The serial number should be unique for the issuer, i.e., an issuer should never issue a new certificate with the same serial number. The combination of issuer and serial number uniquely identifies a certificate.

Not Before

The date before which the certificate is not yet valid.

Not After

The date after which the certificate is no longer valid.

Key Usage

A public/private key can be used for multiple purposes. For example a private key can be used for signing or for decryption. Sometimes however the issuer of the certificate wants to restrict the key usage. The following key usages are available:

digitalSignature
nonRepudiation
keyEncipherment
dataEncipherment
keyAgreement
keyCertSign
CRLSign
encipherOnly
decipherOnly

If the key usage is not specified, the key may be used for all purposes. For S/MIME encryption, if a key usage is specified, it should at minimal contain “keyEncipherment”. For S/MIME signing, if a key usage is specified, it should at minimal contain “digitalSignature” or “nonRepudiation”.

Note

“Non repudiation” is a stronger form of “Digital signature”. Normally a certificate with the “nonRepudiation” flag set, should be a qualified certificate and stored on a secure device, like a smart card.

Extended Key Usage

The extended key usage, if specified, further specifies for what purposes the certificate has been issued. The following extended key usages are available:

anyKeyUsage
serverAuth
clientAuth
codeSigning
emailProtection
timeStamping
OCSPSigning
IPSecEndSystem
IPSecUser
IPSecTunnel
smartcardLogin

If the extended key usage is not specified, the key may be used for all purposes. For S/MIME, if an extended key usage is specified, it should at minimal contain “anyKeyUsage” or “emailProtection”.

Thumbprint

The thumbprint is not part of an X.509 certificate but is computed from the certificate. The thumbprint is the cryptographic hash, for example SHA256, calculated over the bytes of the encoded certificate. The thumbprint uniquely identifies a certificate.

Certificate store

The certificate store contains all the end-user and intermediate certificates. End-user certificates used for signing and decryption, typically issued to internal users, have an associated private key. New certificates or keys can be imported into the certificate store. Certificate files (p7b, cer or pem) can be imported by clicking Import certificates. Files containing private keys (pfx or p12) can be imported by clicking Import keys.

A certificate can be valid, invalid or revoked. By clicking the certificate Subject field, the details of the certificate can be viewed. If a certificate is not trusted, the certificate “Info” field should provide more information about why a certificate is not trusted.

Root store

The root store contains all the trusted CA root certificates. By default the gateway comes with no root certificates installed. New root certificates can be imported by clicking Import certificates.

Tip

A default set of system trusted root certificates can be imported by running the “Encryption settings wizard”

Revocation checking

If a certificate is compromised, or a certificate should no longer be used for whatever reason, the certificate should be revoked. Certificates can be revoked by putting the certificates on a “Certificate Revocation List” (CRL). A CRL is issued by a certificate authority (CA) and is periodically updated. After a certificate is revoked, it should no longer be used.

Note

The gateway periodically scans (by default every 6 hours), the list of CA certificates for CRL distribution points and then tries to download a CRL from the URL defined in the CRL distribution points. If a new CRL is downloaded it is stored in the CRL store replacing the old CRL.

Alternatively if a certificate was issued by a CA for which there is no CRL a certificate can be “black listed” by placing the certificate on the “Certificate Trust List” (CTL).

Certificate selection

The gateway will automatically select the correct certificates for signing and encryption. Only certificates that are valid, i.e., trusted, not expired, not revoked etc., are automatically used. This requires that certificates are trusted by a root certificate and that the root certificate is installed into the root store.

By default the root certificate store does not contain any certificates. The administrator should therefore add all the root certificates trusted by the organization to the root store. If a root certificate is not available, or installing a root certificate is not allowed, an individual end-user certificate can be “white listed” by placing the certificate on the “Certificate Trust List” (CTL).

Color coding

The selected certificates are color coded based on validity and inheritance of the certificates.

Encryption certificate selection

Encryption certificates can be selected for a user or for a domain. The “Select encryption certificates” page can be opened by clicking the select encryption certificates from the S/MIME pull-down menu on the preference page. The “Select encryption certificates” page shows all the certificates that have been selected for the user or for a domain. By default only certificates with matching email addresses will be show.

Filter by: Only shows certificates that match the filter. If “No filter” is selected, all certificates will be shown. If editing the encryption certificates for a user, the filter is by default set to the email address of the user. If editing the encryption certificates for a domain, “No filter” is selected by default.
Expired: If set to “Show all”, expired and non-expired certificates will be shown. If set to “Unexpired only”, only certificates which are not expired will be shown. If set to “Expired only”, only certificates which are expired will be shown.
Allow missing key alias: If set, certificates for which there are private keys and certificates for which there are no private keys will be shown. If not set, only certificates for which there is a private key will be shown.

Each user can have an unlimited number of associated certificates. The system tries to automatically select the certificates for a user based on strict PKI rules. The certificate will only be automatically selected if the email addresses matches the email address from the certificate. If a certificate is not automatically selected, for example the email address in the certificate does not match the email address of the user, the administrator can force the usage of a certificate by manually selecting the certificate for this particular user.

If an email must be S/MIME encrypted, all of the selected certificates for the recipient will be used. This allows the recipient to open the email with one of the associated private keys. The main advantage of using all of the selected certificates is that it allows the recipient to use different keys for decryption. For example, the key stored on the recipients home computer can be used when the email is opened from the home computer and the key on the office computer can be used when the message is read from the office.

Certificates can be manually selected and deselected by selecting the certificate checkbox and clicking Apply. Automatically selected certificates cannot be deselected. The certificate can be completely removed if the certificate is no longer required. Alternatively you can deselect the advanced S/MIME setting “Auto select certificates” for the user if automatic selection of certificates for the user is unwanted.

Even if a certificate is manually selected, it does not automatically mean that the certificate will be used for encryption. A certificate which is not valid, will not be used even if it is selected. A manually selected certificate which is not valid should be made valid. How this should be done depends on why the certificate is not trusted. If the certificate is not trusted because the chain is not valid, the root and intermediate certificates should be imported. If for whatever reason the certificate chain cannot be completed, alternatively the certificate can be white-listed by placing the certificate on the CTL.

Signing certificate selection

A signing certificate can be selected for a user or a domain. The “Select signing certificate” page can be opened by clicking the Select signing certificate from the S/MIME pull-down menu on the preference page. The “Select signing certificate” page shows the signing certificate that has been selected for the user or for a domain. By default only certificates with matching email addresses will be show.

Only certificates with an associated private key can be selected and only one signing certificate per user can be selected at the same time. The system tries to automatically select a signing certificate by searching for a valid certificate with a matching email address. If there are multiple certificates suitable for signing, the first certificate found will be selected. The administrator can override the automatically selected certificate by manually selecting another certificate. If a certificate was manually selected the selected certificate can be reverted back to an automatically selected certificate by clicking Auto select certificate.

Additional certificates

An encrypted email can only be decryped with a correct private key, i.e., the private key that belongs to the public key which was used for encryption. If email is archived after it has been encrypted, it can happen that the email cannot be decrypted when retrieved from the archive. For example if an email is sent to an external recipient, the gateway will only encrypt the email with the certificate of the recipient. To solve this issue the gateway can be configured to always encrypt with an additional encryption certificate for which the company has the private key. This can also be helpful if a company policy dictates that all encrypted email should be readable even when the sender and or recipient no longer have access to the private key (key escrow). Another reason to encrypt the data with an additional encryption certificate is that it allows a centralized virus scanner to scan the email.

Additional certificates can be selected by clicking Additional certificates on the global preference page or from the “Select encryption certificates” page for a user or domain. Additional certificates are inherited just like regular encryption certificates and can be selected for the global settings, the domain settings or for a user.

Note

Anyone with access to the private key of the additional certificate(s) can in principle decrypt all encrypted email. The private keys of the additional certificates should therefore be stored in a safe place and only be used when required.

CRL

A Certificate Revocation List (CRL) is a list of certificates which have been revoked and which should therefore no longer be used. Most Certificate Authorities (CA) allow CRLs to be downloaded from the Internet using HTTP or LDAP. The URLs from which the CRLs can be downloaded are published in a certificates as a “CRL distribution points” extension. The gateway periodically scans all certificates every 6 hours for CRL distribution points and tries to download the CRLs from the URLs. The downloaded CRLs are stored in the CRL store. A CRL update scan can be manually forced by clicking Update CRL store.

CRL details can be viewed by clicking the CRL Issuer field from the CRLs page. CRLs which are not valid (incorrectly signed, no path to a trusted root etc.) are shown with a gray background. The details page provides more information on why a CRL is not valid.

CTL

A Certificate Trust List (CTL) is a list of certificates which are explicitly trusted, i.e., “White listed” or explicitly untrusted, i.e., “Black listed”. A certificate can be manually added or removed from the CTL. A certificate on the CTL is identified by the SHA512 thumbprint of the certificate.

Note

A CTL entry does not directly contains a certificate. It contains the SHA512 thumbprint of a certificate. The reason for this is that it should be possible to white-list or black-list a certificate even if the certificate is not available in the certificate store.

In most cases PKI is sufficient for deciding whether or not a certificate is valid. Sometimes however, inferring trust using PKI rules is not sufficient.

Examples when the CTL can be helpful:

A certificate should no longer be used because it was compromised. However the CA does not publish a CRL. In this case the certificate can be black-listed using the CTL.
A certificate is not valid because the root is missing. The administrator however knows that the certificate is valid (for example the thumbprint has been checked over the phone). In this case the certificate can be white-listed using the CTL.

The CTL page can be opened by clicking Trust List on the left hand side menu of the certificates page. A new entry can be added to the CTL by Add Entry on the left hand side menu of the CTL page.

Thumbprint: The SHA512 thumbprint of the certificate.
Status: Select “Whitelisted” or “Blacklisted”.
Allow expired: If set, the CTL is considered to be valid even if expired. “Allow expired” is only applicable when white-listing a certificate.

CTL inheritance

Black-listing a certificate is inherited by certificates issued by that certificate (assuming the certificate is a CA certificate). This means that if an intermediate certificate is black-listed all certificates, directly or indirectly, issued by that intermediate certificate are also black-listed. White-listing is not inherited. If an intermediate certificate is white-listed, certificates issued by that intermediate certificate are not automatically white-listed. For a certificate to be white-listed it has to be explicitly added to the CTL.

CTL icons

If a certificate is white-listed or black-listed an icon is added next to the email address of the certificate. A yellow icon is shown if the certificate is white-listed and a red icon is shown if the certificate is black-listed. Clicking the icons will open the CTL entry page for that certificate.

Certificate Authority

The gateway contains a built-in CA server which can create end-user certificates for internal and external users. This helps to quickly setup an S/MIME infrastructure without having to resort to external CAs for certificates and keys. Certificates and private keys can be securely transported to external recipients using a password encrypted PKCS#12 certificate store. The external recipients can use the certificate with any S/MIME capable email client like Outlook, Thunderbird, CipherMail for Android etc. and start receiving and sending S/MIME encrypted email.

The CipherMail gateway contains a pluggable framework which allows new certificate request handlers to be registered. A certificate request handler is responsible for creating and/or retrieving a certificate and private key from internal or external CAs. By default, there are five certificate request handlers available: Built-in, EJBCA, CSR , Global Sign EPKI and Intellicard EPKI .

Note

The built-in CA has limited functionality. For support of multiple CA profiles, OCSP etc., use a dedicated external CA (for example EJBCA) or use a remote PKI.

Built-in CA

The built-in CA requires a root and intermediate certificate. A new root and intermediate certificate for the built-in CA can be created by clicking Create CA on the left-hand side menu of the “Create new end-user certificate” page. The following parameters are required for a root and intermediate certificate: Validity, Key length, common name and signature algorithm.

Validity: The number of days the root and intermediate certificate should be valid (starting from the day it was created).
Key length: The length of the public key in bits (1024, 2048 and 4096).

Important

Key length of 1024 should no longer be used for new certificates.

Email: The email address stored in the certificate. Leave empty unless your policy requires an email address for your CA.
Common name: The “Common name” of the certificate is the main identifier of the certificate. The common name of a root certificate should be different from the common name of an intermediate certificate. Choose a unique common name for the root and intermediate certificate.
Make this the default CA: If set, the newly generated CA will be the default CA for the built-in certificate request handler.
Signature algorithm: The hash algorithm for the certificate.

Important

SHA1 should no longer be used for new certificates.

CA configuration

The “CA configuration” page contains the default settings for certificate requests. The “CA configuration” page can be opened by clicking Configure CA on the left-hand side menu of the “Certificate Authority” pages.

The following settings can configured:

Common name: The “Common name” of the certificate is the main identifier of the certificate. This value will be used as the default common name for a new certificate.

Validity: The number of days the root and intermediate certificate should be valid (starting from the day it was created).

Key length: The length of the public key in bits (1024, 2048 and 4096).

Signature algorithm: The hashing algorithm for the certificate.

CA email: The sender email address used when sending certificates to end-users by email. Make sure that the CA email address is a valid email address. If a certificate and key must be sent to an external recipient the CA email address must be set.

Note

Because the email containing the encrypted certificate is sent by the gateway, the settings for the CA email user should be such that the email is not encrypted by the gateway (i.e., set encrypt mode of the CA user to “No Encryption”).

Password length: The password length (in bytes) of the randomly generated password used for encrypting the PKCS#12 file.

Store password: If set, the generated password for the PKCS#12 file will be stored in the user object.

Add CRL distribution point: If set, the configured “CRL distribution point” will be added to the generated certificate. This is only applicable for the Built-in certificate request handler.

CRL distribution point: The CRL distribution point to add to the generated certificate. This is only applicable for the Built-in certificate request handler.

Request handler: The default request handler used for the certificate request.

Certificate Request Handlers

A certificate request handler is responsible for creating and/or retrieving a certificate and private key from an internal or external CA. The CipherMail gateway contains a pluggable framework which allows new certificate request handlers to be registered. A certificate request handler is responsible for creating and/or retrieving a certificate and private key from internal or external CAs. By default, there are four certificate request handlers available: Built-in, EJBCA, CSR , Global Sign EPKI and Intellicard EPKI .

Note

The built-in CA has limited functionality. For support of multiple CA profiles, OCSP etc., use a dedicated external CA (for example EJBCA) or use a remote PKI.

Some certificate request handlers must be configured before they can be used. Certificate request handlers can register a configuration page which can be used to setup the certificate request handler. The available certificate request handler configuration pages can be accessed by clicking Request handlers on the left-hand side menu of the “Certificate Authority” page. The “Configure Certificate Request Handlers” page shows all registered certificate request handler configuration pages.

Built-in certificate request handler

The built-in certificate request handler uses the built-in CA for creating new certificates. Certificates created with the built-in certificate request handler will be issued by the default selected CA. The built-in certificate request handler creates a private key and certificate instantly without any delay (i.e., a request for a certificate is synchronously handled).

Note

Certificates issued by the built-in CA are not trusted by external email clients unless they import the root certificate. Use the GlobalSign or Intellicard connector if a trusted certificate is required.

EJBCA certificate request handler

The EJBCA certificate request handler requires additional configuration from the command line. See the “EJBCA integration guide” for more information on how to configure the EJBCA certificate request handler.

CSR request handler 

The CSR (PKCS#10) certificate request handler will not generate a certificate directly but it will generate a private key and a PKCS#12 certificate request (CSR). The CSR can then be downloaded and sent to a remote CA which supports CSRs for S/MIME certificates. The CA will then issue the certificate. The certificate should then be manually imported. The gateway will then associate the certificate with the correct private key. Use the following procedure to generate a CSR and have it signed by a remote CA:

Select Certificate Authority from main menu to open the “Create new end-user certificate” page.
On the “Create new end-user certificate” page, configure “Email address” and “Common name” and select the “CSR (PKCS#10)” certificate request handler.
Click Request certificate.
On the “Create new end-user certificate” page, click Pending requests. The “Pending certificate requests” page will be opened.
On the “Pending certificate requests” page, select the newly generated CSR and click Download selected and save the downloaded CSR on the local system.
Send the downloaded CSR to the CA.
Wait for the CA to issue the certificate.
Open the “Pending certificate requests” page (On the “Create new end-user certificate” page, click Pending requests)
Click Browse and select the issued certificate and click Upload certificate(s).
The uploaded certificate will now be associated with the private key and moved to the certificate store.

GlobalSign EPKI certificate request handler 

The GlobalSign EPKI certificate request handler can be used to get GlobalSign issued certificates for your organization. The GlobalSign certificate request handler connects to the GlobalSign managed Enterprise PKI (EPKI). This requires a valid GlobalSign EPKI account. Contact GlobalSign for setting up an EPKI account.

EPKI account name: See your GlobalSign EPKI account for the correct value.

Password: The EPKI password.

Profile ID: The profile for the request. See your EPKI account for the correct profile ID.

Product code: The “Product code” defines the type of certificate that should be requested. If unsure what to select, choose “Epki PsPersonal”.

Year: The number of years that requested certificate should be valid.

Request mode: In “Async” mode, a certificate is requested asynchronously, i.e., the certificate requested in the back-ground. In “Sync” mode, the certificate is immediately requested and therefore immediately available.

Note

It is advised to select “Async” mode. In “Async” mode, mail flow is not impacted if a certificate request takes a long time because the request is initiated from a background thread.

GlobalSign Atlas certificate request handler 

The GlobalSign Atlas certificate request handler can be used to get GlobalSign issued certificates for your organization. The GlobalSign certificate request handler connects to the GlobalSign cloud certificate management engine. This requires a valid GlobalSign Atlas account. Contact GlobalSign for setting up a GlobalSign Atlas account.

Before certificates can be issued by GlobalSign Atlas, the following steps should be taken:

Create API credetials and configure the gateway for Atlas
Register your domain(s)
Approve your domain(s)
Import the GlobalSign certificate chain

Configure Atlas

Log into your GlobalSign Atlas Account
On the GlobalSign Atlas management page, open the API Credentials page
Click GENERATE AN API CREDENTIAL
Select View and Copy and click continue
Select the active service you want to link to the new API credential and click Continue
Select a familiar name for the new credential and click continue. A new API key and API Secret will be generated.

Warning

The API Secret will only be shown once. You should therefore copy the API Secret before closing the page.
From the CipherMail Admin GUI, Start the GlobalSign Atlas API setup wizard
Copy the generated API key and API secret to the wizard page
Click Next and click Next
An mTLS certificate request (CSR) will be generated.
On the GlobalSign management page, select mTLS Certificate, then click GENERATE AN MTLS CERTIFICATE
On the GlobalSign “How do you plan to connect to the service?” page, select Directly via the API and click Continue
On the GlobalSign “Link API Credential(s)” page, select the API credentials created in the previous steps and click Continue
On the GlobalSign “Paste a CSR” page, copy and paste the generated CSR from the wizard to the CSR edit box and click Continue
Copy the generated mTLS certificate by clicking COPY TO CLIPBOARD
On the wizard, click Next to go to the “Import mTLS certificate” page
Copy the mTLS certificate which was copied from the Atlas page
Click Next
Click Finish to finish the GlobalSign Atlas setup wizard.

Register your domain(s)

A domain for which you want to request S/MIME certificates must be approved by GlobalSign. To approva a domain, the following steps should be taken:

Register (“claim”) a domain
Add token to DNS
Validate the domain

Register the domain

Before a domain can be validated, the domain should be registered to Atlas.

Start the “GlobalSign Atlas register domain” wizard
Enter the fully qualified domain to be added
Click Next
On the “Register domain” page, a DNS token and claim ID will be shown
Copy the DNS token because it’s needed in the next steps

Add token to DNS

The DNS token generated in the previous step should be placed in the DNS for your domain.

Add the DNS token as a TXT token to your DNS.

example DNS entry:

ciphermail.com.  300 IN TXT "globalsign-domain-verification=5E6DA5B0F899E345915CA238473338B7"

Note

If you forgot to copy the DNS token, you can retrieve the token value by starting the “GlobalSign Atlas search domain claims” wizard (note that the DNS token value will be shown without the globalsign-domain-verification= part).

Validate the domain

Warning

It might take some time before the DNS entry is active. If the domain cannot be validated, wait some time before retrying.

To validate the domain, the following steps should be taken:

Start the “GlobalSign Atlas validate domain” wizard
Enter the fully qualified domain name
Click Next
The associated domain claim ID will be looked up

Note

If a claim ID cannot be found it’s most likely that the domain was not correctly added. If you are certain that the domain was added, you can enter the claim ID manually.
Click Next
Enter the fully qualified authorization domain name. In most cases, leave the default value.

Note

A specialized authorization domain can be used if you would like to delegate the DNS token to a different domain. This is an advanced feature.
Click Finish to start the validation process. If no error is shown, the domain is correctly validated.

Check the domain validation

To check whether the domain is correctly validated, start the “GlobalSign Atlas search domain claims” wizard.

The “GlobalSign Atlas search domain claims” wizard will provide an overview if the domain validation status. A correctly validated domain should have the following status:

"status": "VERIFIED"

Import the GlobalSign certificate chain

Before certificates can be issued, the GlobalSign certificate chain (root and intermediate certificates) should be imported.

To import the GlobalSign certificate chain, start the “GlobalSign Atlas import chain” wizard. After running the wizard, the GlobalSign root certificate will be imported into the root certificate store and the intermediate certificates will be imported into the certificates store.

Intellicard certificate request handler 

The Intellicard certificate request handler can be used to get trusted certificate from Intellicard’s Enterprise PKI. This requires a valid Intellicard EPKI account. Contact Intellicard for setting up an EPKI account.

Customer ID: Contact Intellicard for the “Customer ID”

CA DN: The CA which will issue the certificate. Contact Intellicard for the correct “CA DN”

Private key file: A private key and certificate issued by Intellicard is required to connect to the remote EPKI. Contact Intellicard for the private key file.

Private key password: The password for the private key file. This is required when uploading a new private key file.

Create new end-user certificate

With the “Create new end-user certificate” a new certificate can be created or requested.

Note

If the default certificate request handler is set to “built-in” and an root and intermediate certificate are not yet created, the warning message There is no active CA configured for the built-in certificate request handler will be shown to indicate that the built-in CA is not yet correctly configured.

Validity: The number of days the certificate should be valid
Key length: The length of the public key in bits (1024, 2048 and 4096).
Signature algorithm: The hashing algorithm for the certificate.
Request handler: The request handler to use for the request. By default this will be set to the default configured request handler.
Certificate subject: The subject of the certificate. “Email address” and “Common name” are required.

Advanced settings

Add CRL distribution point: If set, the configured “CRL distribution point” will be added to the generated certificate. This is only applicable for the Built-in certificate request handler.
CRL distribution point: The CRL distribution point to add to the generated certificate. This is only applicable for the Built-in certificate request handler.
Add user object for the requested certificate: If true, a user object for the email address will be added when a certificate is requested.
Send key file to user by email: If set, the generated key will be sent by email to the recipient as a password protected PKCS#12 file.
Password for private key file: The password for the password protected PKCS#12 file. This is required if “Send key file to user by email” is set.

Note

A secure password can be randomly generated by clicking the gear icon on the right hand side of the password field.

Send password via SMS: If set, the password for the PKCS#12 key file will be sent to the recipient by SMS Text. This requires that the SMS gateway is correctly setup, that a user is available for the email address and that the recipients telephone number is configured in the user settings of that user.
Store the password in the user preferences: If set, the password for the last generated PKCS#12 file for a user will be stored in the “Last used pfx password” preference field for that user.

Select default CA

There can be multiple CAs, i.e., different intermediate issuing certificates, for the built-in certificate request handler. However, only one can be active at the same time. A default CA can be selected by clicking Select CA from the left-hand side menu of the “Certificate Authority” page.

Pending requests

Some certificate request handlers, like for example the CSR certificate request handler, do not immediately issue a certificate. Certificate requests which are not immediately handled are stored in the pending requests queue and handled asynchronously by a back-ground thread. The list of outstanding requests can be managed by clicking Pending requests on the “Create new end-user certificate” page.

Download selected: Some requests, like for example the requests generated by the CSR request handler, can be downloaded by selecting the request and clicking Download selected.

Note

Whether or not a pending request can be downloaded depends on the request handler that generated the request.

Reschedule selected: Pending requests will be periodically executed with the associated request handler. By selecting Reschedule selected, the selected items will immediately be executed.
Upload certificate(s): Some request handlers, like for example the CSR request handler, require that certificates are uploaded to finish the request. A certificate can be uploaded by selecting the certificate and clicking Upload certificate(s). For more information about the CSR request handler see CSR request handler .

Bulk requests

With the bulk request option, multiple certificate requests can be requested at the same time. A comma separated value (CSV) file containing the request details should be uploaded. The certificates will be requested using the selected certificate request handler. To make sure that the request details are correctly imported, a preview of the imported certificate requests will be shown after clicking Request preview.

Note

Certificate requests for email addresses for which there is already is a valid signing certificate, will be skipped.

CSV format

The CSV file containing all the certificate requests has the following requirements:

The file should be a comma separated file (CSV).
Values containing commas should be double quoted.
The first row should contain the column order.
The CSV is assumed to be US-ASCII encoded unless a Byte Ordering Mark (BOM) is used.
The following columns are supported: EMAIL, ORGANISATION, COMMONNAME, FIRSTNAME, LASTNAME
EMAIL and COMMONNAME are mandatory.
By default, the maximum number of requests in a single CSV file is 10000.
The maximum length of an individual entry is 256 characters.

Column names are case insensitive and multiple column name aliases are available.

EMAIL, e
ORGANISATION, org, o
COMMONNAME, cn
FIRSTNAME, fn, givenname, gn
LASTNAME, ln, surname, sn

Example CSV

The following example shows how to import two requests. It uses a combination of column name aliases:

"e","org","COMMONNAME","fn","surname"
"[email protected]","organisation 0","user 0","first name 0","last name 0"
"[email protected]","organisation 1","user 1","first name 1","last name 1"

Example CSV

A similar example but this time the values are not quoted and only the required values email and organisation are specified:

e,cn
testA1@example.com, cn1
testA2@example.com, cn2

Create CRL

If a certificate issued with the built-in CA should be revoked, a CRL should be created and the certificate should be placed on the CRL. A CRL for the built-in CA can be created by clicking Create CRL on the left-hand side menu of the “Certificate Authority” page. A CRL should be created for a specific intermediate certificate. If there are multiple intermediate certificates, select the correct one. After selecting the CA the “Create CRL” page is opened on which the certificates that should be revoked can be added to the list of revoked certificates.

Serial numbers: Each revoked certificate is identified by the serial number of the certificate. The serial numbers list contains all the serial numbers that will be revoked.

Revoked certificate: The serial number (in hex form) of the certificate to revoke. Click Add to add the new serial number of the list of serial numbers.

Next update: The next update is the date at which the CA claims it will issue a new CRL. If the CA contains a CRL distribution point make sure that a new CRL is available and that the CRL can be downloaded from the CRL distribution point URL before the CRL expires. The next update is specified in days from the date of the CRL creation.

Note

The next update is the date at which the CA “promises” a new CRL will be available. A CA is however allowed to issue a new CRL before this date.

Update existing CRL: If “Update existing CRL” is selected and an old CRL is available, the old CRL is updated with the new serial numbers. If “Update existing CRL” is not selected, a new CRL will be created with only the newly added serial numbers. It is advised to always update an existing CRL because certificates which are previously revoked should remain revoked.

Signature algorithm: The hashing algorithm used for signing the CRL.

A new CRL will be created when the Create CRL button is clicked. The new CRL will be automatically added to the CRL store.

Important

If the CA contains a CRL distribution point make sure that a new CRL is available and that the CRL can be downloaded from the CRL distribution point.

Send Certificates

With the send certificates page, certificates and the associated private keys can be sent to an external recipient. The certificates and keys will be stored in a password protected PKCS#12 file and then send by email to the recipient. The recipient can then import the password protected private key file into the recipients email S/MIME capable email client.

Note

The recipient requires an email client which supports S/MIME, like for example Outlook or Thunderbird.

Filter by: With the certificate filter, certificates can be searched that match the search term. By default the email address of the user is selected.
Expired: Determines whether or not expired certificates will be shown.
Allow missing key alias: If set, certificates without an associated key will also be shown.

Email address: The email address of the recipient to which the certificate(s) and key(s) will be sent.

Private key password: The password for the PKCS#12 private key file.

Send password by SMS: If set, the password for the PKCS#12 key file will be sent to the recipient by SMS Text. This requires that the SMS gateway is correctly setup, that a user is available for the email address and that the recipients telephone number is configured in the user settings of that user.

Store private key password in the user preferences: If set, the password for the last generated PKCS#12 file for a user will be stored in the “Last used pfx password” preference field for that user.

Allow mismatch between email address from certificate and recipient address: By default, email addresses in the certificates must match the email address of the recipient. However, there are situations where the certificate and private key should be sent to to a different email address. By enabling “Allow mismatch” the certificates and keys can be sent to non matching email addresses.