Sophos Firewall: v21.0 EAP1: Feedback and experiences (EAP Thread)

Some thoughts about Lets Encrypt from my end: 
Release Notes: 
Let’s Encrypt Certificate Support – A long-requested feature, Let's Encrypt certificate support enables the automatic deployment and renewal of certificates based on certificate signing requests (CSRs). Let’s Encrypt certificates are supported for WAF, SMTP, TLS configuration, hotspot sign-in, the Web Admin console, user portal, captive portal, VPN portal, and SPX portal.

SFOSv21.0 LE is very similar to the implementation from UTM9. 
You can start a new LE certificate for a domain, for example: test.domain.com. You need to be the owner of this domain and add a DNS record for this FQDN. test.domain.com needs to point to the firewall (WAN). The firewall will try to request the certificate for test.domain.com and LE will reach out to the configured DNS. If this worked, you will get a valid certificate, you can use everywhere. The firewall will automatically refresh the certificate, if needed and there is no user interaction required. 

For this concept, you do not need a subscription - Base Firewall is fine. 

You cannot generate a wildcard certificate (*.domain.com) - This concept needs an DNS API renewal. SFOS (like UTM) supports only HTTP based renewal - Which limits to one domain per request. You can generate multiple FQDNs per firewall, if needed. 

You cannot download the certificate and reuse it somewhere else. For this concept, you should review a own method like certbot or lego. 

You find more information to debug LE here:  Let´s Encrypt Deep Dive & Debugging in SFOSv21.0  

Some thoughts about Lets Encrypt from my end: 
Release Notes: 
Let’s Encrypt Certificate Support – A long-requested feature, Let's Encrypt certificate support enables the automatic deployment and renewal of certificates based on certificate signing requests (CSRs). Let’s Encrypt certificates are supported for WAF, SMTP, TLS configuration, hotspot sign-in, the Web Admin console, user portal, captive portal, VPN portal, and SPX portal.

SFOSv21.0 LE is very similar to the implementation from UTM9. 
You can start a new LE certificate for a domain, for example: test.domain.com. You need to be the owner of this domain and add a DNS record for this FQDN. test.domain.com needs to point to the firewall (WAN). The firewall will try to request the certificate for test.domain.com and LE will reach out to the configured DNS. If this worked, you will get a valid certificate, you can use everywhere. The firewall will automatically refresh the certificate, if needed and there is no user interaction required. 

For this concept, you do not need a subscription - Base Firewall is fine. 

You cannot generate a wildcard certificate (*.domain.com) - This concept needs an DNS API renewal. SFOS (like UTM) supports only HTTP based renewal - Which limits to one domain per request. You can generate multiple FQDNs per firewall, if needed. 

You cannot download the certificate and reuse it somewhere else. For this concept, you should review a own method like certbot or lego. 

You find more information to debug LE here:  Let´s Encrypt Deep Dive & Debugging in SFOSv21.0  

Hi LucCar Toni,

great that this important function is finally coming to SFOS thanks.

But what surprises me is if this also works for VPN, i.e. for OpenVPN. How should this work with the client certs in config?
The current situation is that you always have to distribute the config to the clients when swapping the global cert for SSL/OpenVPN.
How should this work then?

I had hoped that this would work automatically, because I already swap the cert.

But even if a client connects via Sophos Connect before expiration,
the cert remains old and the connection is no longer possible via VPN from the day the old one expires.

Best Regards
Jacobi

Essentially i do not see a point in using LE for VPN at any chance. OpenVPN uses LE only for the management component and rely on own (self generated) CAs like SFOS does.

The benefit of LE for VPN compared to a self/gen CAs is not given due the fact of trust relationship. You can use LE for the VPN Portal to get the self-gen ovpn file. 

Same for UTM - there was never a reason to switch to LE and deal with the Auto regen problems. 

BTW: You would have to do it for every user all the time, means an additional load of tasks for no benefit. 

If you use profile based vpn config, your clients have the update policy option where they can refresh the vpn config, saves a lot of time and effort.

Hi LuCar Toni , Let's Encrypt worked for me after a view try's. I can use it for anything except for ssl vpn, is that correct. I can only select appliance cert or any other cert but not the Lets Encrypt one.

As SSL-VPN CA will sign User-VPN Certs you probably don’t want to use Let’s Encrypt there. Or every user would need to re-download profile at least every three months.

so I guess that’s correct ;)

I'm excited about LE, though I'm trying to think through my potential use case: I'd like to use the LE certificate for all internal (three VLANs, remote access VPN, etc) captive portals. (I'm pretty sure I'm using the correct portal: the one that web clients are directed to when a URL is rejected.) I'm thinking that this LE cert will be accepted by an browser -- including guests -- unlike the current locally-signed cert I'm using, which has to be installed and trusted on every client.

Seems like I'd need to set it to use the domain name (rather than an IP) and then have a loopback NAT rule to one particular internal interface's IP? I'm a little nervous about this in that I fear I'll end up killing my console access as well.

(Potential complication: I'm using DDNS. The good news is that with IPv4 my ISP has served up the same public IP for years now, so it's essentially fixed.)

Am I thinking in the right direction here? There will be no public access to the domain except the SSL VPN, so I'm not talking website, email, etc usage.