Using an encrypted connection with server authentication, host verification is enabled by default. However if I would like to authenticate the client using certificates as well, I am guessing that host verification can used be as well.

Am I correct in that assumption?


  • Am I correct in understanding that you are asking if the server can validate the DNS name of the client as part of the TLS handshake? I think that's what you want based on your comments to some answers but am not certain. Jun 8, 2015 at 16:24
  • Yes, that is exactly right. Do you agree with Stephane's assessment in the comments?`
    – Hoax
    Jun 8, 2015 at 16:50
  • 1
    You can't accurately get IP/DNS information about the client. Proxies, VPNs, TOR, network hacks, etc... get in the way. And the client certificate does not have an IP in it. It is the IP in the certificate (along with the public key and all of the X.509 signing and trust) that allows the client to confirm the server's IP. The same just isn't possible given current X.509 infrastructure. Jun 8, 2015 at 17:13

2 Answers 2


Yes, TLS has provision for mutual authentication during the handshake process.

In this case, the server will add a certificate request message to his handshake along with his certificate server and server key exchange (so it will happen very soon in the handshake).

Note that mutual authentication is compatible with TLS/SNI because the SNI header is added to the client hello message which happen before the server sends his client certificate request message back.

  • 1
    Ok but if I am interpreting this extension specification correctly, it says that only the DNS server_name can be verified during the mutual authentication version of the handshake.----------------------- therefore a server with a domain (e.g. www.server.com) and its certificate (CN: server.com) - can be validated (and will fail if the CN part were to say: evilserver.com, because of a mismatch----------------------- but the client which could have a hostname of (e.g. mycomputer01) and its certificate (CN: notvalid.com) would not fail because this same hostname check is not done for the client
    – Hoax
    Jun 8, 2015 at 11:20
  • @Hoax, CN of personal certificates include name, family name, email, not domainname Jun 8, 2015 at 11:22
  • What do you mean by personal certificate? if you check the server certificate at google.com the Subject-CN is: *.google.com
    – Hoax
    Jun 8, 2015 at 11:45
  • @Hoax The extension is there to help the client validate the server, not the reverse. Basically, it's there to support multiple SSL servers on the same IP address. It does NOT help validate anything about the client certificate: this is done on the server according to server-specific rules.
    – Stephane
    Jun 8, 2015 at 12:17
  • @Stephane. Thanks for your answer. My follow-up question is now if the server and its server-specific-rules are capable of validating the client-hostname as I have described it in the comment above. Is it default, configurable, not possible at all or just not popular?
    – Hoax
    Jun 8, 2015 at 12:37

Yes. On server such checks are executed to verify (for example) if CA which sign the client certificate is particular. Or CN of client certificate is particular and so on.
For example for apache httpd server you can check this page section "Client Authentication and Access Control"

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .