Hello,
Our domain (odyhpc.com) is hosted by a 3rd party provider. A few weeks ago, we moved the records to a Cloudfare account and modified a few of them (per their recommendations). This is how they look like in the Cloudfare dashboard:
That seemed to be working OK but we have received the following message from the host provider:
Automatic Let's Encrypt renewal for odyhpc.com was attempted and failed.
This certificate expires on 2022-04-24 17:54:44 +0000 UTC.
Unable to renew certificate: Updating challenge for cpcalendars.odyhpc.com: acme: error code 403 "urn:ietf:params:acme:error:unauthorized": Invalid response from https://cpcalendars.odyhpc.com/.well-known/acme-challenge/dFoPtqnrGtZMqqLJUwecArspJzebq6fP-iACux5SC7M [2606:4700:3035::6815:583d]: 401 (order URL: https://acme-v02.api.letsencrypt.org/acme/order/39126393/73990413380)
You can configure/re-install/remove this certificate by logging into cPanel, and visiting the Lets Encrypt SSL page.
[Full disclosure: My background does not include website management and we cannot afford to hire someone for this purpose so I'm pretty much learning on the fly]. I guess that the host provider uses 'Let's encrypt' and that is why received the message. My question is mostly in regards to the records: Are the records set up correctly or do would you recommend any change? Any other suggestion would be also more than welcomed.
Thanks.
The likely reason that you are seeing this error is because you have one or more IPv6 address (AAAA) records in your DNS zone that don't point to the same server as your IPv4 address (A) records. I think there is no IPv6 proxied to your backend server right now (no AAAA records). You can use dig to see what the external world (and Let's Encrypt) sees of your DNS.
You should also look into how SSL/TLS works with Cloudflare:
Hi @griffin,
Thank you for your quick input. The Cloudfare support told me that the records on the cPanel zone editor are no longer significant and that the ones that really matter are those shown in the Cloudfare account (this came about when asking them if I should modify the records in the DNS zone to match those in Cloudfare, and their answer was that that step was unnecessary). Anyway, I just checked but found no AAAA records in the DNS zone: they are A (or TXT, MX CNAME). As far as I know, we don't have an IPv6 address.
I'll take a look at the documentation that you mention (hopefully I'll be able to understand most -if not all- of it).
I'm guessing 'dig' means 'Domain information gropper' but I don't have access to the server as it is hosted by a 3rd party. I've been clicking on the different icons available at cPanel but couldn't find anything related to the external DNS that you mention.
You might have some old DNS records "floating" out there that just haven't timed out yet. When you make DNS changes, it can take upwards of 24 hours (or occasionally more) for changes to propagate.
Hi @griffin,
Sorry but I had a couple of commitments that ran much longer than expected. I checked using dig and found 2 AAAA records, but I also found 2 A and 2 NS (dean.ns.cloudfare.com & emely.ns.cloudfare.com) records. My reaction was that the 2 AAAA (and the A) records are for redundancy purposes but maybe I'm misinterpreting it. Thanks.
There are two each for fallback/balancing purposes. I think the disconnection lies in that IPv6 requests, which Let's Encrypt makes by default during validation attempts, are not being sent to your backend server.
I don't think that I'm going to be able to figure out the disconnection by myself because these are technical details beyond my skill level. At this point, I probably need to contact the host provider. Thanks again.
The Cloudflare articles that I provided should be sufficient. Unless your hosting provider is also your domain registrar, I'm not sure they can do much, but you're welcome to try.
Hi @griffin,
The articles (and tips) have been very helpful in understanding how things are set up. However, what I cannot figure out is "the disconnection lies in that IPv6 requests, which Let's Encrypt makes by default during validation attempts, are not being sent to your backend server." Going over the articles hasn't allowed me to identify which element is causing this disconnection (the SSL/TLS encryption seems to be working properly and everything else looks fine); the only change that was suggested (and which wasn't already active) was to enable DNSSEC, but I don't think that this is causing the issue. Thanks.
NOTE: The domain registrar is a different business (namecheap) so the domain has different pieces in the host provider, Cloudfare, and registrar.
The idea is thus: when something requests to communicate with your webserver, it must first determine to which IP address to send the request. It does so by first determining the authoritative nameservers (NS records) for the domain name in question then querying those name servers for the requisite record(s), which in this case are A and/or AAAA. Let's Encrypt gives preference to AAAA records over A records, if AAAA records exist. In your case, those two AAAA records point to Cloudflare servers, not your hosted server. Once Cloudflare's server receives an IPv6 request (due to an IPv6 address being stored in the acquired AAAA record), Cloudflare's server establishes its own SSL connection with your visitor. Once that's completed, Cloudflare establishes an SSL connection via IPv6 with your hosted server then passes on the request from your visitor.
The issue is likely that you need to set your cloudflare SSL/TLS settings for that domain to use Full rather than Strict mode, otherwise Cloudflare redirects to https for you and if the particular http validation method is only listening on http port 80 then it will fail.
After rereading the articles and contacting the host provider, it seems like the only (potential) solution might be to toggle the IPv6 compatibility to Off, which seems to require the use of the API that I'm unfamiliar with. Either that works or I'll have to roll back the Cloudfare migration.
