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"?

1 Answer 1

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.

8
  • Great explanation, thank you
    – Sauron
    Jun 30, 2021 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? Jan 25 at 20:47
  • @EvanCarroll - I'm not sure what you mean. It might be worth asking a separate question? Jan 26 at 7: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. Feb 22 at 21:48
  • 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. Feb 27 at 7:27

You must log in to answer this question.

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