I noticed certbot requires that port 80 be open for renewal and you cannot specify another port like 8000.
So, on my service, port 80 is reserved - fortunately for a bunch of services I don’t use, but my device REALLY doesn’t like me over-riding port 80 for pass through. I cannot over-ride port 22 (SSH) at all.
It would be nice if for RENEWAL it could use the HTTPS port (443) - using the old certificate - and for new sign up, we could specify an arbitrary port. Heck, even for sign up, it should be able to use port 443 with an expired certificate or even a temporary self signed one. I assume you guys are using wget to retrieve the temporary file that proves we have access to the website.
I’m using Apache and KDE Neon (basically Ubuntu) if it matters.
This has been the subject of quite a bit of discussion here, and seems highly unlikely to change–certainly not to any random port. If port 80 is a problem, investigate using DNS validation instead.
The very new, draft TLS-ALPN validation uses port 443. But it's not widely supported by clients (yet).
What runs on port 80? Can it be changed to handle Let's Encrypt validation appropriately? By copying files, or reverse proxying, or redirecting (perhaps to HTTPS)...?
What would be the reason NOT to change this, just out of curiosity?
Using port 80 can’t be any better than using port 443 with an expired certificate.
My DNS is fron www.dynu.com, it’s a dynamic address so I don’t think I can do DNS validation with that, but even if I can…
I can deal with port 80, but if wget is being used to retrieve the temporary file that certbot creates, it’s easy enough to write a wrapper that will handle an expired/self signed certificate. Heck, I have a TLS client that can do this, and if you want it, it’s here:
That’s a reference example, because I’m having to implement a TLS 1.2 compliant server using IPV6.
If you're curious, do a search--like I said, it's been discussed, extensively and repeatedly, and I don't see that it adds anything to rehash what's already been said. But ports > 1024 do nothing to validate control over the entire domain.
This is a complete non sequitur.
...and what makes you think it is?
The issue has nothing to do with the technical capability to connect to port 443--LE does this already, if port 80 redirects there. And, as @mnordhoff mentions, there's another validator that does run on 443. But the http-01 validator must initially connect on port 80.
Some large existing shared hosting environments have circumstances where using HTTPS for verifications will allow one customer to satisfy a Let's Encrypt challenge for another customer's domain name. This was conjectured to be true both for the obsolete HTTPS-01 method (which required placing a test file) and for the obsolescent TLS-SNI-01 method (which required placing a test certificate). The problem in each case is entirely about the behavior of shared hosting providers and the possibility that a validation can be completed inappropriately by someone who does not in fact control the domain name. These problems are not known to exist with the HTTP-01 method (specifically running on port 80) or with the new TLS-ALPN-01 method (on port 443).
This isn't relevant to people who aren't in shared hosting, but there's no way for the CA to distinguish who is or isn't affected by this condition, so the historical methods for validation on port 443 were removed or not placed in service in the first place.
Port 80 is HTTP, basically the standard port for any web server that isn’t using TLS over HTTP (HTTPS) which runs port 443 (in standard setups). Port 8000 is what is typically chosen when port 80 is unavailable. Any port > 1024 is unreserved.
To be clear, when doing HTTP-01 validation, the initial request is made to port 80. Redirects to HTTP on port 80 or HTTPS on port 443 are followed. Invalid certificates are accepted.
Edit: By the way, port 8000 is registered for iRDMI, whatever that is. Port 8080 is registered as an alternative port for HTTP.
If you’re curious, do a search–like I said, it’s been discussed, extensively and repeatedly
Point taken, and not to belabor the point, but I still need root or administrative access to write the temporary file in order to authenticate with certbot since it writes in /var/www/html/{something}.
Anyhow, upon further consideration about this topic, I realize I should just shut up, and be grateful for the service which I'm paying nothing for, because getting somebody to go to your website using a self signed certificate is really unpleasant, and generally a lot of work.
It depends on what you're doing. Certbot's webroot plugin will write it wherever you tell it to.
Certbot's apache and nginx plugins will write it to a location chosen by Certbot, or potentially not put it in an individual file at all.
Certbot is mostly designed with the intention of having administrative access -- it's configurable, but by default it saves files to /etc/letsencrypt/, the apache and nginx plugins modify the Apache and Nginx configurations, etc. All of that can be done without being root, but it usually requires careful configuration, of Certbot and of the other software.
Some clients are easier to install and run without root.
Even if you run a client without root, you still require whatever access is necessary to use your certificates.
Even if you run a client without root, you still require whatever access is necessary to use your certificates.
Yeah, but still, maybe to belabor the point a little more.
Earlier on, there were real problems with certificate validation. I think one exploit was that the Certificate Authority would send an email to some_email@<whatever_domain> and people that had an account on say... "yahoo.com" would just register an email, and request signature of a certificate, and get it. This was of course years ago - and maybe it wasn't exactly that, but it was something like that.
So anyhow, I'm certain there's really valid reasons to for certbot to do what it does. I just naively thought they may have overlooked something and am now realizing I'm fully out of my depth.
Nowadays email validation still exists but only 5 mailbox names can be used (admin, hostmaster, etc.).
(Email validation using arbitrary addresses from whois -- which brought its own problems -- also separately exists, but I believe it's being phased out.)
Similar problems exist for HTTP validation. It's no good when a shared web hosting server, or someone's NAT, allows one person to open a trivial listener on port 31337 and get certificates for anyone's domains pointed at those IPs.
Email and web validation were both tightened up.
Edit: By the way, Certbot can listen on any port, to facilitate port forwarding. But Let's Encrypt can only use 80 or 443.
Why isn’t this problem taken over by an RFC? Seems like the easiest way to fix the various problems that have been historically encountered is get a standard way for the HTTPS server to handle it.
The ACME RFC has been approved and submitted to IESG, but not yet assigned an RFC number. The working group is also working on discussions about authentication methods. For example, the new TLS-ALPN-01 method is specified in this draft:
So I guess the answer is that these methods are going to be the subject of RFCs, but the RFCs in question are still being written.
If you’re wondering about the shared hosting practices that created risks with HTTPS-01 and TLS-SNI-01 methods, I presume that people discussing them concluded that it’s already too late to change every host’s default behavior, even if an informational RFC were published saying that a certain behavior was a security risk.
Dynu does actually support text record creation. But only if you use your own personal domain (rather than one of theirs). There's also a pretty low record limit (4 I think) for free accounts. So you wouldn't be able to generate a cert with a bunch of names unless you upgraded.
There are at least a couple 3rd party ACME clients that support it as a DNS provider like acme.sh and Posh-ACME. Full disclosure, I maintain Posh-ACME.
