What exactly is a certificate?

S/MIME uses Public Key Infrastructure (PKI) to securely exchange information over insecure networks using public key cryptography. Public key cryptography makes use of two keys: the public key and the private key. The private key should be kept secret whereas the public key can be made available to everyone. The public key is used for encrypting and the associated private key is used for decrypting. If a sender wants to send an encrypted message, the sender needs to get hold of the correct public key of the recipient.

An X.509 certificate contains the public key of the certificate owner. The sender needs to select the correct certificate for encryption. The certificate therefore contains some extra information which can be used to identify the correct certificate. A certificate used for S/MIME should at least contain an email address for which the certificate was issued. Most certificates however contain more information like name, company etc.

A certificate in essence is just a binary file with a specific format. With the correct tools, a certificate with any content can be easily made. A certificate can therefore not be automatically trusted because the content, i.e., the identifying information about the certificate owner, cannot be trusted.

There are two ways a sender can decide to trust the certificate: explicit trust or implicit trust using PKI. By explicitly trusting a certificate, the sender decides that this specific certificate is valid and trusted. For example the sender has checked the certificate thumbprint over the phone. The main disadvantage of explicitly trusting certificates is that every certificate must be manually checked and placed on the Certificate Trust List (CTL).

Using PKI, an automatic procedure can be used to implicitly check the trust of a certificate. S/MIME uses a hierarchical trust model where trust is inferred bottom-up. The root (the bottom) is blindly trusted (which makes it by definition a root) and all leaf nodes and branches (the end-user and intermediate certificates) are trusted because they are child’s of the trusted root (to be precise the intermediate certificates are issued by the root certificate). The main advantage of using the PKI trust model (i.e., implicit trust) is that only the root certificate has to be explicitly trusted. All certificates issued by the root are automatically trusted. A certificate is issued by a CA, which can be a root or an intermediate CA. Because the CA digitally signs a certificate, end-users can check whether the certificate was issued by a trusted root.

Besides identifying information about the owner of a certificate, most certificates contain more information like expiration date, certificate usage etc. For example if the extended key usage is set it should contain at least anyKeyUsage or emailProtection to make the certificate valid for S/MIME.

What is a root certificate?

S/MIME uses a hierarchical trust model. A certificate can be validated by checking whether the certificate was digitally signed by the issuer of the certificate. The issuer certificate itself can be issued by another certificate (which makes it an intermediate certificate). This procedure can be repeated until a root certificate is reached. Because a root certificate is explicitly trusted and a valid chain can be built from a certificate to a root certificate, the certificate is implicitly trusted. Because a root is ‘blindly’ trusted, only root certificates that are really trusted should be added to the root store.

What is an intermediate certificate?

An intermediate certificate is a CA certificate used for issuing other certificates. Sometimes a CA uses multiple intermediate certificates and each intermediate certificate is used for different purposes. For example one intermediate certificate is used for issuing certificates only valid for S/MIME and another one for only SSL. Only certificates with a CA basic constraints extension are allowed to issue other certificates.

What is an end-user certificate?

An end-user certificate is a certificate which should be used for encryption or signing. An end-user certificate for S/MIME should at least contain the email address of the owner. An end-user certificate should not be used for issuing other certificates (i.e., end user certificates should not have a CA basic constraint extension).

How can a certificate have ‘child’ certificates?

A root and intermediate certificate are used for issuing other certificates. The certificates issued by an intermediate certificate are ‘child’ certificates of the intermediate certificate.

Do ‘child’ certificates share keys with the parent?

Every certificate has it’s own public key. Public and private keys are not shared. A private key is not part of a certificate. When a certificate request is created, a private key and public key is generated. The public key is added to the certificate. Although the certificate and private key are associated, they are separate entities. For transport, a certificate and private key are often stored in a password protected PKCS#12 file (generally with the extension .pfx or .p12).

Why do certificates expire?

There are different reasons why certificates have an expiration date. For example when a root certificate is created the protection level of the certificate (for example the length of the public key) is set to a level that should be strong enough to last the lifetime of the certificate. Because of increasing computer power, the level of protection should also be increased over time. By making sure a certificate expires before the level of protection falls below an acceptable level, the certificate protection level is always strong enough. Another reason why an end-user certificate has an expiration date is that when a certificate should no longer be used, because for example an employee has left, the certificate automatically expires after some time.

Commercial certificate issuers have a business reason why certificates expire (most of them are only valid for one year). They ensure themselves of a constant income when they only issue certificates that expire within one year.

How does the gateway handle expired certificates?

The gateway does not automatically use an expired certificate. If an expired certificate should be used by the gateway because the administrator has determined that the certificate can still be used, the certificate should be ‘white-listed’ by adding the certificate to the CTL. Because issuing new certificates is cumbersome, certificates should not expire too soon.

