Certbot show_account fails with acme-v01.api.letsencrypt.org DNS lookup failure

My domain is:

I ran this command:

certbot show_account

It produced this output:

An unexpected error occurred:
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='acme-v01.api.letsencrypt.org', port=443): Max retries exceeded with url: /acme/reg/12067950 (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f638a431de0>: Failed to establish a new connection: [Errno -2] Name or service not known'))

My web server is (include version):

Apache 2.4.53-2

The operating system my web server runs on is (include version):

Debian sid

My hosting provider, if applicable, is:

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):

1.25.0

I have been using/renewing my certificate using v02 of the acme protocol for ages, and renewals are working fine. However, it looks like there is an old account config in /etc/letsencrypt/accounts/

drwx------ 3 root root 4096 Dec 22  2017 acme-staging.api.letsencrypt.org
drwxr-xr-x 2 root root 4096 Jan 18  2019 acme-staging-v02.api.letsencrypt.org
drwx------ 3 root root 4096 Apr  7  2017 acme-v01.api.letsencrypt.org
drwxr-xr-x 2 root root 4096 Feb 21  2019 acme-v02.api.letsencrypt.org

The v02 config is a symlink to v01.

The regr.json file in the account config directory contains a reference to https://acme-v01.api.letsencrypt.org/acme/reg/12067950 - does anyone know the correct way to fix this?

  1. Can I just edit the file to change from v01 to v02?
  2. Should I remove the v02 symlink and rename the v01 directory to v02?

Thanks

1 Like

show_account does not use the account folders in the /etc/letsencrypt/ directory. It's purpose is to fetch the details directly from the ACME server, so you get the most up to date info.

You should debug any networking issues your host has, starting with DNS looking at the error message.

2 Likes

As far as I can tell, there is no networking issue on my host. Also, I cannot find a DNS server which resolves the name acme-v01.api.letsencrypt.org.

root@danieljamesscott:~# dig +short acme-v01.api.letsencrypt.org
root@danieljamesscott:~# dig +short acme-v02.api.letsencrypt.org
prod.api.letsencrypt.org.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
172.65.32.248
root@danieljamesscott:~# dig +short @8.8.8.8 acme-v01.api.letsencrypt.org
root@danieljamesscott:~# dig +short @8.8.8.8 acme-v02.api.letsencrypt.org
prod.api.letsencrypt.org.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
172.65.32.248
root@danieljamesscott:~# dig +short @1.1.1.1 acme-v02.api.letsencrypt.org
prod.api.letsencrypt.org.
ca80a1adb12a4fbdac5ffcbc944e9a61.pacloudflare.com.
172.65.32.248
root@danieljamesscott:~# dig +short @1.1.1.1 acme-v01.api.letsencrypt.org
root@danieljamesscott:~# ping acme-v01.api.letsencrypt.org
ping: acme-v01.api.letsencrypt.org: Name or service not known
root@danieljamesscott:~# ping acme-v02.api.letsencrypt.org
PING acme-v02.api.letsencrypt.org(2606:4700:60:0:f53d:5624:85c7:3a2c (2606:4700:60:0:f53d:5624:85c7:3a2c)) 56 data bytes
64 bytes from 2606:4700:60:0:f53d:5624:85c7:3a2c (2606:4700:60:0:f53d:5624:85c7:3a2c): icmp_seq=1 ttl=58 time=1.20 ms
64 bytes from 2606:4700:60:0:f53d:5624:85c7:3a2c (2606:4700:60:0:f53d:5624:85c7:3a2c): icmp_seq=2 ttl=58 time=1.20 ms

Are you saying that acme-v01.api.letsencrypt.org should resolve to something?

As I thought, the v01 endpoint is not supposed to resolve:

Please can someone let me know whether it is safe to edit my account configuration, or what I should do to get things working. It appears as if something was not updated when I updated from v01 to v02.

Hm, no, sorry. I didn't see v01 in the error message to be honest. Certbot shouldn't be using that hostname any longer, it has been deprecated and subsequently removed for some time now.

