We were hoping to set up our vmin server behind a load balancer but it seems that certbot isn’t able to issue or renew certs if the server its running on doesn’t have a public IP.
If we’re unable to give our vmin server a public IP, is anyone aware of any alternative CAs that might work with vmin that don’t have the same requirements / restrictions as certbot ie ideally it wouldn’t need a public IP and wouldn’t require that port 80 be open to create or renew SSL certs.
http://www.cacert.org/ also seem to issue free SSL certs. Has anyone tried using them with virtualmin and hundreds of subdomains?
We would consider commercial, paid for solutions too if they fit our requirements.
I guess I hadn’t thought much about it, but the cert is tied to a public IP. If it is a private network, then that’s a problem. Mainly because web browsers complain. Just add an exception?
while I’m using a home grown series of bash scripts calling certbot on a dedicated server to manage all my LE certs (using the dns approval method for 99 percent of them), and have never done it thru Virtualmin, speaking in general …
as you mention a load balancer, doesn’t certbot simply need a way for the outside world (ie, the LE server farm) to ‘reach’ your apache/nginx page in order to validate? That is, as long as the load balancer gives access to the server, I would think things would ‘just work’.
of course as I’ve never done any of this with Virtualmin, Virtualmin itself could have some artificial limitation here.
This is correct. Certificate validation for Let’s Encrypt has nothing to do with a public IP.
@danboid Let’s Encrypt needs to be able to make web requests to the .well-known directory for the domain you want a certificate for. Whether it goes through a proxy to get there is basically irrelevant, as long as it can get there.
It sounds like you have misconfigured your proxy (load balancer) and it’s breaking requests to http://domainname.tld/.well-known
But, and this is a big but: You need to handle setting up sharing the certificates to your proxy (load balancer). The TLS connection terminates at the proxy, so you need it to be setup to terminate TLS for every domain behind it, and it needs to have access to all of the TLS certificates, so you’ll need to copy them periodically via cronjob or Virtualmin post change script, or put them in a shared storage, or similar. Virtualmin doesn’t know anything about your proxies, so you need to take care of that bit of the equation.
Note this also means that in the simplest case you’re connecting to the backend domain over http, and the https termination is handled by the proxy (this is common in load balancer configurations, but may be a security issue if the connection isn’t on a private and secure network). TLS in the proxy to backend connection is an additional TLS connection and may or may not use the same certificate. But, it’s got to be unwrapped at the proxy before being forwarded on to the backend via some kind of connection.
Unless you’re buying TLS certs from a company that can validate via some other mechanism, you need web requests to files in .well-known to succeed so you can prove you own the domain. All of the cert providers that use a Let’s Encrypt compatible API work this way.
There’s also DNS validation, which Virtualmin supports, but that’s generally harder to make work, and requires Virtualmin manage DNS. It’s pretty much always simpler to just fix your web server (or proxy) configuration to allow requests to files in .well-known.
CAcert runs it’s website very well with https - but:
The browsers complain about all sites whose root certificate is not already pre-installed in the browser. Either you trust the browser that it has only installed trustworthy root certificates and hope that it has pre-installed all trustworthy root certificates. In the other case, you can install a root certificate yourself. For example, if you trust CAcert, install the root certificate from CAcert. Your browser won’t say a peep; as loud as it shouted before, it will trust your decision afterwards.
CAcert certificates are therefore suitable for internal applications, e.g. branch office → head office, etc. but not for sites with ‘walk-in customers’, as these usually do not have the CAcert root certificate installed.
CAcert’s root certificate can be found here https://www.cacert.org/index.php?id=3
you can also go the the cacert.org website and click on the menue “root certificate” (maybe in your computer’s language; on the top right), it will you proceed to the same page.
That’s not necessary. cacert.org is not a regular certificate issuer, but it’s not spam to talk about what it is.
Community-driven infrastructure is a positive thing, it’s not spam.
Certificates from CAcert are not appropriate for a business that needs to just work for non-technical users.
Anyway: CAcert is in no way an alternative to Let’s Encrypt for most users. OP needs to solve their actual problem rather than trying to find new problems to solve that have nothing to do with what they’re actually trying to achieve. This whole thread is based on entirely on misunderstandings from the beginning (but the post from @CAcert is accurate and informative, it just doesn’t help OP with their actual problem, because their real problem is validation with Let’s Encrypt, which they don’t want to solve for some reason).
Not Spam.
But they they do not seem to understand (and are not alone) that the world uses the internet’s browsers to arrive at and view their website. All browsers now expect a website to have a certificate so it is simply a bad advert when a potential customer arrives at their site to see a warning message. (*even more so when the message is about the product they aye trying to sell)
It is a relatively simple thing to fix - especially for someone who claims to be a provider.
This is also not helping. You’re misunderstanding what CAcert is. Whether it is useful for someone or not is for folks to decide for themselves, but it’s not a commercial service and “bad advert” and “potential customer” are nonsensical things to say about it.
OP’s problem is not (really) about CAcert, even though they mention it, due to misunderstanding what it’s intended for. We’re not going to litigate whether a community managed certificate provider is something people should use on a thread that should just be about OP figuring out how to validate Let’s Encrypt certs.
Pretty sure I am using the built in LetsEncrypt tools in Virtualmin as my Server has a public IP.
However, for VMs that don’t have a public IP, you need to use a tool that uses DNS validation if you don’t want to do port forwarding etc.
It’s been a while since I wrote this, but it should give you some ideas-
OP has a proxy that is forwarding requests to the Virtualmin system. That works fine. They don’t need to port forward and they don’t need to use DNS validation (and can’t if Virtualmin is not managing DNS), they just need to configure it appropriately so that requests to http://domain.tld/.well-known work correctly (not Let’s Encrypt validates via port 80, not 443, since it has to work before TLS works).
