How to Install an SSL Certificate on pfSense and OPNsense

Why an install here is three objects, not one file

On a web server, installing a certificate means putting files somewhere and telling one process to read them. A firewall works differently. pfSense and OPNsense both hold certificates in a configuration database, as objects with identities, and several independent services each store the identity of the object they use. Three things to get right, then, and only the middle one is what most guides call "installing".

The consequence shows up as the most common report we see from people who have just bought a certificate for a management interface: the certificate imported cleanly, the entry is visible in the list with the right dates and the right hostname, and the browser still shows the old one. Nothing failed. The import created a new object and left every existing reference pointing where it already pointed.

There is a second consequence, quieter and more annoying to diagnose. Because the chain the firewall presents is assembled from the CA entries it holds rather than from whatever file your certificate arrived in, a bundle that contains an intermediate does you no good until that intermediate exists as its own object. Both problems have the same root: on this platform, a certificate is a record in a database, and everything that uses it holds a pointer.

Generate the request on the firewall, or import a key

Decide this before you order, because it changes what you paste later. If the certificate will only ever be used by this firewall, generate the signing request on the firewall itself: the private key is created on the box, never leaves it, and the finished entry is guaranteed to have a usable key. Import an existing certificate and key only when the certificate genuinely has to be shared with another system.

For the first path, open System > Cert. Manager, go to the Certificates tab, add an entry and choose Create a Certificate Signing Request. Fill in the common name as the hostname staff will actually type, add any additional names under the alternative-name fields, and keep the key at RSA 2048 or higher unless you have a specific reason to use an elliptic-curve key. The firewall gives you a CSR block to hand to the certificate authority.

What you order against that request is a normal server certificate — there is no firewall-specific product. A domain-validated certificate is enough when the name is validated over DNS and nobody needs to see an organisation name in the certificate details; an OV certificate is the usual choice when an internal policy requires the company to be identified in the certificate itself. Either way you need a real, publicly resolvable hostname, because no public CA may issue for a private IP address or an internal-only name.

For the second path, the one condition that catches people is the key format. The import expects an unencrypted PEM private key. A key with a passphrase, or a .pfx container exported from Windows, has to be converted first — the conversion is a single OpenSSL command, and our guide to certificate formats covers which one you need. Import the certificate without a key and the entry will exist, but it will not appear in any service menu, which is a confusing way to discover the problem.

Importing the CA, and the chain it decides

Do this before you import the leaf. Open System > Cert. Manager, go to the CAs tab, add an entry and choose Import an existing Certificate Authority. Paste one intermediate, give it a name you will recognise in a dropdown a year from now, and save. If your bundle contains more than one intermediate, repeat this for each one as a separate entry. Leave the private key field empty — you are not importing a CA you control.

This is the step that decides what clients actually receive. The firewall builds the chain it presents from the CA entries it holds, so an intermediate that exists only inside the archive the certificate authority sent you is never transmitted. The certificate itself is perfectly valid. The chain is simply incomplete, and each client is left to find the missing issuer on its own.

The reason this survives testing is that desktop browsers are forgiving about it. Chrome and Edge cache intermediates they have seen on other sites and will often complete the chain without being sent it, and some clients will fetch a missing issuer over the network. The clients that will not are the ones that generate the support ticket: phones, older devices, curl, a monitoring agent, anything running in a container with a bare trust store. If the person who installed the certificate tested from their own laptop, they saw a padlock and moved on.

You do not need to import the root. Roots are already present in client trust stores, and sending one adds a certificate to every handshake for no benefit. Intermediates only.

Importing the certificate and its key

With the CAs in place, go to the Certificates tab, add an entry, and choose Import an existing Certificate. Paste the leaf certificate into the certificate field and the matching private key into the key field, both including their-----BEGIN----- and -----END----- lines. If you generated the request on the firewall instead, there is no import to do: find the pending request in the same list and complete it by pasting the issued certificate into it.

Name the entry after the certificate, not after whichever service happens to use it today. fw.example.com 2026-09 beats webgui cert. Every service menu on the box shows these names in a dropdown, you will have two entries for the same hostname during every overlap, and a name that encodes the issue date is the difference between a confident selection and a guess. This costs nothing now and saves a genuine mistake later.

Pointing the web interface at it

Go to System > Advanced > Admin Access. Set the protocol to HTTPS if it is not already, then pick your new entry in the SSL/TLS Certificate dropdown and save. Saving restarts the webConfigurator, so the session drops for a moment and comes back on the new certificate. That restart is the part people skip when they change the setting and then navigate away without saving.

If your certificate is not in that dropdown, the list is telling you something specific: it only offers certificates the firewall holds a usable private key for. An entry imported without a key, or with a passphrase-protected key, is filtered out. Go back to the Certificates tab, check whether the entry shows a private key, and re-import with the key in unencrypted PEM form if it does not.

One habit worth adopting while you are on this page: keep a second way into the box. A mistake here — a certificate that does not match the key, a hostname nobody resolves — locks you out of the interface you would use to fix it. Console access, or SSH left enabled during the change, turns a bad afternoon into a two-minute correction.

The services that hold their own reference

The web interface is one consumer among several, and changing it changes nothing for the others. Each service stores the identity of one certificate entry and keeps using it. Walk the list every time you replace a certificate, because the one you forget is the one that expires in public: OpenVPN servers, IPsec, the Captive Portal, and any package such as HAProxy that selects certificates per frontend.

