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 '15 at 16:24
  • Yes, that is exactly right. Do you agree with Stephane's assessment in the comments?`
    – Hoax
    Jun 8 '15 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 '15 at 17:13

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 '15 at 11:20
  • @Hoax, CN of personal certificates include name, family name, email, not domainname Jun 8 '15 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 '15 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 '15 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 '15 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"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.