I would very much like to believe it’s as simple as trying again later, but I’ve already done that. This is several attempts over several weeks, and these same domains (one of which is listed above) are reliably failing each time.
I can assume you’re certain of your answer, but I may return in a panic on March 29 or earlier.
That's bad. The error is an internal Letsencrypt error:
urn:ietf:params:acme:error:serverInternal :: The server experienced an internal error :: Remote PerformValidation RPCs failed. Skipping.
Your nameservers are buggy.
X
Fatal error: Nameserver doesn't support EDNS with max. 512 Byte Udp payload or sends more then 512 Bytes: ns1.mediatemple.net
X
Fatal error: Nameserver doesn't support EDNS with max. 512 Byte Udp payload or sends more then 512 Bytes: ns2.mediatemple.net
Problems with EDNS512 - check, but if this is a problem, Letsencrypt shows an error message.
Other EDNS-checks are not passed, but that shouldn't be a problem. Perhaps Letsencrypt has updated unboundtest, so the DNS Flag day is relevant (01.02.2019).
No. In fact, these servers are accessed by and are in constant contact with dozens or a hundred tablets connected via cell signal throughout the day.
When doing renewals, does certbot have to restart Apache? Does it try to do so gracefully? I could consider the possibility that it can’t graceful restart with hundreds of tablets keeping connections open in the particular method they do for our messaging system.
I haven’t had actual renewals fail on these yet, but they haven’t been up for renewal yet since this change was implemented.
From what I can tell, all of our HTTP validation attempts for this domain result in either a 404 for the challenge file, or a timeout. While the timeouts may be difficult to diagnose, the 404s should be pretty easy to track down and fix in the interaction between Certbot and Apache.
Is certbot logging any errors regarding attempts to write the challenge file in /.well-known/acme-challenge/?
Is Apache logging anything regarding the 404s which might point you to a solution?
I don’t see anything in the certbot log regarding inability to write a file. The log file says that the server reported errors, and I assume if it were a local issue it wouldn’t ask the server to do anything. The certbot log is too long to post here.
The Apache error log has some lines like this, though…
[Tue Feb 19 17:59:27 2019] [error] [client 172.104.24.29] File does not exist: /var/www/vhosts/best.mobiledispatch.me/httpdocs/.well-known
[Tue Feb 19 17:59:27 2019] [error] [client 13.58.30.69] File does not exist: /var/www/vhosts/best.mobiledispatch.me/httpdocs/.well-known
[Tue Feb 19 17:59:28 2019] [error] [client 52.29.173.72] File does not exist: /var/www/vhosts/best.mobiledispatch.me/httpdocs/.well-known
[Tue Feb 19 17:59:28 2019] [error] [client 66.133.109.36] File does not exist: /var/www/vhosts/best.mobiledispatch.me/httpdocs/.well-known
That would appear to be an incomplete path?
Thanks for the help so far. I’ll be checking up on this tomorrow.
Worse, yum upgrade certbot and yum info certbot are, at the moment, both telling me there’s no such package, and I’m pretty sure that’s how I got it on these systems to begin with, so… the plot thickens.
Would it be at all possible for someone to tell me where certbot might put an HTTP challenge so that I can try to figure out what might be going wrong?
Yes, right you are. I forgot for a moment which environment I was working in.
–debug-challenges seems to pause it, but it finishes without additional input. I’m not seeing the .well-known directory (even with -a, obviously) at the web root. In fact, on dlds.mobiledispatch.me, I’m not even seeing an entry in the Apache error log. I’ve removed all banned IPs, in case that was causing it, to no avail. I can manually navigate to dlds.mobiledispatch.me/.well-known/acme-challenge in a web browser, which of course gives me a 404 and an entry in the Apache error log.
