"Let's Encrypt" and geoblocking issues

Maxstr — Fri, 19 Jul 2024 16:37:11 GMT

Hi, we have a couple 3rd-party applications that use Let's Encrypt for certificate automation. We also use geoblocking rules on our Palo Alto firewall because we are local government, so we block non-US based traffic. I recently learned that Let's Encrypt requires global access due to its nature of validation, because our certificates are failing to renew if I have the US-traffic rule enabled.

Has anyone found a way to whitelist Let's Encrypt traffic without opening it up to the entire planet?

Thanks!

Re: "Let's Encrypt" and geoblocking issues

Adrian_Jensen — Mon, 22 Jul 2024 17:32:14 GMT

With the rise of CDNs and anycast, geolocation of a destination servers can be very problematic as a given IP may trace to one location from one source, and a completely different location from a different source. There is no "location" field associated with an IP address registration, so various third parties make a best-guess as to the physical endpoint from their viewpoint and resell that data to others as geolocation... so it will never be perfect to rely on.

There are a few ways around the geolocation region coding, depending on what type of traffic you are filtering and how broadly you want to accept:

1) Custom Region - As many of these destinations are actually CDNs, which may host components of many different major sites, you may want to explore creating a custom region for those associated netblocks. This will override the default PaloAlto geolocation. The advantage of this is that it quickly encompasses a large swath of IPs which are known to be a major commercial hosting point, even those may technically reside in a different country. The disadvantage is that this is non-specific and "bad" sites can use CDNs just like "good" sites. The malware/AV/URL filtering tools should be used for filtering content rather than a geolocation.

Objects->Regions

Name=CDN

IP=1.1.1.1, 8.8.4.4, 8.8.8.8, 101.53.160.0/18, 118.214.0.0/16, 118.215.0.0/17

Policies->Security

Name=Allow Internet

SrcZone=Trust

DstZone=Untrust

DstAddr=US, CDN

Action=Allow

2) FQDN List - You can create a custom FQDN address object (or address group of objects) and use that as a destination, in addition to the geolocation. This has the advantage that you are targeting a specific destination address, regardless of the geolocation. The disadvantage is that this must be a specific, resolvable FQDN that you have discovered, wildcards will not work. (Note 1: You can also create an IP address/block list and use it in the same way/different variation of the custom region.)

Objects->Addresses

Name=ExampleSite1

Type=FQDN

Address=example.com

Name=ExampleSite2

Type=FQDN

Address=www.example.com

Name=ExampleImageSite

Type=FQDN

Address=images.example.com

Objects->Address Groups

Name=ExampleCorp

Address=ExampleSite1, ExampleSite2, ExampleImageSite

Policies->Security

Name=Allow Internet

SrcZone=Trust

DstZone=Untrust

DstAddr=US, ExampleCorp

Action=Allow

3) URL List - You can create a URL list to filter based on the requested content server name instead of the actual IP address. The advantage of this is that you can use wildcards for a range of FQDNs/subdomains. The disadvantage is that this only works for HTTP(S) type applications and the connection must first establish before the requested server name can be determined. (Note1: This is more suited towards allow/deny of specific sites for specific users, in combination with URL filtering, but can also be used for wider allows/denies. Note2: This is best combined with decryption, but will generally work without.)

Objects->Custom Objects->URL Category

Name=ExampleURL

URL List=example.com/, *.example.com/

Policies->Security

Name=Allow Internet

SrcZone=Trust

DstZone=Untrust

DstAddr=US

Action=Allow

Name=Allow Internet - specific sites

SrcZone=Trust

DstZone=Untrust

Application=web-browsing, SSL

URL Category=ExampleURL

Action=Allow

Re: "Let's Encrypt" and geoblocking issues

jmoscoso1 — Mon, 22 Jul 2024 22:28:31 GMT

There is not really a solution until LE decides to publish their validation endpoints, one common solution for this is to open the rule to the world only when a renew is needed and close it inmediatly.

Some have automated this process via API or simmilar but this depends entirely on your infrastructure.

topic Re: "Let's Encrypt" and geoblocking issues in Next-Generation Firewall Discussions

"Let's Encrypt" and geoblocking issues

Re: "Let's Encrypt" and geoblocking issues

Re: "Let's Encrypt" and geoblocking issues