I just set up TLS for slapd on one server, using a simple PKI, like this one:
ldap cert < intermediate CA cert < root CA cert
In order to connect to the ldap server using TLS from a client, I added, like many tutorials I found, the root CA cert and the ldap cert to the trusted certificates.
I am able to connect via TLS to my ldap server
However, why isn't the intermediate CA cert needed? Does it need to be sent by the ldap server along with the ldap cert? I have only configured these in my slapd config:
olcTLSCACertificateFile: /etc/ldap/ssl/root.pem
olcTLSCertificateFile: /etc/ldap/ssl/ldap_crt.pem
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap_key.pem
And it seems that each of these root and ldap cert files only contains their own certificate.
Am I misunderstanding something? Why is it working without the client knowing what the intermediate CA cert is?
Best Answer
The reason for having an intermediate CA certificate at all is so that the private key for the root CA certificate can be kept offline.
In a normal certificate authority setup, the root CA certificate is kept offline, and used only to sign intermediate CA certificates, a rare event involving armed guards, C-level employees and a lot of protocol. The intermediate CA private key remains online and is used to sign TLS certificate requests from end customers. It would not be possible to maintain that sort of protocol to sign every end certificate.
In the case of a CA compromise, only the intermediate CA (and certificates signed by it) needs to be replaced; if the root CA were compromised it would pretty much put the CA out of business, as every certificate the CA had signed would need to be replaced.
Further, the root CA must exist in the client's trust store. The client decides which CAs it will accept certificates for, and keeps those root CA certificates locally. Having arbitary intermediate certificates gives the CA more flexibility in this regard. Because it's merely signed by the root CA, rather than being the root CA, it can be changed much more easily (e.g. to upgrade to a more secure hash algorithm).
During TLS negotiation, the server will send its certificate and the certificate that signed it, if not the root CA, and the certificate that signed that one, if not the root CA. Because the client has the root CA certificate, the server should not send it. Some clients will refuse to connect if the server attempts to send a root CA certificate.
In your case, you didn't specify the origin of your certificates or give any relevant information, so it's only possible to make wild guesses.
If they're from a private CA, then the TLS certificate might have been signed directly by the root CA instead of or in addition to the intermediate. The client might also have the intermediate in its trust store (though it shouldn't).