"Let's Encrypt" and geoblocking issues

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

"Let's Encrypt" and geoblocking issues

L1 Bithead

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!

2 REPLIES 2

L6 Presenter

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

L1 Bithead

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.

  • 173 Views
  • 2 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!