Http-01 renewal - how was this working?

Help
1

Taking over a site which has been working fine, but 90 days has come up, so logged in to renew cert which I thought would be easy. I am following these instructions: Renew an SSL certificate on a Bitnami stack in Lightsail | AWS re:Post

Those instructions refer only to using Auto or DNS, but found the site was set up with preferred challenge is http_01 and manual renewal:

sudo certbot certificates
Saving debug log to /var/log/letsencrypt/letsencrypt.log

Found the following certs:
Certificate Name: ctrl.zone
Serial Number: [redacted]
Key Type: ECDSA
Domains: *ctrl.zone .ctrl.zone
Expiry Date: 2024-09-25 00:42:11+00:00 (VALID: 1 day)
Certificate Path: /etc/letsencrypt/live/ctrl.zone/fullchain.pem
Private Key Path: /etc/letsencrypt/live/ctrl.zone/privkey.pem

bitnami@ip-172-26-10-153:~$ sudo cat /etc/letsencrypt/renewal/ctrl.zone.conf
'renew_before_expiry = 30 days
version = 2.1.0
archive_dir = /etc/letsencrypt/archive/ctrl.zone
cert = /etc/letsencrypt/live/ctrl.zone/cert.pem
privkey = /etc/letsencrypt/live/ctrl.zone/privkey.pem
chain = /etc/letsencrypt/live/ctrl.zone/chain.pem
fullchain = /etc/letsencrypt/live/ctrl.zone/fullchain.pem

'Options used in the renewal process
[renewalparams]
account = [redacted]
pref_challs = http-01,
authenticator = manual
server = https://acme-v02.api.letsencrypt.org/directory
key_type = ecdsa

I ran:
sudo certbot certonly --manual --preferred-challenge http-01 -d ctrl.zone -d *.ctrl.zone --force-renewal

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator manual, Installer None
Renewing an existing certificate for ctrl.zone and *.ctrl.zone
Performing the following challenges:
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.

My web server is (include version):
Apache running Wordpress on AWS Lightsail (so Bitnami)

I can login to a root shell on my machine - Yes

I have been doing a bunch of reading, and seen that "Let’s Encrypt currently only supports wildcard certificates through the dns-01 challenge"

Which is fine, but then how is the existing website working with http as seen above?.
And then immediately after reading that, I also see: "apache doesn't support dns validation"

In the end, I just modified the command to remove '-d *.ctrl.zone' and then ran the process so I now have an renewal done on just the ctrl.zone domain.

My question is, how did the person who set this up (~90 days ago) manage to set a wild card with HTTP?

I found the guide a bit unhelp, so happy to donate some words on this scenario as must be pretty common.

2

Hi @GrantBlack,

The person who set this up probably ran with a command like

certbot certonly --manual -d '*.ctrl.zone' -d ctrl.zone --preferred-challenges dns

and was then interactively prompted to create certain DNS records.

Sure enough, one of those DNS records still exists today:


[...]
;; ANSWER SECTION:
_acme-challenge.ctrl.zone. 300	IN	TXT	"yoKCclldS9Mk5In7QasflVPRR7DNhbg59UbdEj-b4zA"

So the overall answer is that the person who set it up originally didn't use the HTTP challenge, but rather than DNS challenge.

Looking more closely, I agree that the Certbot configuration that you have shows a default to the HTTP challenge rather than DNS challenge. So that in turn suggests to me that the person who set this up

(1) first ran

certbot certonly --manual -d *.ctrl.zone --preferred-challenges dns

and was prompted to create a DNS record and did so, but then wanted to add the base domain, running something like

certbot certonly --manual -d *.ctrl.zone -d ctrl.zone --preferred-challenges http

This would normally not work because of the issue that you ran into about wildcard certificates not being creatable based on an HTTP challenge. However, if you have recently (within a certain relatively brief period of time) issued a certificate for a particular name, including a wildcard name, the Let's Encrypt CA remembers that and considers your account still authorized to issue new certificates covering that specific name without repeating any kind of challenge. This authorization will expire much sooner than the certificate itself.

So, if the person who set it up had just successfully issued the first certificate using the DNS challenge, the second command would actually have worked because of the cached authorization for that name, despite the HTTP challenge being used for the non-wildcard name.

Cached authorizations are often a source of confusion for users because they can mean that things that "shouldn't work" appear to work, because something else that was done in the past has granted a continuing authorization on the account.

Does this explanation make sense to you?

5 Likes
3

That is a very good diagnosis @schoen

@GrantBlack If you do not need a wildcard cert you have a better option of using the bncert tool. bncert also allows automation. This is the recommended method by AWS for bitnami / lightsail.

Many people choose wildcards because it sounds better without realizing the implications. It is generally easier to setup and manage non-wildcard certs.

5 Likes
4

Thanks, that does make a lot of sense. Awesome level of support

I should have checked that the DNS record first, but when I saw HTTP didn't think to look; and as domain name and DNS entries were looked after yet another person, I could not easily change.

I think I might look at changing to using bncert, as my poking around I did see that and really don't want to do this again when we break for Christmas (Summer holidays) in 90 days

3 Likes
5

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