5

When a client verifies a server's certificate, it knows the domain name of the server, then it can check whether the domain name exists in the SAN (Subject Alternative Name) field of the server's certificate.

When a server verifies a client's certificate, it doesn't know the domain name of the client. Does it mean SAN in client certificate is useless?

Karu
  • 4,634
  • 7
  • 34
  • 54
Robby
  • 51
  • 2
  • Actually this question is not specific. All depends on the type of the client-server. For example, browsers (on the client side) require a SAN DNS record which is validated against the URL provided by the user. The implementations of the mTLS also have different variants. You can go as low as any client cert or cert issued by specific CA to certificate pinning. – nethero Sep 16 '22 at 15:18
  • I had the same concern as you. I thought it might be worth of adding client domain in the SAN although some sites says it's bad practice as it exposes the identity of the client. However it looks appealing as doing that the client certificate becomes linked to their domain name and client can't share their certificate unnoticed. It gives me a chance to track if client certificate is shared. Although putting IP or some ID would be an option. – Peter Oct 17 '22 at 11:12

3 Answers3

2

Generally speaking it is up to the server (and its administrator) to define the requirements for the client authentication/validation in mutual TLS.

I've seen range of the solutions to this problem. The certificate or the public key can be pinned. You may validate the user against directory like LDAP (the DN can be registered). In some scenarios you only care about the issuing CA. There are options to mix and match different details provided in the certificate. The one thing that is really ill-advised is to use the SAN DNS entry, SAN IP or combination of both in client certificates. We should never assume that the client is present in DNS or has a static IP. The identity shouldn't be based on dynamic factors.

nethero
  • 121
  • 5
1

SANs for client certs can be domain names, or IP addresses, or email addresses, and sometimes other information. There's no requirement that they are domain names only

Client auth often uses IPs and emails. Keep in mind, though, that the CN (common name) will be checked first.

Also, keep in mind that some implementations will attempt a reverse DNS (PTR record) lookup of the connecting IP address and validate that against the SAN field.

Karu
  • 4,634
  • 7
  • 34
  • 54
  • Actually one thing should be made clear. You should never bind a client to a DNS record as that exposes your client (it kind of becomes a server at this point). The good practice is to pin the DN details of the client on the server side. You may require a combination of specific DN values and issuing CA to make it more robust. Some go as far as pinning of details unique to the certificate like the serial number, however this is not a good practice as industry is going towards shorter lived certificates. – nethero Sep 16 '22 at 15:13
0

As referenced in this answer, a SAN value listing UPN specifies the domain name as part of the User Principal Name (UPN) suffix value, or it may not if the SAN values populated with other alternate identifiers such as OID, UID or other GUIDs for PKI/endpoint access management, but I think all would provide an auditable trail of some piece of information to follow-up on if needed.

Dallas
  • 248
  • 2
  • 8