httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Confusion about SSLProxyCheckPeerName/CN
Date Tue, 31 May 2016 16:37:09 GMT
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: <http://httpd.apache.org/docs/2.4/mod/directive-dict.html#Default>
SSLProxyCheckPeerName
on
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
<http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxycheckpeercn>,
which only checks for the expected host name in the first CN attribute.

SSLProxyCheckPeerCN Directive
Default: <http://httpd.apache.org/docs/2.4/mod/directive-dict.html#Default>
SSLProxyCheckPeerCN
on
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
<http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#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 (on).

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?

Mime
View raw message