The short answer
Thunderbird has S/MIME built in, and the setup is one import followed by two selections: open Account Settings, choose End-To-End Encryption, click Manage S/MIME Certificates, import your .p12 or .pfx file under Your Certificates, then use the two Select buttons to name that certificate for digital signing and for encryption. The step that catches people is the one before all of that. Thunderbird keeps its own certificate store inside your mail profile, in the files cert9.db and key4.db, and it does not read the Windows certificate store or the macOS keychain, so a certificate that already works in Outlook is invisible here until you import the original file a second time.
How do you set up S/MIME in Thunderbird?
Five steps, and the whole thing takes about two minutes once you have the file. Open Account Settings from the application menu and select the account you want to secure. Click End-To-End Encryption in the left column. Scroll to the S/MIME block and click Manage S/MIME Certificates. On the Your Certificates tab, click Import, pick your .p12 or .pfx file and give the password that protects it. Close the manager, then use the two Select buttons to nominate the certificate for signing and for encryption.
The rest of this page is about the parts that are not on that list: where the certificate has to come from, why the import can succeed and still leave the Select dialog empty, and why the encryption half of the setup usually stays dark on the first day.
Why Thunderbird cannot see the certificate Windows already has
Thunderbird does not use the operating system's certificate store for personal certificates. It carries its own pair of databases inside your mail profile — cert9.db for certificates and key4.db for private keys — and signs and decrypts only with what those files hold. A certificate you double-clicked into the Windows certificate store, or added to Keychain Access on a Mac, is genuinely installed and genuinely unavailable to Thunderbird at the same time.
This is the single most common way a first S/MIME setup stalls, and it stalls in a confusing shape: the user has proof the certificate works, because Outlook on the same machine signs with it happily, and Thunderbird still shows an empty list. Nothing is broken. The two programs are reading two different stores.
The practical consequence is a requirement rather than a fix. You need the original PKCS#12 file — the password-protected bundle of certificate and private key that your certificate authority gave you, or that you exported when the key was generated. If you no longer have it, export a fresh one from wherever the key currently lives: Manage user certificates on Windows, or Keychain Access on macOS, both of which can write a .pfx or .p12 if the key was marked exportable when it was installed.
Worth knowing before you go looking: a .cer or .crt file is not what you need. Those hold the public certificate only. Thunderbird will import one without complaint and then refuse to sign with it, because there is no private key in the file to sign with.
What you need before you start
Three things, and the import fails without any of them. A personal S/MIME certificate issued to the exact email address on the account. The certificate and its private key together in a PKCS#12 file, with a .p12 or .pfx extension. And the password that was set on that file when it was created, which is not your mail password and not your certificate authority account password.
The address requirement is stricter than people expect. S/MIME binds a certificate to a specific mailbox address, so a certificate issued to you@example.com will not serve an account that sends as you@mail.example.com or as an alias. If your account sends from more than one identity, each identity needs its own certificate and its own selection.
If you do not have a certificate yet, this is the point to get one. A personal S/MIME certificate is issued by a certificate authority after it verifies that you control the mailbox, and validation levels differ in whether they also verify your name or your organization. The S/MIME certificate options set out what each level asks you to prove, and the differences between mailbox, individual and organization validation matter more than they look, because the level decides whose name appears on your signature.
One route avoids the file question entirely. Since Thunderbird 128, the client can generate the key pair and the certificate signing request itself: a button beside the certificate selection in the End-To-End Encryption panel writes a CSR to a file after asking you for RSA or ECC and a key size. The private key is created inside the Thunderbird profile and never leaves it, so there is no PKCS#12 file to import afterwards — you send the CSR to a certificate authority and import the certificate it returns. That also means there is no file to fall back on if the profile is lost, which is a trade you should make deliberately.
Importing the certificate and selecting it
Importing puts the certificate in the profile. Selecting it tells Thunderbird it may be used, and those are two separate actions that happen in two separate dialogs. An import that reports success while the account still shows no certificate is the normal state halfway through, not a failure.
- Open the application menu and choose Account Settings, then select the account you are configuring in the left column.
- Click End-To-End Encryption and scroll past the OpenPGP block to the S/MIME block below it.
- Click Manage S/MIME Certificates. The certificate manager opens on the Your Certificates tab.
- Click Import, choose your .p12 or .pfx file, and enter the file's password. The certificate appears in the list under the name of its issuer.
- Close the manager. Beside Personal certificate for digital signing, click Select and pick the certificate. Thunderbird usually offers to use the same one for encryption; if it does not, click the second Select button and choose it again.
Two settings sit under those selections and are worth a deliberate decision rather than a default. One signs every outgoing message automatically. The other requires encryption for every message, which will block sending to anyone whose certificate you do not hold. Sign by default is a reasonable habit. Encrypt by default is not, until you know your correspondents can receive it.
Signing and encrypting a message
In the compose window, the security controls sit behind the Security or Encryption button on the toolbar, with separate toggles for Digitally Sign and Require Encryption. Toggle either one per message. What you set in Account Settings decides the starting position of those toggles; what you set in the compose window decides that message.
A signed message carries an attachment named smime.p7s, which is the signature itself. Recipients on clients that understand S/MIME see a signature indicator instead of the attachment. Recipients on clients that do not, including some webmail interfaces, see a small unopenable attachment and nothing else, which is worth knowing before you turn on sign-by-default for a mailbox that talks to the general public.
Send yourself a signed message first. It is the fastest confirmation that the private key is reachable and the chain is intact, and it costs nothing. If Thunderbird asks for a master password at that moment, that is expected: the private key lives behind whatever primary password protects the profile.
Why you can sign today but not encrypt yet
Signing uses your private key, which you now hold. Encrypting uses the recipient's public certificate, which you do not hold and cannot obtain on your own. S/MIME encrypts to the recipient's public key, so until a copy of their certificate reaches you, Thunderbird has nothing to encrypt with and greys the option out for that address.
The certificate travels inside a signed message. Ask your correspondent to send you anything at all with their signature on it; Thunderbird takes the certificate out of the signature and files it under Other People's in the certificate manager, and encryption becomes available for that address from then on. This is why S/MIME rollouts inside a company usually begin with everyone turning on sign-by-default for a week: the address book fills itself.
It also explains a failure that reads as a bug. If you enable Require encryption and then write to someone new, Thunderbird refuses to send. The message is correct and the configuration is correct; the missing piece belongs to the other party. Rolling S/MIME out across a team goes into how organizations distribute certificates ahead of time so the first encrypted message is not the one that discovers this.
Using OpenPGP and S/MIME on the same account
Thunderbird supports both, and both can be configured on one account, but a single message is protected by one of them rather than both. The End-To-End Encryption panel asks you to nominate a default technology for the account, and the compose window lets you override that choice for an individual message. Nothing forces you to choose permanently.
Which one to make the default follows from who you write to. S/MIME is what businesses, government departments and regulated counterparties expect, because the certificate carries a verified identity issued by a certificate authority. OpenPGP is what developers and privacy-focused correspondents tend to use, with trust established between people rather than through a CA. If your encrypted mail is mostly external and commercial, S/MIME as the account default and OpenPGP per message is the arrangement that creates the least friction. We compare the two in more detail in S/MIME vs PGP for business email.
What to check when the certificate isn't offered
Thunderbird only lists certificates it currently considers usable for the identity you are configuring, so a certificate can import successfully and still be absent from the Select dialog. Four causes account for nearly all of it: the wrong file format, an address mismatch, an expired certificate, or a chain Thunderbird cannot complete to a trusted root.
| What you see | Usual cause | What to do |
|---|---|---|
| Nothing at all in Your Certificates | The certificate went into the OS store, not Thunderbird | Import the .p12 file inside Thunderbird's certificate manager |
| Imported, but the Select list is empty | Certificate address does not match the identity address | Compare them character for character, aliases included |
| Import succeeds, signing fails | A .cer or .crt was imported, so there is no private key | Import the PKCS#12 bundle instead |
| Certificate shows as not trusted | The issuing intermediate is missing from the profile | Import the CA's intermediate under Authorities |
| Password rejected on import | The mail password was entered rather than the file password | Use the password set when the .p12 was exported |
| Everything works, recipients see a warning | Their client cannot build the chain either | A client-side trust problem on their end, not a signing problem on yours |
The chain row is the one people spend longest on, because the symptom appears on the recipient's screen rather than yours. Thunderbird ships public root certificates and will usually build a path without help, but a certificate issued under an intermediate it does not already hold needs that intermediate imported under the Authorities tab of the same manager. The equivalent problem in Outlook, and how to read the warning it produces, is covered in why Outlook says your S/MIME certificate isn't trusted.
Renewal, backup, and the mail you already encrypted
When the certificate expires, import the replacement and leave the old one where it is. Messages encrypted under the old certificate can be opened only with the old private key, so deleting that entry during a tidy-up makes every one of them permanently unreadable. No certificate authority can undo it, because the CA never held your private key.
Backup deserves the same care, and the profile is a weak place to rely on. Both database files live inside the Thunderbird profile directory, so a profile that is lost, corrupted or left behind on an old machine takes the private key with it. Keep the original PKCS#12 file and its password in a password manager, and treat the profile as a working copy rather than the archive. If the key was generated inside Thunderbird through the CSR route, export a PKCS#12 backup from the certificate manager as soon as the certificate is installed.
Renewal timing is worth a calendar entry rather than an inbox reminder. A signature made with an expired certificate is not automatically invalid to every client, but a mailbox that signs with an expired certificate looks careless to counterparties who check. What expiry actually does to old mail walks through the decisions in more detail, including when reusing the same key pair makes sense and when it does not.
FAQ
Need the certificate before any of this works?
My-SSL issues S/MIME certificates through Certum, a publicly trusted certificate authority whose roots ship in the major browser and operating system trust stores — which is what lets a recipient's client verify your signature without installing anything first. The email certificate range sets the validation levels side by side, so you can check which one puts the name you want on your signature before you order.