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/"
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.