https://issues.apache.org/bugzilla/show_bug.cgi?id=55326

--- Comment #2 from falco <[email protected]> ---
(In reply to Kaspar Brand from comment #1)
> (In reply to falco from comment #0)
> > If you additionally add the old directive, it works just fine:
> > 
> >    SSLProxyEngine on
> >    SSLProxyCheckPeerName off
> >    SSLProxyCheckPeerCN off
> >    RewriteRule /status/(.*) https://$1/server-status [P]
> > 
> > But I do not think that this is intentional if SSLProxyCheckPeerName
> > supersedes SSLProxyCheckPeerCN.
> 
> It is intentional, see
> http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslproxycheckpeercn:
> 
> "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."
> 
> SSLProxyCheckPeerName supersedes SSLProxyCheckPeerCN as far as the default
> settings are concerned. Turning off hostname checking for proxied https
> content mostly indicates a misunderstanding of the primary purpose of SSL
> (authentication), so I think it wouldn't be a good idea if
> "SSLProxyCheckPeerName off" would silently disable SSLProxyCheckPeerCN at
> the same time.

Thank you for your reply.
Just to make sure that I understood that correctly:

Setting "SSLProxyCheckPeerName off":
 - disables "SAN" checking
 - hostname -has- to match CN
 * Is used if one want's to make sure, that remote host name and CN of its
certificate are matching


Setting "SSLProxyCheckPeerName off" and "SSLProxyCheckPeerCN off":
 - disables hostname matching at all
 * Is used if one doesn't care about the remote host name and its certificate


Setting "SSLProxyCheckPeerCN off" without "SSLProxyCheckPeerName off":
 - doesn't do anything at all

If this is the case, then I agree, it is good that there's a way to disable SAN
checking without ignoring the CN at all.
I guess I was just irritated by the wording by the description of
SSLProxyCheckPeerName and thought it would replace SSLProxyCheckPeerCN instead
of offering another layer of security.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to