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.
\nThe OPNsense Stunnel guide 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.
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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nPrepare 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.
\nAgree 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.
\nGive 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.
\nProposed 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.
\nAfter 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe OPNsense Stunnel guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich tunnel and issuing CA are in scope, and who maintains its revocation list?\nAre certificates managed locally or through an external issuing process?\nWhat current evidence identifies the list used by the selected tunnel?\nWho may restart the service, and what interruption can the application owner accept?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nPrepare 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.\nAgree 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.\nGive 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.\nVerification and evidence\nProposed 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.\nAfter 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.\nOfficial references\n\nOPNsense — Stunnel — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which tunnel and issuing CA are in scope, and who maintains its revocation list?\n\n- Are certificates managed locally or through an external issuing process?\n\n- What current evidence identifies the list used by the selected tunnel?\n\n- Who may restart the service, and what interruption can the application owner accept?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nPrepare 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.\n\nAgree 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.\n\nGive 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.\n\n## Verification and evidence\n\nProposed 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.\n\nAfter 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.\n\n## Official references\n\n- [OPNsense — Stunnel](https://docs.opnsense.org/manual/how-tos/stunnel.html) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/", "url": "https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Check the OPNsense Stunnel CRL before enabling revocation checks", "item": "https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/#article", "identifier": "https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/", "url": "https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/", "headline": "Check the OPNsense Stunnel CRL before enabling revocation checks", "description": "OPNsense documents denial of all Stunnel connections when CRL checking is enabled without a valid CRL.", "abstract": "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.", "articleBody": "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.\nSource fact: what the authority says\nThe OPNsense Stunnel guide 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich tunnel and issuing CA are in scope, and who maintains its revocation list?\nAre certificates managed locally or through an external issuing process?\nWhat current evidence identifies the list used by the selected tunnel?\nWho may restart the service, and what interruption can the application owner accept?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nPrepare 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.\nAgree 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.\nGive 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.\nVerification and evidence\nProposed 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.\nAfter 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.\nOfficial references\n\nOPNsense — Stunnel — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T19:49:46+00:00", "dateModified": "2026-10-29T19:50:08+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/check-the-opnsense-stunnel-crl-before-enabling-revocation-checks/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Check the OPNsense Stunnel CRL before enabling revocation checks" }, "articleSection": [ "Cybersecurity", "Networks & Infrastructure" ], "keywords": [ "Cybersecurity", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 521, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OPNsense — Stunnel", "url": "https://docs.opnsense.org/manual/how-tos/stunnel.html" } } ] } }