Skip to main content
RunBook Academy

← All break/fix scenarios in OPNsense

intermediatecertificate-expiry~25 min

Break/Fix: VPN Service Down Because Certificate Expired

Reported symptoms

  • ●VPN service refuses to start after a clean reboot
  • ●charon.log or openvpn.log reports expired certificate errors
  • ●Web UI shows a TLS warning or refuses to load

Evidence

  • · charon.log: "received fatal alert certificate expired" or "no private key found"
  • · openssl x509 -in /var/etc/ipsec/certs/<cert>.crt -noout -dates shows notAfter in the past
  • · System → Trust → Certificates shows the cert as expired
Diagnosis and resolutionclick to reveal

Root cause

The certificate used by the VPN service has reached its notAfter date and strongSwan/OpenVPN refuses to use it. The cert was either a short-lived Let's Encrypt cert, an internal CA cert that nobody renewed, or a default self-signed cert that aged out.

Remediation

1. Identify the expired certificate in System → Trust → Certificates. 2. Renew or reissue the certificate from your CA (internal ACME, internal CA, or external CA). 3. Replace the cert in the VPN service configuration and reload. 4. For OpenVPN: re-export the client config and redistribute to clients. 5. For IPsec: swanctl --load-all and re-initiate the SA.

Verification

VPN service starts cleanly; tunnel establishes; clients can authenticate; openssl reports notAfter in the future.

Prevention

Track notAfter dates in your observability stack — alert at 30, 7, and 1 day thresholds for every cert that protects a service. Renew well before expiry. Use ACME where possible. For internal CAs, automate renewal or schedule a calendar reminder far in advance.

Scenario

You are operating an OPNsense edge with a VPN service that has just stopped working. The following symptoms appear:

  • VPN service refuses to start after a clean reboot
  • charon.log or openvpn.log reports expired certificate errors
  • Web UI shows a TLS warning or refuses to load

Available evidence:

  • charon.log: “received fatal alert certificate expired” or “no private key found”
  • openssl x509 -in /var/etc/ipsec/certs/<cert>.crt -noout -dates shows notAfter in the past
  • System → Trust → Certificates shows the cert as expired

Your task

Determine the cause, recover, document, and validate.

Investigation

The investigation follows the discipline taught in Part XXIV:

  1. Form hypothesis, find evidence, test, validate.
  2. Use the available evidence above to bound the search.
  3. Reach one of the likely root causes.

Recovery procedure

(Do not reveal until you have reasoned through the problem.)

  1. Identify the failing component.
  2. Apply the remediation pathway.
  3. Validate with the verification step.
  4. Document the incident.

Remediation

  1. Identify the expired certificate in System → Trust → Certificates. 2. Renew or reissue the certificate from your CA (internal ACME, internal CA, or external CA). 3. Replace the cert in the VPN service configuration and reload. 4. For OpenVPN: re-export the client config and redistribute to clients. 5. For IPsec: swanctl --load-all and re-initiate the SA.

Verification

VPN service starts cleanly; tunnel establishes; clients can authenticate; openssl reports notAfter in the future.

Rollback

Re-enable the previous (now-expired) cert if needed; expect the service to fail again.

Prevention

Track notAfter dates in your observability stack — alert at 30, 7, and 1 day thresholds for every cert that protects a service. Renew well before expiry. Use ACME where possible. For internal CAs, automate renewal or schedule a calendar reminder far in advance.