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.

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.

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 (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.

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.