A typical X.509 certificate contains the following elements (this is a non-exhaustive list):
- Public Key
- Email address
- Serial Number
- Not Before
- Not After
- Key Usage
- Extended Key Usage
Some of the main elements of an X.509 certificate will be discussed.
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.
The subject of a certificate contains the name of the “owner” of the certificate and optionally an email address (or sometimes multiple email addresses).
The email address for which the certificate was issued. A certificate can contain multiple email addresses.
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.
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.
The date before which the certificate is not yet valid.
The date after which the certificate is no longer valid.
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:
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”.
“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:
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”.
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.
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.
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).
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).
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.
- 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.
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.
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.
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.
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.
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.
- The SHA512 thumbprint of the certificate.
- 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.
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.
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.