Running an internal CA on OPNsense · OPNsense

Most production estates run an internal certificate authority. Internal CAs issue certificates for services that do not (and should not) exist on the public Internet: the firewall GUI, internal web apps, internal APIs, IPsec peers, syslog targets, monitoring endpoints. OPNsense ships a certificate authority manager that can act as a self-signed internal CA or as an intermediate signed by a parent CA.

This lesson covers how to operate an internal CA on OPNsense: the root vs intermediate decision, the certificate authority manager, certificate issuance for OPNsense services, the distribution of the trust anchor, and the discipline that keeps an internal CA from becoming a single point of failure.

The internal CA decision

There are two production shapes for an internal CA.

Self-signed root. OPNsense is the CA. The CA certificate is self-signed, the CA private key is generated and stored on the firewall. OPNsense issues certificates for internal services. Every verifier that needs to trust these certificates has the OPNsense CA certificate in its trust store.

Intermediate signed by a parent CA. OPNsense is not the root. A parent CA (an offline root, a step-ca instance, AD CS, HashiCorp Vault PKI, or another internal PKI) issues a certificate for an OPNsense-managed intermediate. OPNsense uses the intermediate to issue certificates for internal services. Verifiers trust the root, which chains to the intermediate, which chains to the leaf.

The trade-off:

Property	Self-signed root	Intermediate
Setup complexity	Low	Higher (parent CA needed)
Blast radius of key compromise	Whole estate	Limited to intermediate
Operational separation	None — OPNsense is the root	Yes — root can be offline
Suitability for HA	Awkward — root lives on one node	Better — intermediate can be replicated
Trust anchor distribution	One CA cert	One root cert (parent)

A small single-firewall estate may run a self-signed root. Anything that is meant to scale, or that needs HA, or that needs to issue certificates from a hardened offline root, should run an intermediate.

Creating the CA on OPNsense

The certificate authority manager lives under System → Trust → Authorities. To create a new CA:

Click Add.
Choose Create an internal Certificate Authority for a self-signed root, or Import an existing Certificate Authority for an intermediate.
Set the descriptive name (e.g. Example Internal Root CA).
Choose the key type and size. RSA 3072 or ECDSA P-256 are the modern production defaults. RSA 2048 is acceptable but weaker.
Set the Common Name of the CA certificate (e.g. Example Internal Root CA).
Set the Distinguished Name fields: Organisation, Country, etc. These go into the certificate subject.
Set the Lifetime in days. Roots commonly run 10 years; intermediates commonly run 5 years.
Click Save.

OPNsense generates the CA certificate and private key and stores them under System → Trust. The CA certificate can be exported from the CA list — this is the trust anchor that gets distributed to verifiers.

Read-only / SafeCA cert inspection— The certificate authority certificate's fingerprint is the value operators compare to confirm they have the right CA cert. After exporting the CA cert from OPNsense and distributing it, the operator should verify the fingerprint over an out-of-band channel (a phone call, a printed page, a second medium) before installing it as a trust anchor. A fingerprint that does not match is a man-in-the-middle.

$ openssl x509 -in /var/etc/cert-manager/ca/example-internal-root.crt -noout -subject -issuer -fingerprint -sha256

subject=O = Example Org, CN = Example Internal Root CA
issuer=O = Example Org, CN = Example Internal Root CA
sha256 Fingerprint=7B:5C:88:D4:9A:2F:1E:BB:34:C7:91:5D:8E:43:01:6A:2C:F8:90:5E:AB:11:CD:EF:12:34:56:78:9A:BC:DE:F0

Illustrative output

Where OPNsense stores the CA key

The CA private key is generated on the firewall and stored in the OPNsense configuration backend. The configuration backend writes the key, encrypted at rest with a key derived from the firewall’s configuration secret, to the config.xml on disk. Backups of config.xml include the CA key. Anyone with a config.xml backup who also has the configuration secret can recover the CA key.

This is why:

config.xml backups must be treated as sensitive. Encrypt them. Do not store them on the same host as the firewall.
The configuration secret must be strong and known only to the operators who need it.
A second, encrypted offline copy of the CA key, exported via the OPNsense UI, is recommended for a self-signed root CA. Store it on a hardware token or a sealed envelope in a safe.