This issue seems to be due to the symbolic link. Apparently, the regular functions of Certbot can get enough information in the v01 directory, but the show_account function uses the account URL from regr.json.

I'm not sure it's wise nor safe to update the v01 account directory to a v02 directory. The URL has changed to https://acme-v02.api.letsencrypt.org/acme/acct/12345 (where 12345 is the "account number"). Maybe it's enough to update that URL? I dunno.. Please backup everything before you start tinkering.

If you don't have anything coupled to your specific account (e.g., rate limit excemptions, ECDSA white list), you can just as easily register a new account with the v02 ACME server by removing the v02 symbolic link pointing to the v01 directory and run certbot register. (That said, I'm not seeing a symbolic link in your ls -l output above?)

4 Likes

OK, thanks. I can definitely re-register my account, but I would prefer to learn how it works and fix it, if possible.

Is there any information available on the structure/contents of the accounts/ directory? It appears that I have 2 'real' accounts, and 2 'symlinked' accounts, so it would be good to know whether I need them all, or whether just 1 would be sufficient?

The symlinks are a level down from the accounts/ directory, which is why they did not show up originally:

root@danieljamesscott:~# ls -al /etc/letsencrypt/accounts/*
/etc/letsencrypt/accounts/acme-staging.api.letsencrypt.org:
total 12
drwx------ 3 root root 4096 Dec 22  2017 .
drwx------ 6 root root 4096 May 26 09:02 ..
drwx------ 3 root root 4096 Dec 22  2017 directory

/etc/letsencrypt/accounts/acme-staging-v02.api.letsencrypt.org:
total 12
drwxr-xr-x 2 root root 4096 Jan 18  2019 .
drwx------ 6 root root 4096 May 26 09:02 ..
lrwxrwxrwx 1 root root   68 Jan 18  2019 directory -> /etc/letsencrypt/accounts/acme-staging.api.letsencrypt.org/directory

/etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org:
total 12
drwx------ 3 root root 4096 Apr  7  2017 .
drwx------ 6 root root 4096 May 26 09:02 ..
drwx------ 3 root root 4096 Apr  7  2017 directory

/etc/letsencrypt/accounts/acme-v02.api.letsencrypt.org:
total 12
drwxr-xr-x 2 root root 4096 Feb 21  2019 .
drwx------ 6 root root 4096 May 26 09:02 ..
lrwxrwxrwx 1 root root   64 Feb 21  2019 directory -> /etc/letsencrypt/accounts/acme-v01.api.letsencrypt.org/directory
2 Likes

As far as I know, this is not documented.

There's nothing wrong with having a staging account. If you'd delete that, it would be recreated when you're using the staging environment, e.g. when using the --dry-run option.

I'm not sure where those symbolic links come from. I can't remember that Certbot did that itself on purpose, but maybe @_az can shed some light on that?

3 Likes

They are before my time, but I believe the reason the account symlinks got created was to automatically preserve the same ACME registration in the transition from ACMEv1 (now defunct) to ACMEv2.

2 Likes

Ah, so Certbot did that.. Well, that's problematic as the contents of the uri part of regr.json therefore also defunct. Maybe the keys are fine, but other stuff isn't.

2 Likes

It sounds like this is a bug in show_account that should be fixed by translating v1 account URLs to v2.

AFAIK Boulder doesn't care whether you send the old or new account URL in the JWS.

4 Likes

show_account just calls query_registration() in acme :wink: So acme would need to be fixed methinks.

Although the translation part probably can also be done in show_account(), not sure what's wise.

2 Likes

It might also be wiser to do this by sending a signed request to newAccount with onlyReturnExisting set. That way, we don't have to assume what the account URI is.

But let's talk about this on the issue tracker later.

4 Likes
3 Likes

Nice to know that I found a bug! :smile:

I've deleted my account, registered a new one and changed my cert to use the new account. It's all working fine now.

Thanks

4 Likes

Note that this bug is now fixed and will be part of the 1.29.0 release of Certbot.

4 Likes

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