I had a use case where I wanted to use the SSL Inbound Inspection on a Palo, but with a different X.509 certificate than the one on the server itself. That is: the backend server has its self-signed (or internal PKI-signed) certificate along with its hostname, while the decryption policy on the Palo uses a publicly trusted signed certificate for the same hostname. Just like a reverse proxy / load balancer / WAF.
To be more precise about the use case: An internal server has one certificate, signed by the internal PKI, but with various DNS hostnames – internal ones, such as foobar.internal, and external ones, such as myserver.company.com.
Now, external visitors shall see a publicly trusted certificate for myserver.company.com, which is different from the one installed on the server itself. This is exactly what a reverse proxy is meant for. But to avoid another component (and since the Palo can do the security part by looking into the TLS session), I wanted to use the SSL Inbound Inspection – but with a different certificate.
By the way: Why is it still called “SSL” and not “TLS”? This really triggers me. 😂
My lab consisted of the following:
- PA-440, PAN-OS 11.2.11
- Raspi with a self-signed certificate with CN/SAN of
pi10-test5.weberlab.de - A Let’s Encrypt certificate with the same name,
pi10-test5.weberlab.de - This Let’s Encrypt certificate, including its private key, was uploaded to the Palo and used in the decryption policy.
But, as already noted, this setup is working.
The decryption log showed some “certificate verify failed” errors:
while the traffic log listed those sessions as “policy-deny”, which is not accurate from my point of view: (and those lines were not highlighted in red, though the checkbox was hit)
The show counter global revealed some ssl_inbound_cert_mismatch hits:
|
1 |
ssl_inbound_cert_mismatch 70 0 error ssl pktproc No matching server certificate found in config |
which exactly aligns with the hit count on the decryption policy:
This KB article from PANW gives some details about that behaviour:
It compares this fingerprint against the one stored in your local SSL Inbound Inspection rule.
If the fingerprints do not match, the firewall immediately kills the session and logs the error: Server and Firewall’s certificate mismatch.
For whatever reason, I’m seeing a different error message. Anyway, that’s the root cause here. AFAIK, it should be possible to do this TLS interception regardless of the exact certificate being present. Hence, I suppose that it’s a limit by design.
Any comments? ;)
Soli Deo Gloria!
Photo by Robert Clark on Unsplash.
Even though I can totally see the use case, I also understand why Palo designed it this way. It’s not a full reverse proxy that terminates a session, then eg manipulates the header or doing load balancing stuff, and establishes a new session, but rather a „transparent“ decryption process for inspecting the content and then forwarding the packet exactly as it was before to the destination server or dropping it because of a policy action.
Also under the hood the inbound inspection behavior changed with PanOS 10.1 to a more proxy like then before.