Re: Certificate check on Apache reverse proxy with upstream SSL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Cheers

Chris

Von meinem iPad gesendet

Am 06.12.2015 um 14:39 schrieb Jim Paniagua <jim.paniagua.951@xxxxxxxxx>:

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 <mail@xxxxxxxxxxxxxxxxx> wrote:

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 SSLProxyEngine

 

 

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

 

Thanks

 

Chris

 

 

 


<Complete JDK 8 Release Notes.html>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx

[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux