Can I re-sign SMIME certificates with my own CA?

Question

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.

Answer 1

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.

Answer 2

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.