- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
12-21-2020 06:25 AM
Hi All,
I'm looking to subject ssl traffic to my security profiles, but to do this, I believe I am understanding that for inbound traffic from the outside, you need to import the same certificate and key from each of your protected servers on the inside network into the Palo Alto. Is that true? If so, why? I don't really understand why the Palo can't use any cert, including a self-generated one to decrypt traffic coming in from the outside, then subject it to the security profiles, and drop it if it's malicious. Why does it have to be the same cert the internal servers have?
12-21-2020 06:48 AM
you could use a self-signed certificate, but this would mean all of your inbound customer will get an error message stating that the certificate is not from a trusted root CA
The way SSL decryption works is that the firewall performs what is basically a man in the middle attack.
If it has the cerver certificate, with a valid private key, it can simply open and close the session to take a peek inside, since it has the key of the server the client is talking to
If the firewall does not have the key, it needs to proxy the connection by terminating the client's connection on itself, and starting a new connection with the server. This means the client will get to see a web page signed by the palo alto self-signed certificate.
the way all browsers handle SSL connections, is they will go and verify if a server certificate is from a know issuer, so they will look at the certificate chain and see if the root certificate (the one signing the server certificate) is one of the trusted certificates. If the certificate was signed by a trusted root CA, it is a good cert and you get the little green lok in your address bar, telling you the validity of the certificate was verified and is ok. a selfsigned cert can't be verified so the browser will throw an error
if you're serving an 'internal' website to xternal users that have an environment you can control, you can provide them with the CA of your self-signed cert, or instruct them how to trust your self-signed cert, but this is cumbersome and may not work for all external users
another bonus to having the real certificate loaded, is that there is no need for proxying so inbound decryption is more resource friendly
hope this helps
12-21-2020 06:48 AM
you could use a self-signed certificate, but this would mean all of your inbound customer will get an error message stating that the certificate is not from a trusted root CA
The way SSL decryption works is that the firewall performs what is basically a man in the middle attack.
If it has the cerver certificate, with a valid private key, it can simply open and close the session to take a peek inside, since it has the key of the server the client is talking to
If the firewall does not have the key, it needs to proxy the connection by terminating the client's connection on itself, and starting a new connection with the server. This means the client will get to see a web page signed by the palo alto self-signed certificate.
the way all browsers handle SSL connections, is they will go and verify if a server certificate is from a know issuer, so they will look at the certificate chain and see if the root certificate (the one signing the server certificate) is one of the trusted certificates. If the certificate was signed by a trusted root CA, it is a good cert and you get the little green lok in your address bar, telling you the validity of the certificate was verified and is ok. a selfsigned cert can't be verified so the browser will throw an error
if you're serving an 'internal' website to xternal users that have an environment you can control, you can provide them with the CA of your self-signed cert, or instruct them how to trust your self-signed cert, but this is cumbersome and may not work for all external users
another bonus to having the real certificate loaded, is that there is no need for proxying so inbound decryption is more resource friendly
hope this helps
12-21-2020 07:10 AM
Thank you Tom.
Can I just point to a trusted and valid certificate on the web from the list that appears in the Palo instead of pointing to the certs on my inside servers? Definitely can't have the users getting that Palo message or they will flood the help desk.
12-21-2020 08:14 AM
Hi @dromanelli
Unfortunately that's not how it works. The firewall still needs to have a private key to 'a' certificate for it to be able to set up the 'server-side' communication for proxied SSL decryption.
The message they will get is actually their browser telling them it wasn't able to verify the certificate chain (like showing your ID at the bank, the teller needs to verify if the person on the ID is really you and the ID was issued by a trusted authority, the state)
If I may ask, why would you not want to import the server certificate onto the firewall ?
12-21-2020 08:22 AM
I'll have to check with the server team, but I believe we have a different certificate on every server, and our farm of servers is almost a full /24 worth of active machines, so it's just going to be a ton of overhead, not to mention getting the server guys to dedicate time to go through each server.
12-22-2020 12:37 AM
I hear you. You could check if they're using wildcard certificates on multiple servers, this would make life a little easier 🙂
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!