Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for d3x0r.org
Waiting for verification...
Cleaning up challenges
Attempting to renew cert (d3x0r.org) from /etc/letsencrypt/renewal/d3x0r.org.conf produced an unexpected error: Failed authorization procedure. d3x0r.org (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching https://d3x0r.org:444/... o: Invalid port in redirect target. Only ports 80 and 443 are supported, not 444. Skipping.
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/d3x0r.org/fullchain.pem (failure)
All renewal attempts failed. The following certs could not be renewed:
/etc/letsencrypt/live/d3x0r.org/fullchain.pem (failure)
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you're using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
The argument was that I had to control ports 80 and 443 in order to be valid.
I did a search for '444' in the configuration, and it turns out I only have 1 line,
Which means to get :444 you had to connect to 80 or 443 in the first place.
Hence, I DO control 80 and 443.
Cox blocks incoming connections to 80 and 443 on IPV4; but the DNS address returns a V6 address... which lets encrypt IS able to conenct directly to 80 and 443.
Removing the rewrite rule and restart httpd allows me to renew; (I don't need help renewing)
@jsha, can you remind us why the CA doesn’t follow a 301 redirect to a port other than 80 or 443? (A long time ago, I thought it did, but now I know it doesn’t, but not why.)
Yes; I’m certain they have good reason fro make a baseline like that.
But what about us home webusers with WebVR programs; which requires HTTPS?
Again, my ISP blocks (before it gets to my modem) port 80 and 443.
You might be able to use the dns-01 challenge to authorize your hostname if port 80 nor 443 isn't available.
It depends on your amount of control over your hostname. E.g., DNS services providing an API for which certbot has a plugin makes sure you can easily automate issuing and renewing. A DNS provider without an API makes automation difficult and could require manually renewing every 2 to 3 months.
Luckily, I see this isn't an issue for you, as your IPv6 isn't blocked. But for other people blocked ports 80 and 443 can be a real issue indeed.
With DNS authorization, there are also other options in case your DNS provider does not have an API, such as acme-dns that should allow automated renewal with any DNS provider.
The BR that governs Let's Encrypt's http-01 validation says:
Confirming the Applicant's control over the FQDN by confirming [a random file or value] under the "/.wellknown/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port
I read this as saying your random value MUST come from an Authorized Port. Whether or not you follow redirects between authorized ports or not is an implementation detail left to CAs. You could even start with an unauthorized port and follow a redirect to an authorized port and that would be okay, though it wouldn't be very practical.
P.S. I forget if http-01 allows to redirect to other domains, but it seems if redirects to domains that aren't the Authorization Domain Name are okay, then redirects to ports that aren't Authorized Ports would also be okay. So either we shouldn't be doing that, or the BRs aren't the reason redirects to non-authorized ports aren't allowed.
I agree with this. The current configuration doesn't stroke with the conditions of the "http" validation outlined in the current BR. It's either no redirecting to non-authorized domain names at all if one would uphold the authorized ports only-condition or redirecting to non-authorized domain names to non-authorized ports would be fine.
Dereference the URL using an HTTP GET request. This request MUST be sent to TCP port 80 on the HTTP server.
...
The server SHOULD follow redirects when dereferencing the URL.
relevant? There are no restrictions of redirects - not domains, not ports.
That's the ACME protocol. That has nothing (directly) to do with the baseline requirements of the CA/B Forum, which dictates the rules for public CA's.