What exactly is a certificate?

S/MIME uses Public Key Infrastructure (PKI) to protect messages sent over untrusted networks with public key cryptography. Public key cryptography uses a key pair: a public key and a private key. The private key must remain secret, while the public key can be shared. Messages are encrypted with the recipient’s public key and can only be decrypted with the matching private key. To send an encrypted message, the sender must obtain the correct public key for the recipient.

Public keys are distributed in X.509 certificates. A certificate includes the owner’s public key and identifying details to help you choose the right certificate for encryption. For S/MIME, a certificate should at minimum include the email address it was issued for. Many certificates also include the owner’s name, organization, and other attributes.

A certificate is simply a file in a defined format. Anyone can create a certificate with arbitrary content, so you cannot automatically trust the identifying information it contains. Trust must be established either explicitly or implicitly through PKI.

With explicit trust, you decide to trust a specific certificate, for example after verifying its thumbprint with the owner by phone. The drawback is that each certificate must be checked and added to your Certificate Trust List (CTL) manually.

With PKI, trust can be established automatically. S/MIME relies on a hierarchical trust model. A root certificate (also called the trust anchor) is explicitly trusted. Certificates issued by that root, including intermediate and end-entity certificates, are trusted because they form a valid chain back to the trusted root. Certification Authorities (CAs), which may be root or intermediate CAs, issue and digitally sign certificates. Applications verify that a certificate was issued by a trusted CA by validating this chain of signatures to the trusted root. The advantage of this model is that you only need to explicitly trust the root certificate; all certificates issued under it are trusted automatically if the chain is valid.

In addition to identity information, certificates include technical details such as validity period and permitted uses. For S/MIME, the certificate’s Extended Key Usage should indicate that it can be used for email protection (emailProtection) or be unrestricted for such use according to your organization’s policy.

What is a root certificate?

S/MIME uses a chain of trust. A certificate is validated by confirming that it was digitally signed by the certificate that issued it. Issuer certificates can themselves be issued by higher-level (intermediate) certificates, and this continues until the chain reaches a root certificate. Root certificates are explicitly trusted. If a valid chain can be built from a certificate back to a trusted root, the certificate is considered trusted. Because trust in the root is unconditional, only root certificates that you truly trust should be added to the root store.

What is an intermediate certificate?

An intermediate certificate is a certificate authority (CA) certificate that is used to issue other certificates. A CA may use multiple intermediate certificates, each dedicated to a specific purpose—for example, one for S/MIME email encryption and another for SSL/TLS website security. Only certificates that include the CA Basic Constraints extension are allowed to issue other certificates.

What is an end-user certificate?

An end-user certificate is intended for tasks like encrypting messages and creating digital signatures. For S/MIME email, it must include the certificate owner’s email address. It is not meant to issue other certificates and must not have certificate authority (CA) permissions.

Why do certificates expire?

Certificates expire for a few important reasons. First, the cryptographic strength chosen when a certificate is created (such as the key length) is designed to be secure for a certain period. As computers get faster, older keys and algorithms can become easier to break. Setting an expiration date ensures a certificate is replaced before its protection falls below an acceptable level.

Second, expiration helps with day-to-day security management. If a certificate should no longer be used—for example, when an employee leaves—its expiration provides an automatic safety net in case it isn’t manually revoked.

Finally, many commercial certificate authorities issue certificates with short validity periods (often about one year). This promotes regular key rotation and identity revalidation, and it aligns with their operational and business processes by creating a predictable renewal cycle.

How does the gateway handle expired certificates?

The gateway does not use expired certificates by default. If you decide that an expired certificate is still acceptable, add it to the Certificate Trust List (CTL) to whitelist it (with the –allow-expired flag set) so the gateway can continue to use it.

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

Some certificates include a key usage extension that limits how the certificate can be used.

