3

I'm trying to get a better understanding of the Server / Client Mutual Authentication process in a TLS1.2 mutual authenticated session. My understanding is that the client is able to fully authenticate the server's identity also relying on the FQDN issued to the certificate presented by the server during the handshake negotiation; however, I believe the server is only relying on a valid client cert being presented by the client (that is, a certificate trusted by the PKI locally installed on server's side or generally trusted via OCSP/CRL) but not necessarily on proof of identity from client's side based on the IP / FQDN (if any) contained in the certificate issued by the client

Is there any way to implement client authentication on the server's side based on the IP / FQDN presented by the client ?

I'm asking also because several SSL VPN remote access solutions mention TLS1.2 mutual authentication - but technically I have the feeling that the way server and client are authenticating each other is somehow asymmetrical.

Ottootto
  • 123
  • 1
  • 6

3 Answers3

4

Is there any way to implement client authentication on the server's side based on the IP / FQDN presented by the client ?

Yes, this can be done. For the server certificate the client verifies not only the certificate chain of the servers certificate but also checks the subject against the hostname of the URL. With client certificates the server should do similar checks, i.e. check the subject of the certificate against the expected subject.

But the question remains what the expected subject should be. In case of a VPN this might be the IP address of the client or the FQDN as determined by a forward confirmed reverse DNS lookup. Or the server could have a specific configuration which subject to expect from each VPN endpoint. Or if this is only a VPN to connect a single client to the company the client certificate might contain the email or the account name of the user.

Thus in summary: yes, this can be done but there is not a single true way. Instead how the subject should be done depends on how the product will be used and different products offer different ways of checking the subject of the certificate.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
2

How you authenticate a peer's certificates in mutual TLS authentication is, strictly speaking, not part of TLS itself, but rather it is part of the application policy.

How the application checks for a certificate authenticity, e.g. checking that the peer's FQDN/IP matches what's written in the C(ommon) N(ame) or S(ubject) A(lternative) N(ame) or the O(rganizational) U(nit) field or checking the O(rganization) for specific value or checking the Extended Key Usage constraints, are application-specific.

For most applications, it is sufficient to authenticate client certificate by trusting the CN and the Issuer. This means you would write authorization policy based on the CN of the Certificate. This allows the clients to be mobile (to move around to different IP Addresses) without the CA having to reissue new certificates, and for the CA to renew the client's certificates without the server having to update authorizations.

The asymmetry here is because in most VPN deployments, servers are generally expected to stay in one place, while clients are generally expected to be mobile.

In some deployments, if you have reasonable belief that the client will not be very mobile, you may want to restrict further that a certain CN is only allowed to connect from a certain IP Address range. This can be part of that deployment's authentication policy, and can be done outside the x.509 certificate. You simply have a table of CN and the IP addresses the CN are permitted to connect from in your application/TLS terminator. I don't see any advantage of writing down the permitted IP Address in the Certificate itself.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
0

Is there any way to implement client authentication on the server's side based on the IP / FQDN presented by the client ?

Could be done.

The REAL client's certificate often doesn't contain any IP/FQDN information. For personal certificates it's usually a name and some identifier, for applications it's usually a system name/application name. Indeed you can create client certificate containing a hostname/IP.

What concerns the TLS, the server validates only the certificate validity (if the server trusts the certificate or any of CAs in the chain). It is common that the applications (above the TLS) enforces a filter to validate of the provided certificate is acceptable.

I'm asking also because several SSL VPN remote access solutions mention TLS1.2 mutual authentication - but technically I have the feeling that the way server and client are authenticating each other is somehow asymmetrical.

For the SSL itself, the hostname is not so important. For the server-side the hostname is commonly validated, but that is the client's task to decide whether to trust it or not (just a good example are the CNAME DNS records, the client is effectively redirected - should it trust the new hostname or not?).

Your intuition is right, the clients (mainly for people) cannot enforce static IP or hostname. You can specify that in the certificate, but the server doesn't really check it (often it has no means to do so, such as IP address provided is often the proxy or VPN).

gusto2
  • 286
  • 1
  • 5