Support redirect for ports other than 80 and 443

Feature Requests
#1

kind of a continuation of this locked topic...

Cert is due for renewal, auto-renewing...

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)

1 renew failure(s), 0 parse failure(s)

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: d3x0r.org
    Type: connection
    Detail: Fetching
    https://d3x0r.org:444/.well-known/acme-challenge/69NhZ2CtLe2YIZ5_Zg4TckP_qW7uyfkwGVVzeS6xWro:
    Invalid port in redirect target. Only ports 80 and 443 are
    supported, not 444

    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,

conf/httpd.conf:RewriteRule ^/?(.*) https://%{SERVER_NAME}:444/$1 [R,L]

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)

1 Like
Certificat avec autre port que 443 et 80
#2

@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.)

1 Like
#3

As far as I have heard here on the forum is that the CA/B Forum doesn’t allow other ports to be used, even when redirected.

See for more information: Ballot 169 – Revised Validation Requirements

Authorized Port: One of the following ports: 80 (http), 443 (http), 115 (sftp), 25 (smtp), 22 (ssh).

By the way, as far as I can see, the BR doesn’t mention any reference to redirecting. Not allowing it nor dis-allowing it.

#4

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.

#5

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.

#6

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.

#7

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.

#8

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.

#9

Isn’t there

8.3. HTTP Challenge

https://tools.ietf.org/html/draft-ietf-acme-acme-14#section-8.3

  1. 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.

#10

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.

#11

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.