For S/MIME encryption, if a key usage is specified, it must include keyEncipherment.
For S/MIME signing, if a key usage is specified, it must include either digitalSignature or nonRepudiation.

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

How the gateway validates certificates for S/MIME

S/MIME encryption

The gateway checks the Key Usage and Extended Key Usage extensions.
Key Usage: If present, it must include keyEncipherment. If the Key Usage extension is absent, the certificate is treated as valid for all usages.
Extended Key Usage: If present, it must include either anyKeyUsage or emailProtection. If the Extended Key Usage extension is absent, the certificate is treated as valid for all extended usages.

S/MIME signing

The gateway checks the Key Usage and Extended Key Usage extensions.
Key Usage: If present, it must include digitalSignature or nonRepudiation. If the Key Usage extension is absent, the certificate is treated as valid for all usages.
Extended Key Usage: If present, it must include either anyKeyUsage or emailProtection. If the Extended Key Usage extension is absent, the certificate is treated as valid for all extended usages.

Do we need separate signing and encryption certificates?

Some organizations require messages to be signed on a desktop using a smart card because these signatures may be legally binding. If your organization does not require signing messages in the email client, you do not need separate certificates for signing and encryption.

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

Using your own root certificate has an important limitation: it is not automatically trusted by external users. Each external user must manually import your root certificate into their trusted root store. By contrast, if you obtain an intermediate CA certificate from a publicly trusted root, certificates you issue will be trusted automatically by most systems. The downside is that this option can be costly. If your primary use case is domain-to-domain S/MIME encryption with external partners who also use an email security gateway, using your own root certificate may be a practical and cost-effective choice.

What does it mean when a certificate is revoked?

If a private key is compromised or an employee leaves the company, the associated certificate must no longer be used and should be revoked. Certificates are revoked by adding them to a Certificate Revocation List (CRL). A CRL is issued and signed by the certificate authority (CA) that issued the certificate and is updated periodically. Most certificates include a CRL distribution point that provides a URL where the current CRL can be downloaded.

The CipherMail Gateway regularly downloads CRLs from the distribution points referenced by all certificates in the certificate store and replaces older CRLs with the latest versions. You can also add CRLs to the CRL store manually, but this is only necessary if a CA provides a CRL without a valid distribution point URL.

What is a certificate Trust List (CTL)?

A Certificate Trust List (CTL) is a list that explicitly allows (whitelists) or blocks (blacklists) specific certificates. The CTL is created and maintained by the gateway administrator and can include certificates from multiple issuers. In most environments, standard PKI-based trust management is sufficient, but a CTL provides additional manual control when needed.

Typical situations where a CTL is useful include the following. If a certificate has been compromised and the issuer does not publish a certificate revocation list (CRL), adding the certificate to the blacklist ensures it is no longer accepted. If a certificate cannot be validated because the root certificate is missing, but the administrator has independently verified its authenticity (for example, by checking the thumbprint), adding it to the whitelist allows it to be used for encryption. If a certificate has expired but the administrator is certain it should remain acceptable under local policy, whitelisting it enables continued use for encryption.

Using a CTL allows trust to be managed on a case-by-case basis. This is similar to how trust can be handled with PGP: instead of inheriting trust from a chain of issuers, each certificate must 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 type of digital signature used for legally binding electronic signatures. In practice, the private key is often stored on a smart card and the certificate is issued by a trusted authority. Some users receive three separate certificates (with matching private keys): one for encryption, one for general signing, and one specifically for non-repudiation. In that setup, the general signing certificate is typically used for authentication (for example, logging in), while the non-repudiation certificate is used to sign documents. The gateway does not distinguish between a general signing certificate and a non-repudiation certificate when verifying signatures. A certificate that allows signing and/or non-repudiation is acceptable for signing. If your certificate is reported as invalid for encryption, it is likely because it only includes the non-repudiation key usage. Such a certificate cannot be used for encryption, but it should be valid for signing—as long as you have access to the corresponding private key.