httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <>
Subject Re: Confusion about SSLProxyCheckPeerName/CN
Date Tue, 31 May 2016 18:15:52 GMT

On 05/31/2016 06:37 PM, William A Rowe Jr wrote:
> It seems the behavior introduced in 2.4.5 is causing a lot 
> of confusion for users attempting to disable peer checking.
> Right now, nothing needs to be done to do deep inspection 
> (altsubjectname plus common name).  Neither directive is
> required, both default to on.
> Disabling checking is a pain in the ass, and the docs seem
> to be very misleading;
>     SSLProxyCheckPeerName Directive
> Default: <>	|SSLProxyCheckPeerName
> |
> This directive configures host name checking for server certificates when mod_ssl is
acting as an SSL client. The check
> will succeed if the host name from the request URI is found in either the subjectAltName
extension or (one of) the CN
> attribute(s) in the certificate's subject. If the check fails, the SSL request is aborted
and a 502 status code (Bad
> Gateway) is returned. The directive supersedes |SSLProxyCheckPeerCN
> <>|, which
only checks for the expected host name
> in the first CN attribute.
>     SSLProxyCheckPeerCN Directive
> Default: <>	|SSLProxyCheckPeerCN
> This directive sets whether the remote server certificate's CN field is compared against
the hostname of the request
> URL. If both are not equal a 502 status code (Bad Gateway) is sent.
> In 2.4.5 and later, SSLProxyCheckPeerCN has been superseded by |SSLProxyCheckPeerName
> <>|, and
its setting is only taken into account
> when |SSLProxyCheckPeerName off| is specified at the same time.
> So under CheckPeerName, we *claim* that the directive *supersedes* the CheckPeerCN -
but taking the only action you can
> with CheckPeerName (turning it off) falls right back into the trap of CheckPeerCN, which
*must* be *seperately*
> disabled. This behavior sucks.
> I would suggest that CheckPeerCN should NOT default to "on" any longer. The only valid
use case is for the user to
> actively disable CheckPeerName (off), and has still wishes to actively enable CheckPeerCN
> But we will need to improve this horrible CheckPeerName documentation for users of 2.4.5
through 2.4.20, even if we
> change the behavior.
> Thoughts?

As I felt into this trap a couple of days ago on my own a wholeheartedly +1.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message