Earlier this year, I found that my Let’s Encrypt certificate didn’t automatically update upon expiry, which meant that I wasn’t able to access my site without clicking past Chrome’s warning messages. After a week or two, the certificate did finally refresh, so I hoped that the problem had been resolved.
Unfortunately, I’m now in the same position. My certificate expired back on September 20, and a new one hasn’t yet been issued.
Rather than wait for the problem to (hopefully) fix itself, is there a way to manually request a new Let’s Encrypt certificate?
A somewhat-related question: If I override Chrome’s warning messages and proceed to my site, is the data I enter (e.g. my username) still encrypted? Or will my data not be encrypted at all due to the expired certificate?
Ah, I just ran that command, and it looks like there might be an issue with my public URL’s host (Hostinger) that’s preventing the certificate from renewing:
"level":"error","ts":1790237309.9486268,"logger":"tls.renew","msg":"could not get certificate from issuer","identifier":"<my public url>","issuer":"acme-v02.api.letsencrypt.org-directory","error":"HTTP 400 urn:ietf:params:acme:error:dns - DNS problem: SERVFAIL looking up A for <my public url> - the domain's nameservers may be malfunctioning; DNS problem: SERVFAIL looking up AAAA for <my public url> - the domain's nameservers may be malfunctioning"}
{"level":"error","ts":1790237309.9486716,"logger":"tls.renew","msg":"will retry","error":"[<my public url>] Renew: [<my public url>] solving challenge: <my public url>: [<my public url>] authorization failed: HTTP 400 urn:ietf:params:acme:error:dns - DNS problem: SERVFAIL looking up A for <my public url> - the domain's nameservers may be malfunctioning; DNS problem: SERVFAIL looking up AAAA for <my public url> - the domain's nameservers may be malfunctioning (ca=https://acme-v02.api.letsencrypt.org/directory)","attempt":1,"retrying_in":60,"elapsed":1.343639881,"max_duration":2592000}
{"level":"error","ts":1790237371.6914477,"logger":"http.acme_client","msg":"challenge failed","identifier":"<my public url>","challenge_type":"tls-alpn-01","problem":{"type":"urn:ietf:params:acme:error:dns","title":"","detail":"DNS problem: SERVFAIL looking up A for <my public url> - the domain's nameservers may be malfunctioning; DNS problem: NXDOMAIN looking up AAAA for <my public url> - check that a DNS record exists for this domain","instance":"","subproblems":null}}
I’m going to check my Hostinger settings to see if anything needs to be updated there. If that doesn’t resolve the problem, I’ll let you know!
Thanks, everyone! I went into my DNS settings on Hostinger, and I’m guessing that I need to tweak something here. Here’s what they currently look like:
‘Public domain’ is my public URL, and ‘public subdomain’ is my subdomain. (So the full URL for my site is <public_subdomain>.<public_domain>.)
Because I don’t have a static ID, my CNAME record points to a DDNS domain rather than my public IP address. The A record just points to what looks like a Hostinger-owned IP address.
Perhaps I need to add an AAAA record to point to the same IP address as the A record? (My understanding is that CNAME, rather than A, should be used for DDNS domains, and I figure the same is true for AAAA records. But maybe, as a temporary fix, I could try creating an AAAA record that points to my public IP address’s IPv6 address. (I say ‘temporary’ because my public IP address changes periodically.)
Aha–when I replaced the CNAME entry that pointed to my DDNS domain with an A record for that same subdomain that pointed to my public IP address, my certificate got renewed successfully, and I was able to access the site. It turned out there was no need to add an AAAA record.
I was using a tplinkdns.com DDNS URL (which is available for free with my router), but perhaps I ought to switch to another DDNS service. That would allow for a more flexible setup anyway, since I wouldn’t need to have a TP-Link router in order to make everything work.
Any recommendations on DDNS services? Perhaps I could try No-IP for now. Alternatively, I could just see how long my ISP maintains my current public IP address before I have to change it. (Losing access to my site from the time the address changes to the time I revise it wouldn’t be catastrophic.)
If I’m interpreting what you wrote correctly, your router (TP-Link) updates the IP addresses for your DynDNS domain — which were refreshed by a forced disconnection — through which your Nextcloud server is supposed to renew its Let’s Encrypt certificates.
The problem here, however, is that your router doesn’t recognize the GUA (Global Unique IPv6 Address) of your Nextcloud Server at all—at least not if it was obtained via SLAAC. Instead, the router is likely reporting its own GUA.
However, since there is no NAT by default with IPv6, the IPv6 address points to the wrong device and is not NATed to the Nextcloud server.
If a domain has both an IPv4 and an IPv6 address, Let’s Encrypt will prioritize the IPv6 address for certificate renewal. However, the Nextcloud server cannot be reached this way, and the renewal fails.
Switching to a different DynDNS provider won’t change this. Instead, you’ll need to familiarize yourself with the basics of IPv6 or do without IPv6.
@adelaar You could very well be correct that this issue isn’t directly with the Tp-Link DDNS. However, I just came across this Tp-Link forum post that suggests that an issue with Tp-Link’s DNS servers are currently causing Let’s Encrypt challenges to fail. (Tp-Link, according to that same thread, is aware of this problem and working on a fix.)
In addition, my Tp-Link DDNS URL worked fine for around 10 months; it’s only recently that I’ve started having issues with it. So the issue might very well be a recent bug on Tp-Link’s DDNS end.
I’ll track the linked forum post and give my Tp-Link’s DDNS URL another try once they report a fix. But since I can access my network’s public IP address remotely using the Deco app on my phone, using my actual public IP address in place of the DDNS URL within my domain’s DNS records should work fine. If my ISP changes the address, I can just find my new IP address, add it to Hostinger, and wait an hour or so for the new address to get registered.
