topic Re: ERR_HTTP2_PROTOCOL_ERROR in General Topics

ERR_HTTP2_PROTOCOL_ERROR

prad4ever — Mon, 08 Nov 2021 15:09:09 GMT

Hi,

We have recently upgraded our PA3200 to 10.1.2 and while we try to access a few sites are not accessible. SSL Decryption has been disabled globally. Still, while we access the URL from our network on any browser we get the above error. I have tried adding the URL in the SSL Decryption exclusion list to see if that resolve the issue it did not work. Any help would be appreciated.

Best Regards,

Pradeep

Re: ERR_HTTP2_PROTOCOL_ERROR

OtakarKlier — Mon, 08 Nov 2021 21:48:22 GMT

Hello,

Do you have Strip ALPN enabled? This article will show you how to disable it, so if your settings are similar, its disabled globally.

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PLpSCAW

Regards,

Re: ERR_HTTP2_PROTOCOL_ERROR

prad4ever — Tue, 09 Nov 2021 12:49:50 GMT

Hi Otakarklier,

The article is showing how to disable HTTP2 inspection when the decryption profile is enabled but in our case, we have disabled the SSL decryption globally.

Br,

Pradeep

Re: ERR_HTTP2_PROTOCOL_ERROR

BPry — Wed, 10 Nov 2021 03:10:27 GMT

@prad4ever,

Are you 100% sure that you aren't decrypting the traffic and have you verified that in your traffic logs on the firewall? The only reason I'm really bringing it up again is because without decryption the firewall shouldn't be causing any disruption with your HTTP/2 traffic at all. Outside of a website rightly having issues with HTTP/2, I've never seen that error on a firewall that isn't actively decrypting traffic.

Re: ERR_HTTP2_PROTOCOL_ERROR

prad4ever — Wed, 10 Nov 2021 12:50:42 GMT

Hi BPry,

Thanks for the reply. I have checked the traffic logs and the URL filter logs both traffic is passing the firewall and there is no decryption profile applied as SSL decryption is disabled globally. Also, we did a pcap on the firewall and found only http1.1 traffic passing at that instance.

Br,

Pradeep

Re: ERR_HTTP2_PROTOCOL_ERROR

LAYER_8 — Thu, 11 Nov 2021 18:56:28 GMT

I would reach out to the service provider and ask them about this on their server:

"Having cross-signatures means that each of our RSA intermediates has two certificates representing the same signing key. One is signed by DST Root CA X3 and the other is signed by ISRG Root X1. The easiest way to distinguish the two is by looking at their Issuer field.

When configuring a web server, the server operator configures not only the end-entity certificate, but also a list of intermediates to help browsers verify that the end-entity certificate has a trust chain leading to a trusted root certificate. Almost all server operators will choose to serve a chain including the intermediate certificate with Subject “R3” and Issuer “ISRG Root X1”. The recommended Let’s Encrypt client software, Certbot, will make this configuration seamlessly."

The DST root is allegedly expiring and being retired (haven't verified this myself), cross-signing isn't something the networking teams adopted at scale, so in the event you don't have the full chain of certificates in your PAN-OS store (please go verify), the service will always show as unreachable as it will never present as valid because the firewall sees an expired intermediate when there's a valid co-signed path in parallel where the trust store chain lookup didn't follow. Same is true of any device without all certificates (browsers, servers, etc.).

I've also attached a screenshot of which browsers (mixed bag) support cross-signing natively as well. Ultimately, decryption is hard but I think your answer lies in ensuring a full certificate chain is fully imported, trusted, etc.

I'm not convinced it's a remote service, nor am I unconvinced it's the firewall, in either case hope this context helps.