httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Georg <>
Subject Re: [users@httpd] Certificate check on Apache reverse proxy with upstream SSL
Date Tue, 08 Dec 2015 07:13:57 GMT
Hi Jim,

Not sure I understand your response. The attachment it's the JDK release notes and I did not
find anything specific in there.

I partially solved his by migrating to Apache 2.4 and using checkpeername. With Apache 2.4
the host name from the http request is checked against the certificate rather than the IP
address used in balancer member, but this still leaves the pining issue open, which I would
like to put on to.



Von meinem iPad gesendet

Am 06.12.2015 um 14:39 schrieb Jim Paniagua <<>>:

if you could i sure would appreciate getting rid of these certs   CA  .. it appears why i
am here he continues to be a large problem with breaking serveral good productive working
computers as well as having fun redirecting me and not allowing me anything but under his
control .. this is why i am here .. thank you .. here was a first attempt prom a fellow member
to help out .. i just didnt get it ..

On Wed, Dec 2, 2015 at 4:29 PM, Christian Georg <<>>
Hi all,

I wanted to implement certificate pinning on an upstream SSL connection of a reverse proxy
but I am struggling with the setup.
Please let me know where I am going wrong or if the expected setup should work.

My setup is as follows:
Multiple local applications ---HTTP via localhost --->  Apache httpd 2.2 as reverse proxy
------------------------- HTTPS via the internet ---------------> API Provider

I am having a bunch of applications which all consume an API provided by a third party. Connection
to the third party is accessible via https and mutual SSL.
All local applications are running on the same server and we decided to bundle requests by
using an apache reverse proxy which handles the SSL connections to the API Provider.
By doing this the Proxy also reduced the number of SSL connections needed while at the same
time reducing latency as connections are be reused. I am running an apache 2.2 on CentOS.
Due to the fact that applications and proxy are living on the same host we decided to use
only http via localhost.

The API Provider is using a server certificate which is derived from a public CA.
root CA => intermediate CA 1 => intermediate CA 2 => API Server Certificate.

The setup is working in general but I wanted to ensure that I am understanding the way certificate
chains are evaluated correctly as my understanding of the trust model is not working a expected.
This where I hope you can help.

According to my understanding I should be able to place the Server Certificate in a file referred
to via SSLProxyCACertificateFile
If I then set SSLProxyVerifyDepth to 0 only certificates included in the certificate file
should be trusted.

During tests this setup failed and I am getting an handshake failure. My assumption is that
this is due to the fact that the server certificate is not selfsigned but derived from an
intermediate CA.
I got this to work by Adding all three CAs (root CA, intermediate CA 1 and intermediate CA
2) and setting SSLProxyVerifyDepth to 3
As soon as I started removing certificates from the top or reducing the verification level
I was getting handshake errors stating either CA chain too long or CA not found.

Could you advice on the best way to ensure only specific certificates (Signed by public CAs)
rather than whole CAs can be trusted in outgoing SSL Connections from Appache 2.2 using the

Here is the config I am using:

SSLProxyEngine                               on
SSLProxyCACertificateFile           trusted_CAs.pem                            # this includes
the 3 CAs and I even tried including the 3 CAs and the server certificate.
SSLProxyVerify                                 require
SSLProxyCheckPeerCN                 on
SSLProxyVerifyDepth                    3

ProxyPass / https://API-Server.X.Y/API-App



<Complete JDK 8 Release Notes.html>

To unsubscribe, e-mail:<>
For additional commands, e-mail:<>

View raw message