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.

S/MIME certificate store

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.

S/MIME root store

Tip

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

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.

S/MIME color coding

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.

S/MIME Encryption Certificate Selection
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.

S/MIME signing Certificate Selection

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.

CTL add entry
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 CTL white listed is shown if the certificate is white-listed and a red icon CTL black listed 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 Pro/Ent only, Global Sign EPKI Pro/Ent only and Intellicard EPKI Pro/Ent only.

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 Pro/Ent only, Global Sign EPKI Pro/Ent only and Intellicard EPKI Pro/Ent only.

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 Pro/Ent only

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:

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

GlobalSign certificate request handler Pro/Ent only

The GlobalSign 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.

GlobalSign EPKI settings
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.

Intellicard certificate request handler Pro/Ent only

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.

Intellicard EPKI settings
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"
"test0@example.com","organisation 0","user 0","first name 0","last name 0"
"test1@example.com","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.