5

For normal TLS the client will check that the server I am communicating with is actually on the FQDN matching the CN, hence if the certificate is for a different domain the TLS should not work by default as the certificate is not for this site.

For mTLS when the server is checking the client certificate, can it somehow check the client address matches the CN somehow or is it simply checking the cert matches the key and cert is trusted on the client side? ie if I use the correct client key/cert from any machine on the internet should the server connect if its configured to trust that certificate, or will it require the client to be somehow at specific address?

othane
  • 558
  • 5
  • 15
  • 1
    TLS and HTTPS are different protocols. HTTPS uses TLS. TLS does *not* specify how upper-level protocols are supposed to confirm peer identities, it just provides validated certificates that should be leveraged by the higher protocol. HTTPS does just that, requiring that the hostname the client uses to make the connection be one of the subject alt names in the certificate(use of the CN for this purpose is deprecated for awhile now). It does not specify what should happen when the client is authenticated with certificates. That's up to the server configuration/code. – President James K. Polk Oct 12 '21 at 00:36
  • 1
    thanks @PresidentJamesK.Polk, so if I understand correctly if I am told there is a mTLS server setup it likely wont be checking the client address in anyway, its just checking the certificate is trusted and signed by the clients private key ? – othane Oct 12 '21 at 01:41

1 Answers1

5

It depends on the specific use case.

In some cases mTLS is used in server to server to communication, for example with SIP (VoIP). In these cases the client certificate is often expected to contain the domain of the sender, similar to a server certificate. Keeping with the example of SIP: here the different systems can also switch roles (i.e. both sites can initiate a call) and what was former the client certificate is now used as a server certificate.

In other cases the subject is not validated during the TLS handshake but the users identity is extracted from the certificates subject and provided to the application. The application might then do additional checks, like allowing only users from a specific organisation encoded in the subject. Thus, the subject is still relevant even if it is not used inside the certificate validation during the TLS handshake.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • thanks Steffen Ullrich, so in the first instance of the SIP case I am guessing its still not checked during the TLS handshake but as a application level check? Either way, what part of the request is being checked to know the client domain (as far as I know a normal request would not contain this info)? – othane Oct 12 '21 at 02:22
  • @othane: see [RFC 5922 - Domain Certificates in the Session Initiation Protocol (SIP), Section 7.4](https://datatracker.ietf.org/doc/html/rfc5922#section-7.4) about some aspects of using the information in the client certificate. – Steffen Ullrich Oct 12 '21 at 07:54
  • "Nonetheless, server policies can use the set of SIP domain identities gathered from the certificate in Section 7.1 to make authorization decisions." ... so if I understand this correctly it means its basically just whitelisting the domains in the cert, but there is no actual way to check the client address match the cert in anyway (this is kinda what I expect) – othane Oct 12 '21 at 23:32
  • @othane: Right, there is no implicit association between the subject of the client certificate and the source IP of the client. – Steffen Ullrich Oct 13 '21 at 05:44