Issuing certificates from the CA

Once the CA is created, certificates for internal services are issued under System → Trust → Certificates. The workflow:

Click Add.
Choose Create an internal Certificate.
Select the Certificate Authority that will sign it.
Set the key type, size and lifetime.
Set the Common Name to the service hostname (e.g. fw.example.com).
Add Subject Alternative Names — at minimum the primary hostname. Add internal hostnames and any aliases.
Click Save.

The certificate is signed by the chosen CA and stored. It can be exported or selected for use by OPNsense services (GUI, IPsec, OpenVPN, captive portal, etc.) under each service’s configuration.

Read-only / Safeopenssl issue leaf— A standard openssl CSR-to-cert flow. The CA signs the CSR, producing a leaf certificate. The SAN extension is added explicitly via -extfile, not the CN. The CA signs with SHA-256. Validity is 825 days (~27 months), the maximum allowed by browser policy for a leaf. The same flow under the OPNsense GUI is wrapped in a wizard.

$ openssl req -new -newkey rsa:2048 -nodes -keyout fw.example.com.key -subj "/CN=fw.example.com" -addext "subjectAltName=DNS:fw.example.com,DNS:fw.internal.example.com" | openssl x509 -req -CA /var/etc/cert-manager/ca/example-internal-root.crt -CAkey /var/etc/cert-manager/ca/example-internal-root.key -CAcreateserial -days 825 -sha256 -extfile <(printf "subjectAltName=DNS:fw.example.com,DNS:fw.internal.example.com\nextendedKeyUsage=serverAuth")

Signature ok
subject=CN = fw.example.com
Getting CA Private Key

Illustrative output

Distributing the trust anchor

The CA certificate must reach every verifier that needs to trust certificates signed by the CA. The distribution paths:

Operator workstations: deploy the CA cert via Group Policy (Windows), MDM (macOS), or a configuration profile. Manual install is acceptable for a small estate.
Linux servers: copy the CA cert to /usr/local/share/ca-certificates/ (Debian) or /etc/pki/ca-trust/source/anchors/ (RHEL) and run update-ca-certificates. Distribute via Ansible, Salt, or configuration management.
Applications with their own trust stores (Java, Python, curl with --cacert, some appliances): the CA cert must be added to those trust stores explicitly.
Mobile devices: install the CA cert as a profile. Note that some platforms (recent iOS, Android) require explicit user trust for non-public CAs even after install.

The trust anchor distribution is the part operators most often underestimate. A working CA that nobody trusts is operationally the same as no CA at all.

Operational discipline for an internal CA

An internal CA is a long-lived infrastructure component. The discipline that keeps it healthy:

Document the CA hierarchy. A one-page runbook that names the root, the intermediates, the issuing policies, the renewal cycle, and the offline storage location. Any operator who needs to recover the CA in an emergency can read the runbook and act.
Monitor expiry. Roots and intermediates expire. A forgotten root expiry is an estate-wide outage. The monitoring lesson in this part of the course covers this.
Restrict issuance. Certificates should only be issued for known services. A CA that issues certificates for arbitrary names at the request of any operator is an open certificate authority. The OPNsense CA manager does not enforce issuance policy beyond “the operator is logged in”. A wrapping process (change ticket, peer review) is the practical enforcement.
Audit issuance. The CA’s audit log (who issued what, when, for which name) must be retained and reviewed. An unexpected certificate for an unexpected name is a compromise indicator.
Plan revocation. When a certificate is compromised (private key leak, mis-issuance), the CA must be able to revoke it. CRL distribution points and OCSP responders must be configured. For an internal CA, even a manual CRL published on the firewall is acceptable.

Summary

An internal CA is necessary for any non-trivial production estate. OPNsense ships a built-in CA manager.
Run an intermediate signed by a parent CA when possible. A self-signed root on the firewall is a single point of failure.
Certificates for OPNsense services are issued under System → Trust → Certificates. Always set the SAN.
Distribute the CA certificate to every verifier that needs to trust issued certificates. Verify the fingerprint out-of-band before installing.
Document the hierarchy, monitor expiry, restrict issuance, audit, and plan for revocation.