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: <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? > >
As I felt into this trap a couple of days ago on my own a wholeheartedly +1. Regards Rüdiger
