Many large corporations choose to use their own CA to sign their employee's SMIME certificates. Which is fine for internal use, but they typically expect external users to import their corporate CA into their email client's certificate store.

I find this expectation unreasonable, as I do not want to trust any more CAs than I already have to. Even without assuming malicious intent, I don't know how well these corporations protect their private keys.

Unfortunately, some of these corporations are our customers. And I'm not going to convince a Fortune 500 company to change their ways by purchasing SMIME certificates from a public CA.

Is it possible that I somehow re-sign single SMIME certificates from my correspondents with my own CA, which I then import into the certificate store? This would be a client-agnostic solution to the whole issue. Of course I'd verify the certificate's fingerprint beforehand over the phone, mimicking the workflow of PGP.

2 Answers 2


While it is theoretically possible to create a new certificate from the public key contained in the certificate, this has some down sides:

  1. This is a lot of work as usually CAs require proof of ownership of the private key to create a certificate (for example by a CSR), so the common tools would not work as seemlessly as with a CSR (afaik).

  2. You are either repeating your check for hashes on every key or trusting the CA by blindly resigning their certificates.

    If you do plan on checking all fingerprints, you might as well express trust in just those certificates directly rather than the CA they came from. While this is not confirming to the standard, some implementations do allow for that for such reasons.

  3. Your initial point of “I don’t know how secure the CA is” is not handled: if the CA (as often with such companies) not only signs a CSR but creates a key pair for the user, the CA you are trying to explicitly not trust may hold the private key for a certificate you signed.

To recap, some of the problems go away when your client allows to explicitly trust a certificate rather than a CA, yet you should keep in mind that you did so and the privacy of the conversation might be broken (maybe even by a mail gateway of the company) either way.

To get rid of the warnings, this does help - to actually have trust for the use cases of S/MIME both ways (your and my suggestion) both do not help.

But then again, the PKI is in a somewhat broken stage such that - depending on your needs - not even a “real” CA would satisfy your needs and you would be better off with a PGP approach, personally expressing trust after out-of-band authentication.

  • 1. In this case, I am the CA, so this should be easily scriptable, no? 2. I understand, but I'm only dealing with a handful of customers that use SMIME this way. 3. Makes sense, but this isn't something I can fix, right? Also, trusting a single certificate is highly dependent on the email client, right? E.g. Thunderbird can't do it, AFAIK
    – Volker
    Commented Oct 30, 2017 at 8:30
  • @Volker from my experience, nothing is “easily scripted” when you do not follow the beaten track. But this might depend on what “easily” exactly means.
    – Tobi Nary
    Commented Oct 30, 2017 at 8:33
  • So is there something else I can do besides importing their CA? As I said, I don't think I can send out encrypted e-mails using Thunderbird without importing the CA.
    – Volker
    Commented Oct 30, 2017 at 8:35

Yes, but it wouldn't necessarily do you any good.

First, signed emails typically contain the (public) certificate with the public half of the signer key. You'll be hoping that whatever your mail client is would be willing to fall back to some sort of external lookup after internal extraction results in a valid signature but invalid chain.

Second, signed emails allow identification of the certificate in two ways: 1) issuer name and serial number 2) "subject key identifier".

If the certificate is identified via issuer+serial then any new certificate you make won't match (unless you name your CA the same as theirs, I suppose). If it's identified as the subject key identifier then you'd have more chance of success, since that is most often just a value in a cert extension and you can simply bring it across during the cross-certification.

Unless you're using CA software that has "cross-certify" as a primitive you're asking for trouble, though. Depending on what you're trying to accomplish you'll need to bypass serial number generation, you may have complicated CA policy objects that are trying to be helpful, but break the certificate for your purposes, et cetera.

Probably your easiest solution is to look into per-certificate trust. For Windows/Outlook that's probably putting the certificate into "Trusted People". Thunderbird probably has a similar feature.

  • Thunderbird won't import untrusted certificates. It's not possible to mark a single certificate as trusted. I'm using mutt, but ideally I'm looking for a general solution.
    – Volker
    Commented Oct 30, 2017 at 14:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .