Let's Encrypt 6 day certs

Third Party News
1

Shorter is better I guess?

EDIT: I guess this is one reason they abandoned the expiration notices emails?

1 Like
2

The IP address certificate is far more interesting for Virtualmin.

We do a crazy and confusing dance where we try to auto-create a Virtual Server in order to fetch a cert for the hostname of the system if it resolves just to avoid the browser error right after installation. Being able to get one for the IP would solve that more reliably. IP-based certs are stupid and a bad idea in almost every case, except this specific one. Having it only last a few days is even better, because I don’t want anyone getting in the habit of using the IP (or the hostname) to talk to the system
once you have Virtual Servers with certs, you can use any of those. With an IP-based cert, we don’t even need the user to have working DNS for anything (the system hostname or whatever) for them to be able to log in to Virtualmin the first time without a browser error.

3

As for having it last just a couple of days—that confuses a lot of users. And if the idea is generally bad in the first place, we shouldn’t do it at all, even with exceptions. The hostname-based cert works well right now, and currently I don’t see a good reason to invest more time in setting up IP-based SSL, especially if it only lasts a few days.

Yet, it could technically serve as a fallback feature if the hostname SSL cert request fails, but it’d be a pretty complex one to implement!

Because I don’t want anyone getting in the habit of using the IP (or the hostname) to talk to the system.

The main reason we eventually decided to automate support for hostname SSL is because people were/are actively using them—and will keep using them—regardless of what we (or anyone else) advocate for or think is the “right” way. If that weren’t the case, this feature wouldn’t exist at all.

With an IP-based cert, we don’t even need the user to have working DNS for anything (the system hostname or whatever) for them to be able to log in to Virtualmin the first time without a browser error.

I wouldn’t mind automating this, but it needs to be clear and confusion-free. If we set up an IP-based cert, it could be for shortened or a standard duration, but with scheduled renewals. We’d also need to monitor and update it whenever the IP(s) changes. Keep in mind that a host might have four or more IPs, potentially a mix of IPv4 and IPv6, and all of this would need to be automated to make it a practical and smooth feature.

Generally, I’m not eager to spend time implementing this, but I wouldn’t oppose it either. However, removing the existing feature that creates an SSL cert for the hostname wouldn’t be wise—people are using it, and trying to change that would have any practical benefits and only cause confusion and frustration.

Talking of improvements—I just made a small tweak—the post-install message won’t show the IP:10000 link anymore if the SSL certificate for the hostname was set up successfully. We can bring it back if we ever decide to support IP-based certs—or for example, when the hostname SSL request fails.

@Jamie, also, I’m considering updating the Virtualmin installer to have Webmin also listen on port 8443 if the hostname’s nameservers point to Cloudflare. What are your thoughts on this?

1 Like
4

I didn’t actually know that IP based certs existed until now! But I can see how they could be useful for new installs to avoid the complexity of the default hostname. I will take a look to see how complex this would be to implement..

We could just do that for all installs. What’s special about port 8443 though?

5

There is also the cpanel ports that might be useful. Just an idea. I don’t know if they are passed through with cloudflare

6

Cloudflare only proxies for a handful of ports, and 8443 is one of them. 10000 doesn’t work for a Cloudflare address.

7

ZeroSSL has had this feature for years.

It’s not only about complexity; it’s about what people would do or expect, regardless of any recommendations. Practice has clearly proven it.

Also, getting it to work smoothly for IP addresses isn’t easy. We’d need to handle all public IPs on the system—which could mean dozens of IPv4s and, eventually, IPv6 too (though they don’t support IPv6 yet). Plus, we’d have to keep track of any new IPs being added or removed.

And, according to Let’s Encrypt, it will always be a short-lived certs—just 6 days. ZeroSSL, on the other hand, gives you 90 days—we’d need to support both and maybe plan for other SSL providers too, each with their own profiles and rules.

I don’t see it to be easy if done thoroughly.

If Cloudflare proxying is turned on, it only allows certain ports—mainly standard web ones. So my.hostname.tld:10000 won’t work, but my.hostname.tld:8443 will. That’s just because Cloudflare blocks most other ports when proxying.

2 Likes
8

We obviously won’t use those!

9

Seems like there’s no downside to listening on this port then.

1 Like
10

I think it’s useful only in the case where the admin is connecting to Virtualmin using an IP address. I would agree that this is pretty low priority though


1 Like
11

8443 is the Plesk port.

Service name Ports used by service
Administrative interface of Plesk over HTTPS TCP 8443, UDP 8443

regards
Jan

12

Just a quick point to consider for Virtualmin setups:
Many users start out with Cloudflare’s free plan when setting up their servers. Since the free plan does not support proxying port 8443, Cloudflare’s Free Plan supports ports—such as 2096, 2083, or 2087.

1 Like
13

The free plan of Cloudflare supports port 8080, just like 8443.

Ports 8080 and 8443 are alternative (http-alt and https-alt) ports—not exclusive to Plesk, just ones they wisely chose to use.

If we choose to listen on an additional port, it will be either 8080 or 8443.

14

Thanks Ilia, as you have stated - should have checked the source of truth :slightly_smiling_face:.

Here are the Cloudflare details :

Network ports compatible with Cloudflare’s proxy

By default, Cloudflare proxies traffic destined for the HTTP/HTTPS ports listed below.

HTTP ports supported by Cloudflare

80
8080
8880
2052
2082
2086
2095

HTTPS ports supported by Cloudflare

443
2053
2083
2087
2096
8443

Ports supported by Cloudflare, but with caching disabled

2052
2053
2082
2083
2086
2087
2095
2096
8880
8443
2 Likes
15

cpanel ports are also not official assigned to cpanel
2083 = radsec

8443 = pcsync-https, not https-alt

Plesk has been using ports 8443 from its very beginning in summer 2001

cpanel is more used us the US while plesk is more used in Europe. If you won’t use the cpanel ports then the same reasoning should apply to the plesk ports.

If you plan to use port 8443 only in virtualmin, then go ahead. I doubt that many people will have both plesk and virtualmin on the same server.

But if you also plan to use it in webmin then you will create problems for all the people that use plesk as customer interface and webmin as server configuration tool.

regards
Jan

16

Yeah, we’d only set Webmin to use port 8443 during the Virtualmin post-install setup—and only if the hostname is using Cloudflare nameservers.

17

Webmin and virtualmin use the same port as virtualmin is a module of webmin, so just change the webmin port and everything will work

18

Not sure how this affects the conversation but it is easy to forget. Never really knew the ‘why’ of the range.
image

19

The range is meant for possible use in RPC calls, using the current Webmin port (i.e. default 10000) plus up to 100 additional ports.

20

OK. Partially I didn’t want folks to forget there is a range even if it doesn’t affect this application of it.