Lost access to certs in nameserver move

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: *.medicard.systems

I ran this command:
sudo certbot renew --force-renewal --server https://acme-staging-v02.api.letsencrypt.org/directory --cert-name medicard.systems
It produced this output:
Saving debug log to /opt/local/var/log/letsencrypt/letsencrypt.log

Processing /opt/local/etc/letsencrypt/renewal/medicard.systems.conf

Plugins selected: Authenticator manual, Installer None
Failed to renew certificate medicard.systems with error: You should register before running non-interactively, or provide --agree-tos and --email <email_address> flags.

All renewals failed. The following certificates could not be renewed:
/opt/local/etc/letsencrypt/live/medicard.systems/fullchain.pem (failure)

1 renew failure(s), 0 parse failure(s)
My web server is (include version):

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

My hosting provider, if applicable, is:
Rimuhosting.com (no plugin available, but python wrappers for the rimu dns api are available.)
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.13.0

I changed my nameserver on medicard.systems and did not bring the _acme.challenge entry across. 6 weeks later, the cert came up for renewal, and the validation failed on the new server.

When I first created wildcard certs, I used a manual process that involved updating the nameserver manually.

I went through that process, created a TXT record for _acme.challenge.etc… and the certificate was created.

I create these certs locally, and scp them onto the servers, so I have /opt/local/etc/letsencrypt/{live, archive, renewal, etc}. I found that I subsequently had in the letsencrypt directories, directories for both medicard.systems and medicard.systems-001.

I also found that on my ehealth.id.au server, the _acme.challenge is entered as a CNAME, rather than a text, so I gather thing have been changing fairly rapidly.

I tried a --force-renewal to staging to test whether I had stuffed it up and indeed I had. (See output above.)

Given the situation, and my ability to wind back, how should I go about cleaning up?

1 Like

Welcome to the Let's Encrypt Community :slightly_smiling_face:

Every new certificate and renewal requires new _acme-challenge TXT records to be created. Your old one(s) would have been worthless, so you lost nothing. :slightly_smiling_face:

Yep, that's the long, manual way.

These were likely either duplicate certificates or contained slightly different domain names.

That's only if you want to delegate the location of the TXT record(s) to a different DNS zone.

Avoid that parameter like nuclear waste. :wink:

I can certainly help you with that.

Forgot to add:

Before testing to staging, I had removed the old medicard.systems directories and configs, and renamed the medicard.systems-001 entries to medicard.systems, including the links within live, and any similar changes that may have been necessary in renewal/medicard.systems.conf.

1 Like

Using manual dns validation (creating TXT record manually) means you will always have to manually update the TXT records for every renewal. You should avoid this at all costs.

I recommend investigating acme-dns for DNS validation challenges (where you run a server which in turn answers DNS challenges via CNAME redirection). Alternatively if you can move your DNS hosting to a DNS provider supported by your ACME client you can then automated DNS updates as required.

1 Like

What does this say?

sudo certbot certificates

Note: @webprofusion is absolutely correct. We'll get to that.

For this particular certificate:

Certificate Name: medicard.systems
Serial Number: 4d5e8ada6b442c480cf106df2e290e23f49
Key Type: RSA
Domains: *.medicard.systems
Expiry Date: 2021-06-23 12:26:19+00:00 (VALID: 89 days)
Certificate Path: /opt/local/etc/letsencrypt/live/medicard.systems/fullchain.pem
Private Key Path: /opt/local/etc/letsencrypt/live/medicard.systems/privkey.pem

1 Like

I have renewed many times, but I have never had to manually change the TXT record. Once it was created, it continued to work.

I have renewed many times, but I have never had to manually change the TXT record. Once it was created, it continued to work.

The TXT record is only valid one time for the specific order. You either had some automatic process that was updating it, or the certs were being obtained through HTTP-01 or TLS-ALPN-01 validation.

If your DNS provider doesn't have a good automated method to update records with certbot, acme-dns would be a good option.

1 Like

I concur with @ski192man. Having written my own ACME client (CertSage), I can assure you that TXT records are never reused once authorized.

You probably want your certificate to also cover medicard.systems in addition to *.medicard.systems.

For manual:

sudo certbot certonly --agree-tos --register-unsafely-without-email --cert-name medicard.systems --manual --preferred-challenges dns -d "medicard.systems,*.medicard.systems"

The certbot command above will require creating two different TXT records both for host _acme-challenge.medicard.systems.

All of my domains are using the CNAME challenge, but that was set up a while ago, and when I forgot the CNAME redirect I went looking for a method that did NOT involve a plugin for a particular provider. That's how I found the TXT method, and everything went downhill.

I have now found the original method, also using --manual to get the CNAME record. I removed all the old medicard.systems records on my local system, ran
sudo certbot certonly --manual --manual-auth-hook /opt/local/etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d *.medicard.systems -d medicard.systems
and was presented with a CNAME to add to the DNS records. Once I did that, I was back to what I believe is the status quo ante.

Thanks for pointing out the TXT error. If I had bothered to looks at the DNS records for my other domains, I would have seen that.

1 Like

Ah... you're using acme-dns. :grinning:

That's still a dns-01 (TXT record) challenge. It's just that the location of those TXT records is delegated to a different DNS zone using a CNAME record. It's a bit like telling the Let's Encrypt server to "look over there for the information that you seek". The hook script actually creates (and destroys) the TXT records for you (in the delegated DNS zone indicated by the CNAME record) so that you don't need to. By just leaving the CNAME record in place, your renewals can be automated.

The --debug-challenges parameter pauses the execution of certbot once the TXT records have been created so that you can see them. You don't actually need (or want) to use that parameter for automated renewals.

In my script I don't use --debug-challenges, but I had to set up for medicard.systems from scratch because of my stuff-ups. That allowed me in initialise the CNAME.

1 Like

Interesting... :thinking: I never considered using the --debug-challenges parameter upon initially setting up acme-dns. I'll need to keep this in mind.

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