I have a system created that of course has evolved over the years but this is what it looks like right now…
Physical server with pfSense which has 2 Ethernet ports, 1 for WAN, 1 for connection to switch for LAN.
Inside LAN I have a Physical Server with multiple virtual servers put two important ones that both need to be accessed from outside.
Virtual Server #1: Houses main web page and CRM software (Ubuntu)
Virtual Server #2: Houses Nextcloud (Ubuntu)
They have to be on separate machines because they require different software that clashes when on the same machine.
I want to use HAProxy & ACME to allow this to work because I want to have both using Certificates. I have never fully understood how to fully allow this to work. I currently have the CRM using port forwarding feature from pfSense since I need that secure. I would like to allow pfSense to handle the certs. Does anyone have advice for this?
In the past I used only a webpage on one server and just did port forwarding. Do I still need port Forwarding with HAProxy? It seems like there should be something that can read the packets and say “https://nextcloud.mydomain.com” should redirect traffic to VM #2, and “https://www.mydomain.com” points to VM #1.
I hope this makes sense I really appreciate any light someone can shed on my brain that seems to be running the little wheel right now.
Your exactly describing what a reverse proxy offers – the ability to forward connections from a common frontend to a different backends based on http address. (HA proxy also does tcp reverse proxy). A reverse proxy oftentimes functions to offload the TLS connection which then forwards the connection upstream (or to the backend) in an unencrypted manner. If desired the reverse proxy can re-encrypt to the upstream component however this also brings a more complex setup now with SSL certs installed at the reverse proxy and upstream.
HA proxy is one reverse proxy, others have used Traefik, Caddy, or nginx. I’ve never had the greatest of luck with HA proxy personally, so I just port forward to a VM running in the DMZ that runs nginx and I do the reverse proxy from this machine along with the certificate management. Others have used docker instances for the reverse proxy. There are a lot of different ways to attack your problem, but unfortunately you just need to start somewhere. I believe I started using Nginx mostly since at the time I was using this as a reverse proxy for Nextcloud and the Nextcloud has very good documentation on how to setup an nginx or apache reverse proxy. From there I just kind of expanded my knowledge.
@LTS_Tom Thanks for your response. I can get this to work if the sub-domains are on different servers with different IP addresses. However, I have a machine that has docker and the sites are on different ports on the same IP. I can’t get this to work like the first way however.
Hello Tom,
I was able to follow your video and got the ACME “Lets encrypt” to work, but then I ran into a snag or should I say I just realized that you can’t copy issued certs to another Netgate device.
So I manage different sites using the same domain name and of course I have all my subdomains setup in dns on my web server. I would like to deploy “Lets encrypt” on all netgate devices using the same primary domain. Like I said I got the first one setup with a wildcard config but during the next device I noticed that I can’t import or paste an issued cert.
My web server is hosted at Linode running ubuntu with cpanel. Yes I am using cPanel as my dns server right now. I tried to use the Linode API token but could not get it to work, so I ended up using the “DNS Manual” mode. As you know that ureses the ACME challenge txt record and you can only have one for that domain.
Not sure what to do at this point, any tips would be awesome…
So to sum it up in a nut shell, need to setup ACME on 15 Netgate devices all using the same primary domain.
Example: device1.mydomain.net device2.mydomain.net
and so on to number 15.
I don’t understand the use case but for that to work you would not want a wild card but just a cert for each systems full domain device1 dot the domain, device2 dot the domain.
Let’s Encrypt wildcard certificates are only valid for one level in the domain hirarchy:
With a *.domain.tld certificate you can use sub1.domain.tld, sub2.domain.tld, but you cannot use sub.sub1.domain.tld or sub.sub2.domain.tld.
With a *.sub.domain.tld certificate you can use sub1.sub.domain.tld, sub2.sub.domain.tld but you cannot use sub1.domain.tld or sub2.domain.tld
So, If you want to distribute certificates for 15 firewalls on the first level, e.g. fw1.domain.tld, fw2.domain.tld etc, you can theoretically distribute a *.domain.tld certificate manually or via SSH, but that’s not really feasable over 15 different remote sites, imho. So you would probably want to use one of the following two methods:
1. You want to use the certificate only for the firewalls themselves
As Tom already said, in this case you don’t need wildcard certificates. Just let each firewall get a certificate for itself:
2. You want to use the certificate for multiple local services e.g. via HA proxy
In this case the solution from my previous post would come into play:
Firewall 1 obtains a wildcard certificate for *.site1.doamin.tld. The firewall itself could then use e.g. fw.site1.domain.tld. Other local services on that site would use service1.site1.domain.tld, service2.site1.domain.tld etc…
Firewall 2 obtains also a wildcard certificate, but for *.site2.doamin.tld. The firewall itself then uses fw.site2.domain.tld. Other local services on that site would use service1.site2.domain.tld, service2.site2.domain.tld etc…