The short answer
An S/MIME certificate expires; the private key it names does not stop working. After the end date you can no longer sign outgoing mail or receive newly encrypted mail with it, but every message encrypted to that key beforehand still decrypts, provided the key is still in your keystore — which is exactly what a tidy renewal tends to delete. Renewals also come round faster now: the Legacy profile closed to new issuance on 15 July 2025, so publicly trusted S/MIME certificates cap out at 825 days rather than 1185. Treat the expiring certificate as an archive you keep, not an item you replace.
What actually expires?
The certificate expires. The key pair does not. A certificate is a signed statement from a certificate authority that your email address belongs with a particular public key, and that statement carries an end date. The private key it refers to is a number sitting in your keystore, and numbers have no calendar. Software enforces the date, and it only enforces it for some operations.
That distinction is the whole subject. Two of the four things you do with an S/MIME certificate check the end date before proceeding, and two of them never look at it. Signing checks it, because your mail client will not put its name to a message with a lapsed credential. Encryption to you checks it, because the sender's client validates your certificate before using the key inside it. Decryption of an old message does not check it, since nothing in that operation consults a certificate at all — it takes the encrypted message key and applies your private key. Verification sits awkwardly in between, and gets its own section below.
So the practical question at renewal time is never "how do I stop the certificate expiring". It is "what do I need to keep once it has".
Can you still read old encrypted mail?
Yes, indefinitely, as long as you still hold the private key. Opening an encrypted message from three years ago runs the same operation it ran on the day it arrived: unwrap the message key with your private key. No validity window is consulted, no revocation list is fetched, no CA is contacted. Expiry is a statement about future use of the certificate, not a switch that turns off past mail.
What actually ends that access is losing the key, and the routes to losing it are mundane. A new laptop, a rebuilt Windows profile, a mail client reinstalled from scratch, an administrator clearing expired certificates out of the personal store because they look like clutter. In Outlook the symptom is a message that will not open and an error about a digital ID that cannot be found by the underlying security system. The certificate and the key live in the Windows certificate store rather than in the mailbox, so a mailbox backup on its own does not save you.
Apple Mail keeps the same material in the login keychain, which travels with a Time Machine restore but not with a clean install. Thunderbird stores it in the profile's certificate database. Hosted S/MIME in Google Workspace is the exception worth knowing about: there the key is uploaded to the user's profile by an administrator, so retention is an admin decision rather than a device one — the Workspace setup guide covers where it lands.
None of this is recoverable from the certificate authority. A CA issues certificates against public keys and never sees the private half, so there is no copy to reissue. This is the same property that makes private key handling the part of any PKI deployment worth being careful about.
Do messages you already signed still verify?
Sometimes, and you do not get to decide which. An ordinary S/MIME signature carries no trusted timestamp, so a verifying client has to choose which moment to check your certificate against. RFC 8550 tells implementers not to take that moment from the signingTime attribute inside the message, because the sender controls it and could backdate it. Plenty of clients therefore validate against the current date, and an expired signer certificate then reads as invalid.
Vendor FAQs tend to say that a message signed inside the validity window keeps verifying afterwards. That is true of the mathematics and only sometimes true of the software. Outlook displays a warning on messages whose signer certificate has since expired, and Thunderbird has carried a long-standing bug report asking it to validate at signing time rather than at open time. Neither behaviour is wrong, exactly — both are reasonable readings of a specification that declines to hand implementers a trustworthy clock.
The comparison that makes this click is code signing, which faced the identical problem and fixed it. A signed executable normally carries an RFC 3161 countersignature from a timestamping authority, so the operating system can check the certificate as it stood on the signing date and keep trusting the binary years later. That is precisely why timestamping a code signature is treated as mandatory practice rather than a nicety. Mail clients never adopted the equivalent.
The consequence for planning is narrow but real: if a signature has to hold up as evidence years after the fact, S/MIME on its own is the wrong tool. That work belongs to a document signature with a timestamp attached, which is what document signing certificates are built for. S/MIME is excellent at proving who sent a message today and at keeping its contents private for good. It was never designed as an archival signature format.
How long an S/MIME certificate can last now
825 days, at most. The CA/Browser Forum's S/MIME Baseline Requirements define three certificate generations — Legacy, Multipurpose and Strict — and cap each one. Legacy allowed 1185 days, but certificate authorities have not been permitted to issue it since 15 July 2025. That leaves Multipurpose and Strict, both capped at 825 days, which is why the three-year email certificate quietly disappeared from CA price lists.
The difference between the two surviving generations is scope rather than length. Multipurpose permits a certificate to carry other uses alongside secure mail, such as client authentication or document signing. Strict confines it to mail. Both give you the same 825-day ceiling, and for most buyers the choice is made by the CA's product line rather than by any decision at checkout.
The reuse periods underneath matter more at renewal than the headline number does. A CA may rely on identity vetting it performed up to 825 days ago, so a returning customer usually does not resubmit documents. Mailbox control is a different story: proving it with an email challenge is only good for 30 days. That single figure explains the renewal experience — the paperwork is remembered, the click is not.
Which generation and validation level you end up with also depends on what the certificate asserts about you, a subject the S/MIME validation types guide covers in full.
Renewal, reissue, and what gets re-validated
Renewal issues a new certificate with a new end date, and in most workflows a new key pair with it. Reissue replaces a certificate inside its existing lifetime and keeps the original end date; Certum, for one, documents reissue as free for the whole validity period. The two solve different problems, and picking the wrong one is a common way to waste a week.
| Renewal | Reissue | |
|---|---|---|
| Use it when | The certificate is running out of time | The key was lost, replaced, or exposed |
| End date | New, up to 825 days out | Unchanged from the original |
| Cost | A new certificate | Free for the full term at Certum |
| Mailbox check | Repeated — the email proof is 30 days old at best | Repeated as part of activation |
| Identity check | Reused if vetted within 825 days | Reused from the original order |
In both cases you generate a key pair during activation, either from a CSR you produce or directly on a cryptographic card. A card keeps the key where it was generated and never exports it, which is excellent for signing and worth thinking twice about for encryption — a key that cannot leave the card also cannot be archived, so losing the card ends access to everything encrypted to it.
If the existing certificate has weeks rather than days left, start the replacement now and let the two overlap. My-SSL's S/MIME certificates for individuals and organisations run the same order-then-activate flow the second time as the first, so an overlapping renewal holds no surprises.
The archive step almost everyone skips
Before you install anything new, export the expiring certificate together with its private key to a PKCS #12 file and put it somewhere you will still have in five years. Every other step in a renewal can be redone. This one cannot, because once the key is off every machine you own, no CA, backup vendor or password reset brings it back.
On Windows, open certmgr.msc, find the certificate under Personal → Certificates, and export it with the private key to a .pfx file with a strong password. On macOS, Keychain Access exports the identity as a .p12. Thunderbird has its own certificate manager with a Backup button under Your Certificates. The file format is the same in all three cases even when the extension differs, which the certificate formats guide sets out.
What a usable archive looks like
- One PKCS #12 file per certificate you have ever used on that address, named with the address and the year, not "cert-final-2.pfx".
- A password stored in the same password manager the rest of the team can reach, since an archive nobody can open is not an archive.
- A copy somewhere that survives the laptop: a managed backup, an encrypted vault, or organisational key escrow if you run S/MIME at scale.
- A note of which mailbox it belongs to. Addresses get reassigned and the certificate is the only thing that remembers.
For an organisation, the individual version of this advice does not scale, and the answer is key escrow: keep a central copy of each encryption key at issuance so a departure, a lost device or a legal hold does not cost the company its mail. That is a policy decision to make before the first certificate is issued rather than after the first loss.
A renewal that does not lose mail
Six steps, in this order, and the order is the point. Archive before you touch anything, overlap the certificates so signing never has a gap, and leave the old certificate installed when you are done. Two of the six are the ones people skip, and between them they account for most of the "I cannot open my old encrypted mail" tickets a reseller sees.
- Export the expiring certificate with its private key to a password-protected PKCS #12 file, and store it off the machine.
- Order the replacement two to three weeks out so the old certificate is still signing while the new one goes through validation. You can start an S/MIME renewal here and complete activation the same day in most cases.
- Complete the mailbox challenge — a link sent to the address in the certificate. Identity documents are usually reused if you were vetted within the last 825 days.
- Install the new certificate and make it the default for both signing and encryption in every client you use. Outlook's settings live under Trust Center rather than anywhere obvious.
- Leave the expired certificate in the keystore. It costs nothing and it is what opens your archive. Delete it only after you are sure the PKCS #12 backup restores.
- Send one signed message to a colleague and have them confirm the new certificate is the one that arrived. Clients sometimes cling to the old default.
Should you revoke the old certificate?
Usually not. Revocation is the tool for a key you no longer trust or a mailbox you no longer control, and a certificate that simply reached its end date is neither. Letting it lapse is the quieter outcome, and it leaves your archive and your sent signatures exactly where they are.
There is a cost to revoking that rarely gets mentioned. Expiry and revocation are read differently by verifying software: an expired certificate is a certificate that ran its course, while a revoked one can be treated as a certificate that should never have been trusted. Clients that check revocation may therefore reject signatures you sent while the certificate was live — which is the behaviour you want after a key compromise and not otherwise. The revocation mechanics are the same as they are for TLS.
Revoke when the private key was exposed, when a device holding it was lost, when someone leaves and their key was not escrowed, or when the address itself is being handed to another person. Note that revoking never affects your own ability to decrypt: that runs on the key, and revocation is a statement to other people about the certificate.
If it has already expired
Start with one question: is the private key still on the machine? Open the certificate store and look for the expired certificate under your own identities. If it is there with a key attached, you have lost nothing at all — sign a new order, and the archive keeps opening the whole time. If it is missing, the next hour decides whether the old mail comes back.
Places a copy tends to survive, in the order worth checking: the machine you used before this one, a phone or tablet still carrying the mail profile, a full-disk backup taken while the certificate was installed, an exported .p12 or .pfx from a previous migration, and — for managed environments — the escrow database your administrator may have without realising you need it. Restore the file, import it, and the messages open again.
If none of those turn anything up, the encrypted messages are gone, and it is better to hear that plainly than to spend a week on support tickets. The sender encrypted a message key to a public key whose private half no longer exists anywhere, and that is the property the whole system is built on. Signed-only messages are unaffected: their contents were never encrypted, so they read normally regardless of what the signature panel says about the certificate.
Going forward, do the archive step first and the ordering second. If several people in one organisation have hit this, the fix is escrow rather than a memo.
FAQ
Renewing an S/MIME certificate this month?
Export the old key first, then order the replacement with enough overlap that signing never stops. My-SSL sells S/MIME certificates for individuals and for organisations, and for a returning buyer the mailbox challenge is usually the only step you repeat.
Compare S/MIME certificates and renewal terms