I have a reverse proxy which connects to an application which presents a certificate used for PKI based validation. I was wondering if I should enforce the condition that the common name (or subjectAltName) in the certificate match with the hostname brought along with the client. The relevant RFC 6125 says:

If the hostname does not match the identity in the certificate, user oriented 
clients MUST either notify the user (clients MAY give the user the opportunity to 
continue with the connection in any case) or terminate the connection with a bad 
certificate error.  Automated clients MUST log the error to an appropriate audit
log (if available) and SHOULD terminate the connection (with a bad certificate 
error). Automated clients MAY provide a configuration setting that disables 
this check, but MUST provide a setting which enables it.

For the reverse proxy scenario, is the server-side connection an "automated client" or a "user-oriented client"?

3 Answers 3


It's your own decision. Pros and cons on each side.

If you enforce strict checks then that is one more thing that can break. If you don't care about encryption from load balancer to backend server, then leave it off. This is something you may choose to do if you've decided that the LAN-side of the LB is safe enough for you.

  • If you decide that you need to worry about ACTIVE attackers LAN-side then absolutely, do reencrypt (or maybe never decrypt and only do limited load balancing) and be strict about it.

  • If you decide that you need to worry about PASSIVE eavesdroppers only LAN-side, then encryption without authentication will do.

  • If you decide that you need to worry about no attackers LAN-side, then you don't need encryption there.

And as for the client type: "automated client". Users need/should not be aware of any load balancer even existing in the network path.

  • I think it is better not to enforce strict checks since there might be multiple servers being loadbalanced each presenting their own certificates.
    – user90696
    Commented Nov 19, 2015 at 23:14
  • Okay, but there are more alternatives: if you have your own PKI then you could just give each backend server its own cert. Or if you want them to share certs, then you could use a shared wildcard cert or multi-name "SAN" certificate. In those cases hostnames validation would not be a problem. Commented Nov 20, 2015 at 5:29

It depends:

  • If you expect a specific certificate the most secure way is to configure your reverse proxy that it expects exactly this certificate. In this case the actual subject of the certificate does not matter and it can also be self-signed, because the reverse proxy will not accept anything else than this certificate.
  • If instead you accept a certificate as long as it is signed by a trusted CA then you need to additionally check the subject. Otherwise a man-in-the-middle attack could be done by any other certificate which was issued by a trusted CA and at least if you use public CA then these certificates are easy to get without any kind of hacking.

For certificates signed by a public CA usually the name in subjectAltName/CN is checked against the actual hostname of the server (from the URL) because this the part which is considered specific enough and it is expected that nobody can get a certificate for a hostname (s)he does not own. If you have another property which can be used as secure identifier with the same properties than this could be used instead too, but public CA usually want the hostname.

How you propagate the error in case the certificate does not match depends on the exact design of your application. But usually the reverse proxy is part of the server side and in this case errors in the validation mean that there is something wrong at the server side which need to be fixed there. Thus you could tell the client that something is wrong but the actual details should probably not be told to the client.

  • A rookie question: The hostname validation is essential for the certificate to be accepted as valid, right (along with signature validation)? Otherwise, any man-in-the-middle can impersonate the type URL in theory.
    – zgulser
    Commented Apr 23, 2020 at 10:04
  • 1
    @zgulser: Yes, the subject/SAN of the certificate must match the domain name accessed by the client. Otherwise an man in the middle attacker could simply use a certificate issued by a public CA but for a different domain. Commented Apr 23, 2020 at 10:34

First and foremost, a reverse-proxy is by definition a man-in-the-middle attacker.

Exceptions Noted: When using Where the TLS/SSL packets are not inspected.

As others have said, it is your decision but there can be no REAL SECURITY for a communication when a reverse-proxy is present.


  • Not necessarily. You can do some loadbalancing without opening SSL. EG for Citrix NetScaler: "SSL_BRIDGE" mode. Commented Nov 20, 2015 at 17:23

You must log in to answer this question.