# Check the OPNsense Stunnel CRL before enabling revocation checks

> OPNsense documents denial of all Stunnel connections when CRL checking is enabled without a valid CRL. Review list availability and the consuming tunnel before the change.

- Canonical URL: https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-29T19:49:46+00:00
- Modified: 2026-10-29T19:50:08+00:00
- Last reviewed by DSE: 2026-10-29
- Resource type: Guide
- DSE priority: Advisory
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 3 minutes

## What you need to know

OPNsense documents denial of all Stunnel connections when CRL checking is enabled without a valid CRL. Review list availability and the consuming tunnel before the change.

## Potentially affected

OPNsense Stunnel plugin deployments using certificate authentication and the documented CRL option.

## DSE recommendation

Verify the selected CA, valid CRL and controlled authentication cases before enabling revocation checking.

## Article

Bottom line: Make CRL availability a release condition for the tunnel. Keep a missing revocation list separate from a deliberately revoked client certificate, and agree the recovery action before enabling the option.

## Source fact: what the authority says

The [OPNsense Stunnel guide](https://docs.opnsense.org/manual/how-tos/stunnel.html) says the plugin supports certificate-based authentication only, although the underlying application also supports pre-shared keys. Its CA selection accepts connections using a certificate issued by that CA. Enabling CRL checking requires a list named in the documented XXXXXXXX.r0 format in /var/run/stunnel/certs/; attached CRLs are generated automatically for certificates managed on that machine. The guide warns that all connections are denied when the option is configured without a valid CRL, and additions may require restarting Stunnel when the certificate was already used.

## What the source does not establish

This article covers the plugin’s documented certificate and CRL dependency, not a universal certificate-offboarding procedure. It does not establish the behavior of an already connected client, a particular PKI refresh schedule or another TLS service.

## Applicability questions

- Which tunnel and issuing CA are in scope, and who maintains its revocation list?

- Are certificates managed locally or through an external issuing process?

- What current evidence identifies the list used by the selected tunnel?

- Who may restart the service, and what interruption can the application owner accept?

## DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a tunnel-specific dependency record containing the CA identity, public certificate references, CRL location and responsible PKI owner. Keep private keys out of that record. Resolve an absent or ambiguous list before treating the checkbox as a completed access-control change.

Prepare a proposed laboratory case with a valid client certificate, a deliberately revoked test certificate and a deliberately unavailable test CRL. Write the required result for each case before changing the service. Do not perform the unavailable-list case against an operational tunnel merely to demonstrate the warning.

Agree how the list is supplied and how its validity is checked during routine maintenance. Review the documented restart caveat with the application owner rather than assuming that importing a new list alone completes the change. Keep the previous configuration and an authorized management route available during the attended pilot.

Give renewal and revocation maintenance their own owner. Ask a second administrator to follow the public references and identify the actual consuming tunnel without relying on a friendly certificate name alone.

## Verification and evidence

Proposed verification: use the approved test certificates to attempt new connections and record the selected tunnel, CRL reference, time and observed decision. Keep valid, revoked and missing-list results in separate rows. Inspect service evidence for the actual authentication attempt rather than accepting a successful browser transaction as the entire explanation.

After the approved list update or restart, repeat the relevant new-connection checks. Preserve unsuccessful and unperformed cases as open findings. Accept only the observed service behavior and leave existing-session handling to a separately supported test plan.

## Official references

- [OPNsense — Stunnel](https://docs.opnsense.org/manual/how-tos/stunnel.html) — official product documentation; confirm the installed release and configuration.

Source review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.

## Primary reference

- Name: OPNsense — Stunnel
- Authority: docs.opnsense.org
- URL: https://docs.opnsense.org/manual/how-tos/stunnel.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Check the OPNsense Stunnel CRL before enabling revocation checks,” DSE Security, https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.