S/MIME Certificate Expiration and Renewal: A Guide for IT Teams

An S/MIME certificate binds a public key to an email address and is signed by a certificate authority (CA). Its validity period has a fixed start and end date. After the end date:

• Encryption to the user fails or triggers a warning. Mail clients generally refuse to encrypt to an expired certificate, so partners either send unencrypted mail or cannot send at all.
• New signatures are not trusted. Recipients see a warning on messages signed with an expired certificate.
• Existing signatures may still verify. Many clients check whether the certificate was valid when the message was signed.
• Previously encrypted messages stay readable, provided the private key is still available.

In other words, expiry is mostly a problem for future mail. It becomes a serious problem for past mail only if the private key is lost during renewal.

Since September 1, 2023, publicly trusted CAs have issued S/MIME certificates under the CA/Browser Forum S/MIME Baseline Requirements (external link). These rules standardize how CAs validate control of a mailbox and the identity of its owner, define certificate profiles, and cap the validity period. For the strict and multipurpose profiles in use today, the maximum is 825 days, a little over two years.

The requirements also define validation types. A mailbox-validated certificate confirms only control of the email address, while organization-, sponsor- and individual-validated certificates also contain verified organization or personal details. Choose the type that matches how recipients will rely on your signatures.

Individual CAs often issue one- or two-year certificates, and the CA/Browser Forum has repeatedly shortened the maximum validity of TLS server certificates. It is sensible to treat S/MIME renewal as a routine, repeating process rather than an occasional event.

Certificates from a private CA, such as one operated on a cloud PKI service, are not bound by these public rules, but they are trusted only by systems that have the private root installed. Our page on external and private certificate authorities explains the trade-off.

Lost private keys

If a device is replaced, or a certificate is reissued with a new key pair, and the old private key is not kept, every message encrypted to the old certificate becomes unreadable. Organizations that must retain mail need a key history: secure storage of each user’s previous encryption keys.

Partners still hold the old certificate

Partners encrypt with the certificate they have on file. Until they receive the new one, usually from a signed message or a directory lookup, their mail to you may fail or arrive unencrypted.

Renewal by calendar reminder

Spreadsheets and reminders do not scale to hundreds or thousands of personal mailboxes, shared mailboxes and service accounts, each expiring on a different date.

Devices out of step

A certificate renewed on a laptop but not on a phone leaves the user unable to read encrypted mail on whichever device still holds the old key or none at all.

Missing intermediate certificates

CAs occasionally change the intermediate certificates they issue from. If the new chain is not sent with signed messages or published with the certificate, some recipients cannot validate the signature.

Certificates are not only for individuals. Shared mailboxes such as invoices or legal addresses, and systems that send signed notifications, need certificates too, and they are the ones most often forgotten because no single person owns them.

Staff changes need a process as well. When someone leaves, revoke or retire their signing certificate, but keep their encryption keys available to authorized staff if the organization must still read mail sent to them. Revocation tells relying parties to stop trusting a certificate before its end date, for example after a suspected key compromise.

The aim is to remove manual steps from issuance, distribution and renewal:

• Integrate with the CA. Request and renew certificates through the CA’s interface rather than by hand. RFC 8823 (external link) extends the ACME protocol to end-user S/MIME certificates, although CA support varies.
• Centralize keys. Generate and store keys in a managed service, so renewal does not depend on individual devices.
• Publish automatically. Make new certificates available through a directory such as LDAP, so partners can find them.
• Sign outbound mail. Signed messages carry the sender’s certificate, which lets partners update their copy.
• Monitor expiry. Track every certificate and alert well before its end date.

A gateway model handles much of this centrally. Our pages on S/MIME certificate lifecycle management and cloud-hosted S/MIME issuance and renewal describe how CloudPGP supports these workflows, and the certificate authority integrations it works with.

1. Inventory every certificate, including shared mailboxes and service accounts, with its CA, profile and expiry date.
2. Set a key policy. Decide whether renewal uses a new key pair, and retain previous encryption keys for as long as mail must stay readable.
3. Start early. Renew well before expiry, so partners receive the new certificate in time.
4. Distribute the new certificate through your directory and signed mail.
5. Verify end to end by exchanging signed and encrypted messages with a few important partners.

If your organization is still deciding between standards, our comparison of PGP and S/MIME for enterprise email sets out how their key and certificate models differ.