Issue while generating certificate from DNS challenge
Before 5 months I created SSL certificate for my domain lets-example.com using Buypass through HTTP-01 method. Now as the certificate is going to expire, I want to generate certificate for the same domain using DNS method.
I am using following command.
./certbot-auto --manual --preferred-challenges dns certonly -d lets-example.com --server "https://api.buypass.com/acme/directory/"
I ensured that no http service running on my server, even then the certificate is directly issued to me (using http challenge) where ideally I should be served with a DNS TXT entry(to be dome).
What am I missing or it is some bug ?
-
A couple of things, I just tested it using outside systems which worked great.
Your webserver should not affect this, mine was running at the same time.
I see a few differences, but the main one is the --preffered-challenges=dns and some additional commands which skips a few steps if you have not registered already. You will still be asked for confirmation two times and set the DNS record. I also have some structural differences where certonly appears first. Try the command below and see if it fixes the issue.
The TTL on your DNS record should therefore be set sufficiently low as to allow for faster attempts during testing, and has the format of "_acme-challenge.<FQDN>".
sudo /opt/certbot/certbot-auto certonly --manual --preferred-challenges=dns -m <EMAIL> --agree-tos -d <FQDN> --server "https://api.buypass.com/acme/directory/"
-
Magnus I used option -m <EMAIL> --agree-tos but still I found that certificate is being issue by HTTP method and no DNS TXT record is being generated against my request.
-
ProK After testing a good amount I've found that this is an issue on our side. We default to using the original method, but it is also connected to the stored system state. However, testing letsencrypts implementation of this scenario showed that they utilise the "preferred challenge" parameter for renewals.
The only current workaround I found was to delete my current account from the local system, and all traces of the certificate within the letsencrypt directory. Then re-obtain the certificate using the dns-challenge method.Thank you for providing us with this issue and I'll forward it to the development team and figure out a solution. It is currently summer vacation, so it will not be implemented until the middle of august at the earliest.
Best regards -
Magnus Thanks for acknowledgement.
I expect you will have a patch asap and hope that it qualifies for a bug-bounty coffee 😉😄
-
-
Hi ProK
Our implementation reuses authorization for a domain while it has not expired.
So when the request is made to authorize the domain, the server can send in response to the client previous authorization (in valid or pending state).
Consequently, referring to the scenario described above, when the Certbot was going to request new certificate to replace the expiring, it requested the authorization first. At this step the server returned authorization in valid state (validated using HTTP-01 method previously and still unexpired). The server considers any one of the challenges sufficient to make the authorization valid. Certbot proceeded to request new certificate, skipping any challenge validation, since the authorization was valid, and there was no need to prove the control of domain.
The preferred challenge option is a hint for Certbot to select the challenge, which should be used during the validation of control of the domain.
In the described case, to “force” DNS-01 challenge validation client could wait while the authorization expires, or use the https://tools.ietf.org/html/rfc8555#section-7.5.2 authorization-deactivation feature to relinquish its authorization to issue certificates for a domain and then requesting authorization and instructing client to prefer “DNS-01” challenge. However, the support of the latter in clients is unclear.
Regards,
Andriy Mahats
