Both pfSense and OPNsense manage certificates for their own web-based management interface (the "webConfigurator" in pfSense terms) through a dedicated certificate manager, separate from any certificates you might issue for services behind the firewall.
pfSense
- Go to System → Cert Manager → Certificates, and choose Import to bring in an existing CA-signed certificate and its private key (and intermediate, if applicable).
- Go to System → Advanced → Admin Access, and under the SSL/TLS certificate setting, select the certificate you just imported.
- Save — the web interface (lighttpd, internally) restarts to apply the new certificate, which will briefly interrupt your active session.
OPNsense
The equivalent screens are System → Trust → Certificates for importing the certificate, and System → Settings → Administration for selecting which certificate the web GUI (TLS certificate setting) should use. The underlying concept is identical to pfSense; only the menu labels differ between the two forks.
Automating issuance with the ACME package
Both platforms offer an ACME client package (available through their respective package managers) that can request and automatically renew a Let's Encrypt certificate directly on the firewall, and — depending on how you configure the package's automation actions — bind the renewed certificate to the web GUI automatically going forward. This avoids the need to manually re-import a certificate by hand every renewal cycle, which is easy to let lapse on an appliance you don't touch often. Because DNS-01 or HTTP-01 validation both require the firewall to either answer on port 80 or have API access to your DNS provider, plan the validation method around what's actually reachable from this specific box.
Why to keep console or SSH access available before changing this
The certificate you're changing here secures the same web interface you're using to make the change. An incorrectly matched certificate and private key, or a certificate the browser won't accept for an unrelated reason, can leave you unable to reach the web GUI at all afterward. Before making this change on a firewall you can't easily walk up to, confirm you have console access (physical, or serial/IPMI) or SSH access as a fallback — both platforms also expose certificate and admin-access settings through their console menu and shell configuration, which is the recovery path if the web GUI itself becomes unreachable.
Certificates for services behind the firewall vs. the GUI itself
None of the above affects certificates for other services running behind or on the same box (a captive portal, a VPN endpoint, or another self-hosted service using the firewall's built-in certificate manager as a convenient local CA) — each service that uses a certificate typically has its own separate certificate-selection setting, independent of whichever certificate secures the administrative web GUI.
Loading comments…