12-05-2012 12:50 PM
The admin guide and online help are a bit thin here but lots of good info through this resource. One document seemed to indicate that ssl forward proxy (decrypting my client traffc for inspection on it's way "out") only worked with a self-signed cert or an internal trusted cert. In other words, I either generate one on the device and distribute to all of my clients to avoid getting a broken session warning on the endpoint or leverage an internal CA to do that for me.
For anyone else who's done this successfully, is that truly the case or can I leverage my geotrust wildcard cert that I've already uploaded? I'm attempting to use it at the moment and get an error in my browser telling me that no issuer chain was provided despite the fact I've already obtained Geotrust's intermediate cert and appended it to mine.
Sorry if I'm covering extremely worn ground here but after days of experimentation I'm going a bit cross eyed.
12-05-2012 02:42 PM
You cant use your wildcard cert from GeoTrusts (unless they were really stupid and gave you a wildcard cert for "*" (compared to "*.example.com" which I assume is what you actually got from them)).
What PA does is to use the CA cert (private key) to sign a cert created on the fly (when session starts) which is then sent to the client. The cert sent to the client will have expiration date etc copied from the real cert (real cert as in the cert which the target system sent to the PA box).
The above is maintained just as you described, you either create this particular CA cert within the PA box (and then export it to its HA partner (private key + public cert) and put the public cert as trusted CA in all your clients to avoid getting a warning that the connection is not trusted) or you create this CA cert (and key) in a "real" CA server (or just use openssl) and then import it to both your PA boxes in the HA pair (if you have a HA pair otherwise just import the private key and public cert to the PA box you got).
As a sidenote in order to handle cases where the real cert couldnt be verified you can use another cert (created just like above) as "untrusted cert" (and perhaps add it as untrusted issuers in your clients browsers).
This way if the real cert (between PA box and target system) was successfully verified the PA box will sign the inbound cert (between PA box and client) using its "trusted forward" cert and then send it to the client. While if something went bad (like the real cert is expired or issued by a not trusted CA etc) the PA box will sign the inbound cert using its "untrusted forward" cert and then send it to the client.
12-05-2012 02:42 PM
You cant use your wildcard cert from GeoTrusts (unless they were really stupid and gave you a wildcard cert for "*" (compared to "*.example.com" which I assume is what you actually got from them)).
What PA does is to use the CA cert (private key) to sign a cert created on the fly (when session starts) which is then sent to the client. The cert sent to the client will have expiration date etc copied from the real cert (real cert as in the cert which the target system sent to the PA box).
The above is maintained just as you described, you either create this particular CA cert within the PA box (and then export it to its HA partner (private key + public cert) and put the public cert as trusted CA in all your clients to avoid getting a warning that the connection is not trusted) or you create this CA cert (and key) in a "real" CA server (or just use openssl) and then import it to both your PA boxes in the HA pair (if you have a HA pair otherwise just import the private key and public cert to the PA box you got).
As a sidenote in order to handle cases where the real cert couldnt be verified you can use another cert (created just like above) as "untrusted cert" (and perhaps add it as untrusted issuers in your clients browsers).
This way if the real cert (between PA box and target system) was successfully verified the PA box will sign the inbound cert (between PA box and client) using its "trusted forward" cert and then send it to the client. While if something went bad (like the real cert is expired or issued by a not trusted CA etc) the PA box will sign the inbound cert using its "untrusted forward" cert and then send it to the client.
12-06-2012 07:40 AM
My testing aligns with your explanation. Just wanted to be sure I was interpreting my results and the various threads and docs I've read correctly.
Thanks!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
