One of my devs recently had an issue with the compatability of a certificate, and we rooted around for a bit until we came across a a similar problem on SO.

Once I understood the developer's initial problem (the original certificate was generated with a CNG provider, rather than the Legacy one), I was expecting to have to re-create the CSR with the compatable parameter, and send it to the CA for re-signing.

However, the Linked Questions list led me to an unaccepted answer on another question, which suggested openssl could be used to split the existing PFX to a PEM pair, change the CSP parameter of the PEM private file to one that was compatable with the application, then recreate the PFX.

PFX-PEM-PFX conversion aside, I was skeptical that changing the private key file would work, because I thought that would cause the signature to change, and so would no longer validate. However, to my surprise, it appears to have worked and the dev was able to continue without further issues.

This got me wondering, how much of the certificate is actually covered by the signature process? What's to stop someone using the same tool (or similar) to change the expiry date, add another subject alternate name, or remove the CRL or OSCP information (for example)?

One of my devs recently had an issue with the compatability of a certificate, and we rooted around for a bit until we came across a a similar problem on SO.

Once I understood the developer's initial problem (the original certificate was generated with a CNG provider, rather than the Legacy one), I was expecting to have to re-create the CSR with the compatable parameter, and send it to the CA for re-signing.

However, the Linked Questions list led me to an unaccepted answer on another question, which suggested openssl could be used to split the existing PFX to a PEM pair, change the CSP parameter of the PEM private file to one that was compatable with the application, then recreate the PFX.

PFX-PEM-PFX conversion aside, I was skeptical that changing the private key file would work, because I thought that would cause the signature to change, and so would no longer validate. However, to my surprise, it appears to have worked and the dev was able to continue without further issues.

This got me wondering, how much of the certificate is actually covered by the signature process? What's to stop someone using the same tool (or similar) to change the expiry date, add another subject alternate name, or remove the CRL or OSCP information (for example)?