Bug 62915

Summary: SSLProxyCheckPeerName does not seem to work with Lets Encrypt full chain cert
Product: Apache httpd-2 Reporter: Aram Akhavan <kaysond>
Component: mod_proxyAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED INVALID    
Severity: normal CC: kaysond, kirtankshetty
Priority: P2    
Version: 2.4.29   
Target Milestone: ---   
Hardware: PC   
OS: Linux   

Description Aram Akhavan 2018-11-16 07:21:18 UTC 
I'm trying to use apache2 to reverse proxy my router config page. The router serves a certificate generated by Let's Encrypt using the DNS-01 challenge with wildcard support, and I'm using the subdomain router.domain.com.

The certificate file contains both my domain cert and the intermediate Let's Encrypt cert that's signed by DST Root CA X3. Per the documentation for SSLProxyCheckPeerName, the Subject Alt Name contains

Not Critical
DNS Name: *.domain.com
DNS Name: domain.com

And the CN is domain.com

However, if I set up the proxy with

RequestHeader set X-Forwarded-Proto "https"
SSLProxyEngine On
ProxyPass "/" "https://192.168.1.1:443/"
ProxyPassReverse "/" "http://192.168.1.1:443/"

I get an - Error during SSL Handshake with remote server

Just adding "SSLProxyCheckPeerName off", however solves the problem. I'm not sure if this also disables CA checking or its a problem with the chaining, but I serve the same cert to my reverse proxy and web clients, and there are no problems.

I'm happy to provide the cert privately.
Comment 1 Aram Akhavan 2018-11-16 07:21:50 UTC 
This is running on Ubuntu 18.04, hence the slightly older release
Comment 2 Ruediger Pluem 2018-11-16 08:32:49 UTC 
This is because ProxyPass uses an IP address and not domain.com. It needs to be 

ProxyPass "/" "https://domain.com:443/"

This is a configuration error and not a bug.
Comment 3 Aram Akhavan 2018-11-16 17:30:30 UTC 
I'm an idiot. Sorry. I don't know why I thought the cert is to match the host that the client is connecting to...