A client of mine has a domain, and pointed the A record of his domain to my machine, so i can develop a site.Usually, when i have the control of the DNS it's pretty easy to get the LetsEncrypt certificate and the https working.However, i'm not able to do this now that he has the DNS and it's pointing only the A record to my IP, and i'm not sure why.any clue?
Answer 1 :
Let's Encrypt supports multiple ACME challenge types.if you cannot use DNS-based domain verification, your alternative is to use the HTTP challenge, i.e. the
--webroot option in certbot.
In this mode, CertBot just needs to place a specific file in your web directory so that the let's Encrypt server can successfully download it – for which, the existing A record is sufficient.However, you need a web server to be already running on port 80.
- Configure the webserver to serve e.g.
/var/wwwat this domain, over plain HTTP.
certbot certonly --webroot -w/var/www -d example.com
- Certbot puts a file under/var/www/. well-known/acme-challenge/, let's Encrypt downloads it
- Now finish the webserver's configuration to also serve the domain over HTTPS.
(Note that you need to keep the plain-HTTP port-80 access working for every renewal as well.it's okay to redirect it to HTTPS, but the challenge file still needs to be accessible. )
Answer 2 :
Usually, when i have the control of the DNS it's pretty easy to get the LetsEncrypt certificate and the https working.
If you are using DNS-01 to validate a site, then TXT records are added temporarily to the DNS zone during that process.Assuming DNS-01 is being used, it seems likely that Certbot cannot add the necessary TXT records for validation.
The simplest alternative is to use HTTP-01 validation instead with the
--webroot options (as pointed out in the answer by @grawity).you cannot be issued a wildcard domain certificate with this method (e.g.*.example.com), but you should be able to use Subject Alternative Names (SANs) with it (assuming you need a certificate that also covers subdomains, etc.).