0

I have a Windows web server, and usually I install the ca-authority in "LocalMachine\Root" and the intermediary PFX certificate in "LocalMachine\My", everything works well. Now I wonder, if during the PFX certificate generation I include the ca-bundle, can I avoid to install the ca-authority in "LocalMachine\Root" and just install the PFX with included the bundle-ca in "LocalMachine\My"?

Sauron
  • 221

1 Answers1

2

The root CA certificate is normally installed at the opposite end of the TLS connection to the certificates in the PKCS#12 (PFX) file.

If the PKCS#12 file contains a client authentication certificate along with its private key and the certificate of the CA which issued it (and potentially other intermediate CA certificates) the chain is installed in your device and used to authenticate you to a remote server. That server should have the root CA installed in its trust-anchor store, if it trusts that root CA, which it uses to verify the certificates from the PKCS#12 presented by the client.

Very similarly, if the PKCS#12 file contains a server authentication certificate along with its private key and the certificate of the CA which issued it (and potentially other intermediate CA certificates) then chain is installed in your server and used to authenticate it to your device. Your device should have the root CA installed in its trust-anchor store, if you trust that root CA, which it uses to verify the certificates from the PKCS#12 presented by the server.

Saying that, a PKCS#12 is simply a container, so other combinations of certificates and keys are permitted, but the above are the two most common use-cases.

If you install all the certificates within the PKCS#12 it does not mean you trust any root CA certificates within. Who/what you trust isn't bilateral - it's your choice. You need to explicitly make that choice ensure the integrity of the system.

For example, if you install a PKCS#12 on your Firefox browser, so that you can log in to a website, it does not make sense to install any root CAs within the PKCS#12 in Firefox's trust-anchor store automatically. You may not want to trust that root CA for verifying web servers, only for verifying clients. That is, it's not up to Firefox developers to decide which root CAs you trust.

Similarly, if you install the PKCS#12 in a Windows server, it can present those certificates to any clients which connect to it and those clients (if they have the root CA certificate installed in their trust-anchor store) will trust the server. However, that does not automatically mean you want to trust other certificates presented to your server from that root CA, such as client authentication certificates.

The bottom line is - it's up to you to decide what to trust.

garethTheRed
  • 4,779
  • Great explanation, thank you – Sauron Jun 30 '21 at 18:44
  • what is the .pfx file is self-signed and the CA is foreign? Does "trusting" it when imported mean you trust that CA as a root CA for your application? Or does it mean you trust that self-signed CA for that one client cert? – Evan Carroll Jan 25 '24 at 20:47
  • @EvanCarroll - I'm not sure what you mean. It might be worth asking a separate question? – garethTheRed Jan 26 '24 at 07:29
  • Your comment: "PKCS#12 is simply a container" implies, then, that the order of certificates doesn't matter at all, correct? The server certificate doesn't have to come first. By convention it does because it makes working with tools like OpenSSL much easier. I just want to be sure I understand correctly because I got a bundle with the order: endpoint-entity, Root-CA, Intermediate-CA, and it validated just fine (because the same Root-CA cert is already in the machine's trust store)--but when using -no-CAfile -no-CApath -untrusted..., then it didn't--which makes sense to me. Thanks. – fourpastmidnight Feb 22 '24 at 21:48
  • Using my same certificate bundle, I performed this: openssl verify -show_chain -no-CAfile -no-CApath -untrusted <( openssl x509 >/dev/null; cat; } < server.crt ) server.crt and got the following output: DC = com, DC = mydomain, CN = My Certificate Root Authority\n error 19 at 2 depth lookup: self signed certificate in certificate chain\n error server.crt: verification failed. So your assertion is 100% correct, just because the self-signed Root CA cert is in your bundle doesn't mean that you will trust it. You have to put it in your machine's trust store. (cont'd) – fourpastmidnight Feb 26 '24 at 15:42
  • Because I know my Root CA cert comes in the middle of the bundle, let's pretend I don't have it installed yet (-no-CAfile -no-CApath) but that I trust the root CA certificate in the bundle and want to verify the bundle trust chain: openssl verify -show_chain -no-CAfile -no-CApath -untrusted <({ openssl x509 >/dev/null <({ openssl x509 >/dev/null; cat; } < combined.crt); cat; } < combined.crt ) -trusted <({ openssl x509 >/dev/null; cat; }) < combined.crt) combined.crt This yields combined.crt: OK with the resulting trust chain. (cont'd) – fourpastmidnight Feb 26 '24 at 17:28
  • 2
    @fourpastmidnight - ordering is irrelevant as PKCS#12 is a container and not a method of chain building. According to RFC 7292, PKCS#12 is a transfer syntax for personal identity information and has nothing to do with building certificate chains. Software which use PKCS#12 do whatever they want with the certificates, private keys, or any other info held within. You've demonstrated what OpenSSL does. Java applications may behave differently, and so may GnuTLS etc. In the end, it's down to their developers. – garethTheRed Feb 27 '24 at 07:27
  • @garenthTheRed Thanks for confirming. I was wondering if there was a RFC for PKCS12, I just hadn't quite gotten around to looking it up, so thanks for the link, I'll be sure to bookmark it! – fourpastmidnight Feb 27 '24 at 17:59