1

I'm currently migrating to a new host. There are around 20 domains all set up as name-based VHosts in apache.

I read about Apache's reverse proxy ability as an idea to overcome DNS downtime, as not all the domains are in my direct control and I'm not sure how punctual their owners will be in updating them.

Since this is proxying sensitive data over the internet I need SSL all the way.

Virtualhost on origin server:

ServerAdmin a@b.com
ServerName abc.domain.com

SSLEngine On
SSLCertificateFile     /path/to/cert
SSLCertificateKeyFile  /path/to/key

SSLProxyEngine On
ProxyRequests Off
ProxyPreserveHost On
UseCanonicalName On
SSLProxyVerify require
SSLProxyCheckPeerName On

ProxyPass / https://1.2.3.4/
ProxyPassReverse / https://1.2.3.4/

Virtualhost on target server:

ServerAdmin a@b.com
ServerName abc.domain.com

SSLEngine On
SSLCertificateFile     /path/to/cert
SSLCertificateKeyFile  /path/to/key

My issue is with the verification. If I set SSLProxyVerify off everything works as expected.

I've duplicated the certificates on old and new servers - which I obviously have to do anyway - so /path/to/cert and key on both servers leads to the same data.

Browser shows a 500, in the error log on the origin server I see:

AH02039: Certificate Verification: Error (20): unable to get local issuer certificate

I've read a lot of content around this topic, but I'm still confused as to how I should be setting this up.

I believe I should possibly be using a self signed cert and CA for the origin->target leg, but how should this be configured? What should the common name/subject alternatives be on the cert?

Any help appreciated! Thanks!

1 Answers1

1

I was able to get this working myself with a self signed CA and cert.

The proxy server must have SSLProxyCACertificateFile pointing to the generated CA cert.

The remote server must use the self signed chain for SSLCertificateFile along with the key file for the client cert in SSLCertificateKeyFile.

Since I don't have a valid common name/SAN on the client cert the proxy server must also disable SSLProxyCheckPeerName and SSLProxyCheckPeerCN, but keep SSLProxyVerify set to require.

This configuration means end user -> proxy server uses a valid cert, while proxy server -> remote server uses your self signed cert. While we aren't checking common names etc, the proxy server will only accept a response that validates against your self signed CA.

Things that helped diagnose this:

  • Moving the VirtualHost on the remote server to its own port, so I could visit it directly and verify the cert it was serving etc.

  • Increasing the LogLevel for the VirtualHost on the proxy server, I used LogLevel ssl:debug which was enough to show the certs being exchanged in the logs.