Consider a certificate used by a Certification Authority. This is currently hashed using SHA-1. I'd like to keep the same public/private key for this, but hash it using SHA-256. By hash it I mean hash the tbsCertificate section - as described in RFC5280 - using SHA-256, followed by signing the digest with the private key of the original CA that actually issued the certificate.

This comes in the context of this article, where it's stated that

If you want to convert a CA certificate on an ADCS version prior to Windows Server 2012, you must export the CA cert off of the CA, import onto ADCS 2012 or later using certutil.exe with the -KSP option, then export the newly signed certificate as a PFX file, and re-import on the original server.

Besides the typing error (there's no -KSP, only a -CSP switch).

However, if you use a different CA to sign a certificate this results in the use of a different private key, providing that the Authority Key Identifier stays the same, and the public key of the referenced CA won't verify this new signature. Does this generate a certificate that would fail validation?

1 Answer 1


When you install ADCS, you get the option of generating a new key pair, or reusing an existing key pair. The sentence you quote seems to indicate the latter:

  • You export the certificate and private key from an existing CA, as a PFX file.
  • You import the PFX into a Windows Server 2012 machine.
  • You install ADCS on that machine, directing it to reuse the private key you just imported. ADCS then proceeds to generate and sign its certificate, using the private key you indicated.
  • You re-export the certificate and key from that new ADCS, again as a PFX file, and import that back into the original machine.

The first PFX file contains a certificate and a private key because that's what PFX files are for, but the certificate is completely ignored here; only the private key matters. It just happens that Microsoft tools are unable to process a private key travelling "alone"; they always access keys through certificates, so there must be a certificate.

During the import in the 2012 machine, you need to add a -csp "Microsoft Software Key Storage Provider" option so that the private key is handled in the new crypto system (CNG) because the old one (CryptoAPI) does not know SHA-256.

Of course that's a bit weird to go through an additional Windows 2012 machine, since Windows 2008 or Windows 7 perfectly know how to do crypto with SHA-256. In any case, with a bit of programming, it is not ultimately hard to decode tbsCertificate from the existing certificate, rehash it with SHA-256, compute the signature, and wrap the whole set into a new certificate. Of course you'd have to understand how the whole ASN.1/DER encoding works, but if you want to manage a CA properly you almost need to know that anyway, so you'd better get it done now.

By suggesting an extra system, one may even suspect that Microsoft is making money out of selling Windows licenses !

  • But in step 3 above, wouldn't a new serial number be generated, along with a different CA name (otherwise it'll collide with the existing one, assuming both are Enterprise subordinate CAs) - thus resulting in a new tbsCertificate section ? Although from a chain-linking perspective it shouldn't really matter, since the AKI/SKI is the hash of the public key, which is being kept the same. Jan 29, 2016 at 8:02
  • Also a bit of background, so my questions don't seem out of a SciFi movie: Issuing CA with its own cert being sha-1 hashed, but issuing sha-256 hashed certs. Chrome complains about chain containing at least one sha-1 signed cert for web servers using the issued certs. Easiest thing to do is simply rehash the Issuing CA's own cert with sha-256, and rely on AKI/SKI keeping the chain consistent (we don't care about sha-1 hashed root certs at this time, as stated in the last line here googleonlinesecurity.blogspot.ch/2014/09/…). Jan 29, 2016 at 8:10

You must log in to answer this question.

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