what names for TLS certificates when using SRV records

When I'm using a SRV DNS record, what name(s) do I put in the TLS certificate? For example, if I'm setting up slapd on two servers (klas1 and klas2), and I define these DNS records (using bind zone file style notation):

_ldap._tcp.example.com. IN  SRV 10 0 389 klas1.example.com.
_ldap._tcp.example.com. IN  SRV 20 0 389 klas2.example.com.
klas1.example.com.  A 192.168.0.1
klas2.example.com.  A 192.168.0.2

I'd expect my clients would be configured to connect to ldap://example.com/. However when I'm generating TLS certificates on the servers, do I generate them with the name "example.com", or do I generate them with the name "klas1.example.com", or do I need both?

Solution 1:

The certificate must match the hostname, i.e. corresponding A record for the server. You could have individual klas1.example.com & klas2.example.com certificates or shared wildcard *.example.com certificate, but example.com won't match.

The SRV records don't need certificates as they are used only on DNS level for service discovery.

Solution 2:

you only need your host entries (A records), services records are used for discovery not the connection itself.

Solution 3:

The certificate common name or SubjectAltName.DNS should match the name that was originally given in the LDAP uri. RFC6125 in appendix B.3 (https://www.rfc-editor.org/rfc/rfc6125#appendix-B.3) says:

3.6. Server Identity Check

The client MUST check its understanding of the server's hostname
against the server's identity as presented in the server's
Certificate message, in order to prevent man-in-the-middle attacks.

Matching is performed according to these rules:

o The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate. The client MUST NOT use the server's canonical DNS name or any other derived form of name.

Note that the same logic applies for other protocols that use SRV records, like SIP. This is somewhat logic from a security standpoint. If only the host was checked, it would be easy to perform a man in middle attack by diverting the connection to nodes whose hostnames are unrelated to the domain name originally queried.