Does Apache needs to know about intermediate certificates for client authentication? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.

Closed 9 years ago.

Improve this question

I have a following hierarchy of certificates. And I need to do a client authentication on Apache.

.
└── root (CA) - self signed
    ├── intermediate 1 (CA)
    |   ├── client1
    |   ├── client2
    └── intermediate 2 (CA)
        ├── client3
        └── client4

Who should store intermediate certificates (a client or a server)?

I would prefer to store just a root CA on the server to validate all client certs against it. The main reason is that list of intermediate CA's can grow and I don't want to update all the time certs stored in Apache configuration.

Is this technically feasible? Does SSL protocol requests clients to send the whole chain?

One thought on this subject. As I understand when a client authenticates a server then the server sends the whole chain to the client. I hope that it's symmetrical and when the server needs to authenticate the client, it's the client responsibility to send the whole chain.

Answer 1

The overall rule is that the entity that verifies a certificate should be able to build a full certification chain between the End-Entity Certificate (EEC) it is given and the CA certificates it already trusts (or it could also trust a specific EEC and compare it directly, but that's just a more specific and bespoke case).

This applies to server-certificate verification if you're a client and to client-certificate verification if you're a server. In both cases, a certificate list is sent. In fact, about the message format, the Client Certificate section of the TLS specification mainly refers to the Server Certificate section (7.4.2):

   Client certificates are sent using the Certificate structure
   defined in Section 7.4.2.

Meaning of this message:

   This message conveys the client's certificate chain to the server;

Reducing the number of CA certificates trusted by the server isn't a bad idea. This will reduce the size of the CA certificate list advertised in the Certificate Request message, therefore reducing the size of the handshake. (I've seen default deployments, using a Java server with the default truststore from the OSX keychain if I remember well, that cause that list to be so big that clients wouldn't process it. The problem would also have happened with an Apache Httpd server, if configure with as many CA certificates.)

It's not unreasonable to expect the client to present a complete chain of certificates. Client tools are generally capable of doing this, although the client certificate may need to be packaged accordingly for the expected client, as described in this question in Java, or with a PKCS#12 file build with the chain for tools that rely on this. People who deploy PKIs for their users to use client certificates would generally be aware of this and prepare the certificate and its keys accordingly (or give their users instructions on how to do so).

If you are simply deploying this server and relying on someone else to manage the PKI you belong to, get it touch with them to make sure they explain the users how to prepare the full chain (it's not particularly different from a server chain). In many cases, the certificate skills you would expect from a client-certificate user might not be the same as what you'd expect from a sysadmin installing a certificate on a server, so clear explanations, or having it prepared in advance for the end user (in particular if it's on a smartcard), would generally help.

If you're also involved in the PKI management and learning about it yourself, I'd also suggest trying with the various clients you'd expect. Perhaps try to look at the traffic with Wireshark (if you use initial negotiation, you'll see the client-certificate chain in clear in the initial handshake) to check your settings are correct.

Note that if you're concerned with the size of the transfer, you can exclude the root CA from the chain: it's pointless to send it because the remote party should already trust it (and if it doesn't, it won't trust that chain anyway). (See TLS specification, Server Certificate section: "Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.", which also applies for the client certificate list, for the same reasons.)

Another point is that you can in principle choose to trust a different set of CAs than those you advertise (it's only a "should": "If the certificate_authorities list in the certificate request message was non-empty, one of the certificates in the certificate chain SHOULD be issued by one of the listed CAs."), and Apache Httpd has options to achieve this, but I would recommend against this: it generally only adds confusion and provides few or no benefits.