0

If I'm understanding this correctly, the Palo Alto PA-220 allows for SSL/TLS traffic decryption using its proxy feature. By generating a Certificate Signing Request and loading it into the firewall, Clients should never receive a browser warning when accessing HTTPS sites?

1
  • No. It can't work like that. If the device is a TLS Terminator (clients connect to it, it is a TLS server, it handles the TLS connection and proxies requests to backend servers), it needs the private key of your certificate. Either the private key is imported into it or it generates the key itself and exports a CSR that a CA signs to produce the certificate and you import the certificate to the device. If it's a self signed certificate, you don't need a CA. If it's a certificate signed by corporate CA, you need the corporate CA. But anyway the device needs the private key, not just a CSR. – Z.T. May 7 '20 at 6:38
1

You misunderstand how TLS works.

A certificate signing request is exactly what it sounds like: A request for a certificate authority to sign a certificate. The request alone is worth nothing. Compare that with the request to be released from prison, compared to a signed pardon letter.

As Z.T. pointed out in a comment, the requests needs to be signed from a certificate authority.

You have two ways of going about this:

For outgoing traffic

Your company should have an internal certificate authority, which is rolled out automatically to all clients using your endpoint management system. Then, the proxy can generate a private key and a CSR, and the IT department can sign the CSR with the private key of the internal certificate authority.

It is typically then configured that all outgoing traffic from employee hardware is rejected and required to pass through the proxy.

For incoming traffic

Since you mentioned that you don't want clients to install additional certificates, I assume what you want is to monitor incoming traffic. The proxy would then act as a reverse proxy, taking incoming traffic, inspecting it and forwarding it to the designated endpoint.

The setup is identical to that of your currently externally visible endpoint. You take the private key and certificate from that server and place it on your proxy. To the end-user's computer, this proxy is the endpoint. The TLS connection ends at the proxy, where the proxy can inspect the traffic.

The request must ultimately be forwarded to the endpoint (if deemed safe), and I recommend using an internal certificate for that, meaning you create a new TLS connection between the proxy and the endpoint. This has the advantage of making it harder for internal attackers to gather sensitive information from the communication between proxy and server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.