Somehow when I used --test-cert option, it succeeded once. When I removed the option, the error appeared.
However, it seems a valid certificate already generated. When use --test-cert option again, I got the following error message:
You’ve asked to renew/replace a seemingly valid certificate with a test certificate (www.mydomain.com).
We will not do that unless you use the --break-my-certs flag!
Note: --test-cert generates a “valid” certificate issued by the “Issuer” happy hacker fake CA, which ofcourse isn’t recognised as a real and trusted certificate authority… Good for testing, but it will not work for production servers.
As why Boulders DNS client can’t reach your DNS server: I don’t have a clue and without the hostname there’s nothing I could say or do to help.
Thank you for your reply. The certificate I got seems valid. It is issued by “Let’s Encrypt”. Both Firefox and Google Chrome did not complain. I will see if I can send you my domain name through a private message. Thanks.
Check the "Not Valid Before" field on the certificate. It will contain the timestamp of when the certificate was issued.
Well, this is still a beta. The only real methods currently supported are tls-sni-01 or http-01. Those both require a verification file to be accessible on the server.
The various plugins like webroot, apache, standalone, etc just provide different ways to get that file where it needs to be and optionally configure your webserver.
I know it was generated yesterday (1/15/16). I tried many times, just did not know which time it went through.
I had 80 and 443 open (with a self signed certificate at 443). So I assume both tls-sni-01 and http-01 should be working. This is very helpful information, though.
I think the problem is on the DN look-up step. There is no CAA record. Somehow it took very long time for domain name server to respond. Here are some results Osiris sent to me. He mentioned that getting ip is fast, but ‘one but last step is often quite slow’. Slowness could be the reason for failing at CAA checking step.
Domain Name servers: dns9.hichina.com. dns10.hichina.com.
;; Received 676 bytes from 2001:503:a83e::2:30#53(a.gtld-servers.net) in 6799 ms
;; Received 676 bytes from 2001:503:a83e::2:30#53(a.gtld-servers.net) in 701 ms
;; Received 676 bytes from 192.35.51.30#53(f.gtld-servers.net) in 2312 ms
;; Received 676 bytes from 192.31.80.30#53(d.gtld-servers.net) in 5115 ms
Based on the original error and those times, it’s very likely there are some problems with the DNS servers you’re using or the route to them from Let’s Encrypt’s data center, and it’s causing timeouts.
I am not forwarding acme requests to https. Actually, other than a specific folder, all requests can be accessed through either http or https.
When I renew the certificate, the error messages are the same.
Type: urn:acme:error:connection
Detail: DNS problem: query timed out looking up CAA for
I can see the requests from the validation server 66.133.109.36 and there were no errors found in apache2 log files. So the problem is still in the CAA records checking step.
Despite the error messages, the renewal seems to be successful. The expiration date has been updated.
@cryptoz: Can you share your domain name, the name of your DNS provider, and whether they use PowerDNS? We’ve gotten a number of reports of CAA timeouts on this thread, and they may be the same issue you are seeing.
I have a server in China with the same provider (Ailyun) and I get the same error.
I can provide details privately on my domain name. I believe this is just because requests in/out of China are often very slow even though the network within China is fast.
I’m closing this topic since it’s quite old, and each individual example of “query timed out” usually needs its own thread. Feel free to start a new thread if you have a problem matching this topic.
