3

My PKI certificate (Digital ID for email from Symantec, issuer is "VeriSign Client External Certification Authority - G3") expired after 1 year and so I have renewed it.

Do the people I correspond with using S/MIME for encryption and signing of emails have to do anything?

For example, if I encrypt an email using S/MIME and the new certificate, will the recipients need to do anything special, like "import" the certificate somehow?

Likewise, if they try to send me an encrypted email, will they just get an error that says "certificate expired for the recipient" or something like that?

It seems like a huge pain in the ass if me and my correspondents have to be re-importing each others certificates every year.

  • This needs a little more detail. Is this PGP email, or what kind of PKI are we talking about here? – theterribletrivium Oct 15 '14 at 16:38
  • @theterribletrivium I have updated the post describing the type of certificate – Tyler Durden Oct 15 '14 at 16:50
4

Theory is that everything works automatically. Practice sometimes differs.

I suppose that you are talking about S/MIME and X.509 certificates. With S/MIME, when you send an email:

  • The email is encrypted with the public key of the recipient, so you have to know the current recipient's certificate.
  • The email is signed with your private key and the signature format normally includes a copy of your own certificate.

Thus, other people learn your current certificate when you send signed emails to them. Once they received such an email, they can send encrypted emails to you. If these people also signs their own emails, then you learn their certificates as well, and you will thereafter be able to send encrypted emails to them.

When you get your new certificate, your correspondents don't know it yet; they just know the previous one. When your old certificate expires, they will cease to be able to send encrypted emails to you. But, as soon as you send them a signed email, they will learn your new certificate and everything will be fine again. Storage of copies of the certificates of other people is supposed to be done automatically by your emailing software, so there is never some manual import to do. At least when everything works fine.

If you want people to be able to send you encrypted emails without first receiving a signed email from you, then you can put a copy of your certificate (not your private key, of course) on your personal Web site, Facebook profile, or anything similar.

(In the dreams of the original X.509 designers, certificates for everybody would be found at any time in a worldwide, shared directory called the Directory, with an uppercase D. This is why the main identity in an X.509 certificate is a Distinguished Name: this is a hierarchical path within the Directory. But this never happened: the Directory remained a purely theoretical beast.)

3

You are correct in that contacts may receive a "certificate expired", if they attempt to encrypt an email to you first and attempt to use the expired, cached certificate (this doesn't apply to signed-only emails). Their email client may allow them to proceed if they persist.

Additionally, there's a small chance that the certificate chain may have changed (different CA certificate) and an intermediate be missing from some recipients email client. It happens every once in a while with web-server certs where the workaround is to make the intermediate chain available directly during HTTPS setup. It happens less now with more frequent updates of browsers, but if the email client is decoupled from a browser or OS certificate store it may still be an issue.

I don't know if all S/MIME email clients commonly include the chain as well as the signing certificate. Emailing your contacts a signed (optionally encrypted) email containing and/or linking to a CMS/.p7b file with your new cert and chain is one workaround. This should solve both problems though possibly with some user-interaction required, depending on client software and CA database contents.

If there is no change of chain to cause a problem then Tom is correct, a well behaved client should update with your cached certificate silently when it receives message.

It sounds like this is the first renewal for you, there are some things to be aware of:

  • make sure you understand how your "sent" email is stored (e.g. encrypted or not), these may have been encrypted to you, which means you need to keep your old key
  • you need to keep your old key to decrypt old encrypted messages sent to you (unless your client decrypts messages for storage also)
  • recipients need to keep your old certificate around to validate old signed email without receiving warnings (decrypting email from you is a function of their key of course)
  • export and store in a secure physical location your new key/cert pair!

(Technically, most of these points only apply if your private key has changed, it's possible though uncommon to issue a new certificate reusing a key. The expiry date is a synthetic property of a certificate, a key doesn't expire like that.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.