Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
11-09-2012 04:06 PM
I am trying to get this setup for a customer and this is my first time setting up ssl decryption. The customer has SBS2011 so they do have AD CA. I created a domain cert for the PA and exported the root cert. I imported both of these into the PAN firewall. I set the PA cert as the forward trust and forward untrust and the other as a root cert. I then imported the PA cert into my browser. I am still getting cert errors when trying to browse.
So I am seeking a little guidance here. I have search through the forums and read the managing certs pdf but it seemed to only scratch the surface.
Thanks so much in advance!
11-10-2012 12:40 AM
You create either a selfsigned cert (as a new root CA) or intermediate cert (from existing CA) and import both the public cert AND the private key to the PA.
Then on the client you add the public cert from above as trusted CA.
What happends during ssl-proxy is that the PA will have one outbound SSL session and one inbound towards the client. The PA will copy stuff from the outbound SSL session like expire date etc and use this private key you imported above to create a new cert which is then sent to the client in the inbound session.
The client will verify the issuer and since you already added this as trusted CA there will be no warnings on the client that the issuer is not trusted.
You can do a similar thing for bad outbound certs and have another public cert/private key combo as blacklisted CA. This way your client will be notified if the ssl terminated (outbound) session is malfunctioning security wise.
In addition to ssl-proxy the PA also features ssl-inspection. Where ssl-proxy is used for client (which you have control of) going towards for example Internet the ssl-inspection is used for servers which you have control of. In the later case you can add the servers private keys to the PA which will then make PA able to decrypt each session as a "sniffer" and if something bad is found it will block/drop the session. This also means that the client (on Internet or whatever) will handshake its SSL session directly with the server (compared to ssl-proxy where the handshaking is actually made with the PA device).
11-09-2012 06:04 PM
I think I have figured it out, I was importing the root cert instead of the ca cert. 😐
11-09-2012 06:18 PM
Ok maybe not. Here are more details.
I generated a new cert from my ca, call it pancert. On the PA, I imported the pancert and the caCert. I set the caCert as the ca and the pancert as the forward trust and untrust. I imported the pancert into my browser under trusted root cert authorities.
11-10-2012 12:40 AM
You create either a selfsigned cert (as a new root CA) or intermediate cert (from existing CA) and import both the public cert AND the private key to the PA.
Then on the client you add the public cert from above as trusted CA.
What happends during ssl-proxy is that the PA will have one outbound SSL session and one inbound towards the client. The PA will copy stuff from the outbound SSL session like expire date etc and use this private key you imported above to create a new cert which is then sent to the client in the inbound session.
The client will verify the issuer and since you already added this as trusted CA there will be no warnings on the client that the issuer is not trusted.
You can do a similar thing for bad outbound certs and have another public cert/private key combo as blacklisted CA. This way your client will be notified if the ssl terminated (outbound) session is malfunctioning security wise.
In addition to ssl-proxy the PA also features ssl-inspection. Where ssl-proxy is used for client (which you have control of) going towards for example Internet the ssl-inspection is used for servers which you have control of. In the later case you can add the servers private keys to the PA which will then make PA able to decrypt each session as a "sniffer" and if something bad is found it will block/drop the session. This also means that the client (on Internet or whatever) will handshake its SSL session directly with the server (compared to ssl-proxy where the handshaking is actually made with the PA device).
11-10-2012 08:14 AM
Thank you for that wonderful response! I have one more inquiry, is there any documentation on properly creating that intermediate cert using the A.D. CA? I want to make sure I do everything properly as oppose to stumbling my way through it until it works and potentially creating a vulnerability somewhere.
Also to make sure I understand what you put, after I create the intermediate certificate, that is the only cert I have to install on the PA, correct? I do NOT have to install the CA cert.
11-11-2012 07:55 AM
I got it setup correctly using a PA generated cert, so thank you again for the information!
11-11-2012 03:58 PM
I guess you have already read these documents on the subject?
11-11-2012 05:20 PM
Yeah! I read both of those and they helped a lot. I guess what I meant was the proper way to get the intermediate cert from A.D... so it's more of a Microsoft related question than it is a P.A. question.
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!
