Is it possible to ignore an Apache proxy'd certificate

Question

For background information: (Question at bottom)

I'm trying to connect to a client, who has 8 servers, all of which have unique IP addresses. The client uses the same SSL certificate on all the servers (for this example, cert name == www.all_servers.com). The client only allows incoming requests over https.

I'm trying to create an apache proxy using mod_proxy that maps different URI mappings to different servers. For example:

https://PROXY_SERVER/SERVER1/{REQUEST}

This would send {REQUEST} to server1

https://PROXY_SERVER/SERVER2/{REQUEST}

would send {REQUEST} to server2. So far, pretty simple.

In Apache 2.2, this could be achieved by using the IP addresses like so:

SSLProxyEngine On

ProxyPass /server1 https://1.1.1.1/
ProxyPassReverse /server1 https://1.1.1.1/

ProxyPass /server2 https://1.1.1.2/
ProxyPassReverse /server2 https://1.1.1.2/

This was due to Apache 2.2 not checking if the certificate matched (1.1.1.1 != www.all_servers.com)

However, in Apache 2.4, I'm now getting certificate issues (rightly so). (This exact code works on an apache 2.2 box)

[Thu Oct 10 12:01:48.571246 2013] [proxy:error] [pid 13282:tid 140475667224320] (502)Unknown error 502: [client 192.168.1.1:48967] AH01084: pass request body failed to 1.1.1.1:443 (1.1.1.1)
[Thu Oct 10 12:01:48.571341 2013] [proxy:error] [pid 13282:tid 140475667224320] [client 192.168.1.1:48967] AH00898: Error during SSL Handshake with remote server returned by /server1/asd
[Thu Oct 10 12:01:48.571354 2013] [proxy_http:error] [pid 13282:tid 140475667224320] [client 192.168.1.1:48967] AH01097: pass request body failed to 1.1.1.1:443 (1.1.1.1) from 192.168.1.1 ()

I can't use /etc/hosts, as one server would work, using:

1.1.1.1 www.all_servers.com

SSLProxyEngine On
ProxyPass /server1 https://www.all_servers.com/
ProxyPassReverse /server1 https://www.all_servers.com/

But many servers wouldn't

---

So, to the actual question:

Is there a way to force mod_proxy to ignore miss-matching certificates. Or, is there a better way to do this.

Thanks for any help with this!

Solution

You can set the SSLProxy* options on your Apache server (which is a client as far as the reverse proxy connections are concerned).

This was done with SSLProxyCheckPeerCN (off by default in 2.2, but on by default in 2.4), but I'm not sure how this is going to work with IP addresses (since having IP addresses in the CN is not standard). There's a new option in Apache Httpd 2.4 for checking SANs (SSLProxyCheckPeerName), but I'm not sure how it behaves for IP addresses either.

Having IP addresses in DNS SAN extensions or in the CN is not standard compliant with HTTPS:

If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead.

[...]

In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI.

Comments

[Bruno]

Just to avoid confusion, you could call your client/customer something else than "client", when you talk about servers.

[Bruno]

Voting to move to ServerFault.

[Gwynnie]

Thanks this worked well, I only had checkCN off, once I added checkName to off, it all started working magically

[Bruno]

Turning this off makes that connection potentially vulnerable to MITM attacks, unless perhaps you've imported those certificates in the SSLProxyCACertificate* directly (and there's only those certs there).