Cert renewal behind AWS global accelerator

Help
1

Hi folks,
I've filled in all the information from the help template below, but let me add a little more context.

I am able to successfully renew a cert if I point my A record straight to an origin in us-east-2. However, if I add AWS global accelerator into the mix, renewal fails.

What's intriguing to me is that while the dry-run is happening, I can curl the challenge at the challenge location just fine. E.g. if certbot adds:

rewrite ^(/.well-known/acme-challenge/.*) $1 break; # managed by Certbot
...
location = /.well-known/acme-challenge/zCs<snip> {
    default_type text/plain;
    return 200 zCs-tW<snip>UF
} # managed by Certbot

I can curl from my machine (SF) https://api.aiproxy.pro/.well-known/acme-challenge/zCs and get back the 200 and associated text

I'm wondering if it's because global accelerator uses two IPs?

Template below. Thank you,
Lou

My domain is:
api.aiproxy.pro

I ran this command:
/opt/certbot/bin/certbot renew --reuse-key --nginx --dry-run --no-random-sleep-on-renew

It produced this output:

Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: api.aiproxy.pro
Type: connection
Detail: 3.33.194.222: Fetching http://api.aiproxy.pro/.well-known/acme-challenge/w2oc7PMhFsndgmGYVdBQGQ8MiebLzm9EKxELvSw3CaQ: Timeout during connect (likely firewall problem)

Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.

Failed to renew certificate api.aiproxy.pro with error: Some challenges have failed.

My web server is (include version):
nginx version: nginx/1.26.3

The operating system my web server runs on is (include version):
AL2023
uname -a
Linux ip-172-31-7-39.us-east-2.compute.internal 6.1.84-99.169.amzn2023.aarch64 #1 SMP Mon Apr 8 19:19:24 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux

My hosting provider, if applicable, is:
AWS

I can login to a root shell on my machine (yes or no, or I don't know):
yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
certbot 2.10.0

2

Do you curl from the public internet? Or the instance itself or within the VPC?

Because I can't reach your domain using HTTP right now. Not even from an AWS EC2 in US-East. Which is the same error as issued by Let's Encrypt in your first post.

curl -i -m8 http://api.aiproxy.pro/.well-known/acme-challenge/Test404
curl: (28) Failed to connect to api.aiproxy.pro port 80 after 6004 ms: 
Connection timed out

Do you have anything that would block inbound HTTP requests for port 80 from passing through AWS GA on to your EC2?

Do you need to setup a specific listener or path for HTTP (in addition to HTTPS)?

That all said, the Cloudflare DNS is well supported for a DNS Challenge by Certbot and many ACME Clients. You could switch to using that and not worry about the HTTP traffic flows with an HTTP Challenge.

aiproxy.pro.            3600    IN      NS      venkat.ns.cloudflare.com.
aiproxy.pro.            3600    IN      NS      clarissa.ns.cloudflare.com.
3 Likes
3

Do you curl from the public internet?

Yup. I curled from my home. The difference is that I curled https://...

Do I understand that the challenge must occur over http? I suppose that does make sense, especially for the first cert issue.

In that case, I'm confused that renewal worked when I pointed the A record at my origin in us-east-2, because I don't even have an nginx server directive listening on 80 at all. Perhaps certbot adds a temporary one.

It's true that 80 is allowed straight to the instance. But as you correctly anticipated, I only have a GA listener for 443, which I didn't realize until right now:

Screenshot 2025-03-10 at 15.33.31
Screenshot 2025-03-10 at 15.33.311798×520 51.2 KB

That all said, the Cloudflare DNS is well supported for a DNS Challenge by Certbot and many ACME Clients. You could switch to using that and not worry about the HTTP traffic flows with an HTTP Challenge.

Good idea. I have simulated renewal working now! Here are my notes in case others find this too:

  • In cloudflare go to Manage Accounts > Account API Token > Create token > Edit Zone DNS template Include all zones.

  • Edit /etc/letsencrypt/cloudflare.ini to look like this. An email is not needed. Do not use _key use _token:

      dns_cloudflare_api_token = "<snip>"

  • Make certbot pick up your cloudflare API token:

    chmod 600 /etc/letsencrypt/cloudflare.ini
/opt/certbot/bin/pip install certbot-dns-cloudflare
sudo /opt/certbot/bin/certbot renew --reuse-key --dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini --dns-cloudflare-propagation-seconds 60 --dry-run --no-random-sleep-on-renew

Thank you @MikeMcQ !

1 Like
4

Yes, an HTTP Challenge starts with an HTTP request to you. You can redirect to HTTPS port 443 and the cert does not even have to be valid apart from doing a proper TLS handshake. See: Challenge Types - Let's Encrypt

Yes, with --nginx option Certbot can start an installed nginx system and create a temp server block for that purpose. It can sometimes go wrong so best not to rely on that. Personally I wish it didn't do that :slight_smile:

Glad you switched to DNS Challenge and got it working.

3 Likes