What is the difference between a signature and an encryption certificate?

A certificate can contain a key usage extension which restricts the certificate usage. For S/MIME encryption, if a key usage is specified it should at least contain keyEncipherment. For S/MIME signing, if a key usage is specified it should at least contain digitalSignature or nonRepudiation.

How does the gateway handle key usage and extended key usage?

When deciding whether a certificate is valid for S/MIME encryption, the gateway checks the following certificate properties: key Usage and Extended Key Usage.

If the key usage extension is specified, it should contain keyEncipherment. If the key usage extension is not specified, the certificate is considered to be valid for all usages. If the extended key usage extension is available, it should either contain anyKeyUsage OR emailProtection. If the extended key usage extension is not available, the certificate is considered to be valid for all extended usages.

When deciding whether a certificate is valid for S/MIME signing, the gateway checks the following certificate properties: key Usage and Extended Key Usage.

If the key usage extension is available, it should contain digitalSignature OR nonRepudiation. If the key usage extension is not specified, the certificate is considered to be valid for all usages. If the extended key usage extension is available, it should either contain anyKeyUsage or emailProtection. If the extended key usage extension is not available, the certificate is considered to be valid for all extended usages.

Do we need separate signing and encryption certificates?

Sometimes policies require signing of messages with a smartcard on the desktop because the signature is considered a legally binding signature. If signing of messages on the senders email client is not required there is no need to use a separate signing and encryption certificate.

Can we use a self-signed root certificate or should it be issued by a trusted CA?

The problem with using your own root certificate is that the root certificate is not automatically trusted by external users. Every external user should import the root certificate into the root certificate store. Getting an intermediate CA certificate issued by a trusted root has the advantage that all issued certificates are automatically trusted. The main disadvantage however is that this is expensive. If you mainly use domain-to-domain S/MIME encryption with other external parties that also use a gateway, you might consider using your own issued root certificate.

What does it mean when a certificate is revoked?

When a private key was compromised or an employee left the company, a certificate should no longer be used in which case the certificate should be revoked. Certificates can be revoked by putting the certificates on a Certificate Revocation List (CRL). A CRL is issued and signed by the certificate authority (CA) that issued the certificate. A CRL is periodically updated. Most certificates contain a CRL distribution point extension which contains the URL from which the CRL can be downloaded. The CipherMail Gateway periodically downloads the CRLs from all the CRL distribution points of all certificates from the certificate store. Old CRLs are replaced by the newly downloaded CRLs. CRLs can also be manually added to the CRL store. However, this is only needed when a CA issues a CRL for which there is no valid CRL distribution point.

What is a certificate Trust List (CTL)?

A Certificate Trust List (CTL) is a list of white-listed and black-listed certificates. A CTL is created and updated by the gateway administrator and can contain certificates from different issuers. In most setups, trust management using PKI will be sufficient. Sometimes however, the administrator needs more control over this automatic process. Some examples of when a CTL can be helpful are:

• A certificate should no longer be used because it was compromised. The certificate issuer however does not publish a CRL. By black-listing the certificate, the certificate will no longer be valid.

• 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). By white-listing the certificate, the certificate will be valid for encryption.

• A certificate is not valid because the certificate has expired. However, the administrator is absolutely certain that the certificate is still ‘valid’. By white-listing the certificate, the certificate will be valid for encryption.

Using the CTL, trust can be managed on a more ad hoc bases. This is more-or-less similar to how trust is managed with PGP. Instead of ‘inheriting’ trust from other trusted certificates, with a non-PKI approach using the CTL, every certificate should be explicitly trusted.

What does the key usage nonRepudiation mean?

I found some certificate in our Ciphermail store with key usage nonRepudiation. I downloaded the matching root CA but this certificate is still marked as invalid so the question is if this is because of the exclusive use of nonRepudiation and what this certificate should be used for anyway?

Non-repudiation is a strong form of signing which is used for legal electronic signatures. This normally implies that the private key is stored on a smart card and that the certificate is issued by a trusted issuer. Sometimes, three certificates (and associated private keys) are issued to one person. An encryption certificate, a signing certificate and a non-repudiation certificate. With three certificates, the signing certificate is normally used only for authentication purposes and the non-repudiation for signing documents.

The gateway does not make a distinction between a signing certificate and a non-repudiation certificate. A certificate with signing and/or non-repudiation key usage is acceptable for signing. The reason why the certificate is invalid in your case is that the certificate only contains the non-repudiation key usage. The certificate is therefore not valid for encryption. It should however be valid for signing. This however requires that you possess the private key.