OpenVPN deserves a note of its own, because it behaves better than people fear. Clients verify the server against the CA in their profile, not against one specific server certificate, so replacing the server certificate with another from the same issuer is invisible to them. What is not invisible is a change of certificate authority: the CA in every exported profile is now the wrong one, and each client refuses the connection until the profile is replaced. Treat a CA change as a client-side rollout, which is the same reasoning behind the overlap period in our guide to switching certificate authorities without downtime.

HAProxy is the one that most often keeps serving an expired certificate after everything else has moved. It runs as a package with its own configuration, its own certificate selection per frontend, and its own restart, and none of that is touched by the Admin Access page. If your firewall publishes anything to the internet, HAProxy is probably the service your users actually reach, which makes it the last place you want to find out that a replacement was incomplete.

Leave the old certificate entry in place until you have confirmed every consumer. Deleting an entry that something still references does not warn you at the time; it surfaces later as a service that will not start, or an interface quietly back on a self-signed certificate.

The same job on OPNsense

OPNsense uses the same three-object model with different menu names. Certificates and authorities live under System > Trust, split across the Authorities and Certificates pages, and the web interface certificate is chosen under System > Settings > Administration. Import each intermediate as an authority first, exactly as on pfSense, then the leaf with its key.

The practical difference is what happens after issuance. OPNsense keeps a trust store that other services read from, and its ACME client plugin writes renewed certificates into that store, so a renewal reaches the services that reference it more cleanly than the equivalent flow on pfSense. That is a convenience rather than a substitute for checking: a service still has to be restarted to present a certificate it has just been handed.

Everything else in this guide transfers unchanged. The chain is still built from imported authorities, a key still has to be unencrypted PEM to be usable, and every service that presents TLS still holds its own reference.

Automating it with the ACME package

pfSense ships an ACME package that requests, renews and installs certificates on a schedule. Install it from System > Package Manager, register an account key against your certificate authority's ACME directory, then define a certificate with the names you want and a validation method. On OPNsense the equivalent is the ACME client plugin, configured the same way.

Choose DNS validation rather than HTTP validation on a firewall. HTTP validation needs port 80 reachable from the internet on the device whose entire job is to not have unnecessary ports open, and it cannot issue for a name that only resolves internally. DNS validation asks your DNS provider's API to publish a record instead, which works for an internal-only management name and for a wildcard, and leaves nothing listening on the WAN.

The step that determines whether any of this works unattended is the actions list on each certificate. A renewal that writes a new certificate into the store and restarts nothing leaves you exactly where the manual process does: a valid new certificate that no service is presenting. Add the restart your services need — restarting the webConfigurator for the management interface, and whatever each other consumer requires — and confirm the package's scheduled job is enabled, because that job is what runs those actions.

The package is not limited to free certificates. Any certificate authority that exposes an ACME endpoint can be used, and a commercial account is tied to your orders through External Account Binding credentials — a key identifier and an HMAC key issued with your account. What ACME cannot automate is the organisation check in front of an OV certificate, which is a human process the first time and on each revalidation.

What 200, then 100, then 47 days changes

As of September 2026 a publicly trusted TLS certificate may be valid for at most 200 days, so a firewall needs a new one about twice a year. Under the CA/Browser Forum schedule in Ballot SC-081v3 that cap falls to 100 days on March 15, 2027 and to 47 days on March 15, 2029, taking the same replacement to roughly four and then eight times a year.

The arithmetic matters more here than on a web server, because a firewall gets touched on purpose, inside a change window, and barely at all in between. A change that lands in someone's calendar once a year gets done. The same change four times a year, on a box nobody logs into between incidents, is the kind of task that slips — and when it slips on a management interface, the first symptom is usually an administrator training themselves to click past a warning.

There is a detail in the ACME package worth revisiting each time the cap drops. Its renewal threshold is expressed as a number of remaining days, not as a proportion of the lifetime. A threshold that leaves a comfortable margin on a 200-day certificate can sit awkwardly close to, or beyond, the whole lifetime of a shorter one. Read the value your configuration actually uses; whatever it is, it was chosen for longer certificates than the ones you are about to be issued. Leave yourself enough runway to notice a failed renewal before the certificate expires. The same reasoning, applied across a whole estate, is the subject of our guide to preparing for 47-day certificates.

Proving the change actually reached a client

Check from somewhere that is not the firewall, and check the chain rather than the padlock. One command answers both questions at once: openssl s_client -connect fw.example.com:443 -servername fw.example.com -showcerts. Read the certificate list it prints. You want the leaf followed by the intermediate, and a verify return code of 0.

A leaf on its own, with no intermediate beneath it, means the CA entry never got imported — that is the missing-chain problem, seen from the client side. An unexpected issuer or an old expiry date means a service is still holding a reference you have not moved yet. Repeat the command against every port that presents TLS, not just 443, because each one answers for a different service.

For a name that resolves publicly, our SSL certificate checker does the same inspection from outside your network and reports the chain it was served, which is a useful second opinion when the answer from inside your own network looks fine. For an internal-only name, the OpenSSL command is the practical equivalent — run it from a workstation, not from a shell on the firewall.

That last row is the one that separates a working setup from one that appears to work. Force a renewal on the day you configure it, while you still remember which services you re-pointed and which restart each one needs. Discovering a missing action six months later, from an expiry warning, means diagnosing a system you have entirely stopped thinking about.

FAQ