Outbound traffic - stability of IP address of acme-v01.api.letsencrypt.org (alternative answer)

Hello,

I’ve just created an account to reply an alternative answer to a closed topic (same title).
The selected Solution in this topic recommend the use of an outbound proxy server.

If you are in an organisation where you cannot setup these kind of component.
But can ask for a whitelist-based set of traffic then here is the solution.

You can get the ip block from cdn provider :

# Get your local IP resolution
$ dig +short acme-v01.api.letsencrypt.org | tail -1
104.94.110.183

# Extract full netwoks 
#   (Based on akamai's current whois ouput, which may change in the future)
#   (Remove the grep part to find if you read this message in 2023 :p) 
$ whois 104.94.110.183 | grep ^CIDR:
CIDR:           104.94.108.0/22
CIDR:           104.64.0.0/10

Now you can ask your security/firewall guys to whitelist :

  • source: (your source ip)
  • destination (the extracted ip blocks destinations)
  • protocol: TCP
  • port: 443

Hope this will help someone in the future

Hi @frntn,

As you pointed out in your comment this is based on the response you received from the perspective of the machine you ran your dig from, at that snapshot in time.

Akamai is free to return a completely different answer in a completely different CIDR range whenever they choose. It will also likely differ based on the source of the query (e.g. this answer might work for one server but fail if used in a different geographic region).

For these reasons it seems like this solution is likely to have reliability issues. I would encourage folks in this situation to carefully weigh whether this is likely to cause them problems down the road that would break certificate automation.

Hi @cpu

I may have explained it a little more in depth.
Yes, the dig action has to be done from the server where certbot (or any other client) will be used.
So you’ll have the ip range from which akamai will respond your future cert requests.

Yes, edge servers selection use complex algorithms to get you the fastest response.
But you’ll always endup with a pool close to you, which will exists in a limited number of IP ranges (2 in my example).

Akamai have a HUGE number of endpoints : 30+ Autonomous Systems for more than 8000+ IP ranges total.
This makes the old firewall port opening absolutely unpractical.

I have been constrained to use this whitelist-based solution with a lot of big old company and this works pretty well actually. Edge server ip ranges can change, but they usually don’t.

I’m sure some (you?) will still disagree because it may seems unreliable or even inconsistent.
But from my experience I got a 100% success hit, which I bet is more than the proxy service availability for most users :wink:

This is why I believe this is a usable solution and wanted to share it with the community…

1 Like

It’s a nice idea - in reality you are talking about outbound traffic which is usually not filtered except to stop browsing to malicious or malware sites. If this is the case this idea would potentially would not work.

the blocks you mentioned /10 has a large number of IPs most of whom will have nothing to do with Akamai ( 4 million IPs)

I would find it highly doubtful that a security team that limits outbound traffic (no porn sites etc) would whitelist outbound traffic to 4 million IPs.

usually host based white-listing is the best approach for this and most modern firewalls support this

Andrei

it has got me thinking though

the TTLs for the API are about 2 hours which should be enough to complete the challenge

when I have time I will write a script that analyses the IP over a 48 period and check the stability

logic for client ->

$whitelistedIP = x.x.x.x
$currentip = nslookup (dig) acme-v01.api.letsencrypt.org

if $whitliesteip == $currentip -> proceeed with hook

if not - email -> cannot complete renew hook. API IP has changed inform security team to update

Andrei

That might not be true! In practice it might be but there's no guarantee

That might also not be true! CDNs will sometimes direct you to a point of presence (PoP) that isn't closest to you for a variety of reasons (maintenance, the location of your resolver, peering preferences, etc).

I'm sorry to hear you're constrained such that you have to find a whitelist based solution. I'm happy you shared your approach with the forum, I don't mean to provide a harsh critique but to point out some of the facets of the approach that might bite you or someone reading this in the future. If it works for you & your requirements who am I to tell you what to do :slight_smile:

.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.