# Separate OPNsense certificate chain import from intermediate trust deployment > OPNsense distinguishes manually including intermediates in an imported certificate from deploying intermediate CAs to the shared trust store. Review application context before changing a global trust option. - Canonical URL: https://update.dsesecurity.com/updates/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-29T19:49:39+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 distinguishes manually including intermediates in an imported certificate from deploying intermediate CAs to the shared trust store. Review application context before changing a global trust option. ## Potentially affected OPNsense certificate imports and default OpenSSL trust-store configuration in the official Trust reference. ## DSE recommendation Inspect the imported chain and the consuming application before altering shared intermediate-CA trust deployment. ## Article Bottom line: Identify whether the problem concerns a presented certificate chain or shared trust configuration. Ask which application consumes the trust setting before changing a global option to repair one validation error. ## Source fact: what the authority says The [OPNsense Trust reference](https://docs.opnsense.org/manual/certificates.html) says Store intermediate defaults to disabled, so intermediate certificates are not deployed to the trust store by default. It instructs administrators importing a certificate manually to include its intermediate certificates to avoid validation issues with the web GUI. The reference describes configuration constraints for the default OpenSSL context and warns that applications are not forced to use a standard context, so custom constraints may have no effect. The reference distinguishes client, server, combined and certificate-authority certificate types, warning that incorrect selection can cause client errors. ## What the source does not establish This article concerns the reference’s chain-import and shared-trust distinction. It does not establish the trust behavior of every application, approve a new issuing authority or treat a successful GUI connection as proof that all service clients validate the same chain. ## Applicability questions - Which exact endpoint and client report the validation problem? - What issuer and intermediate chain are actually presented? - Was the certificate imported with the required chain and intended type? - Does the consuming application use the default OpenSSL context or its own configuration? ## DSE recommendation: controlled next steps The following steps are DSE recommendations based on the cited source. DSE recommends a certificate map containing the endpoint, public issuer references, expected chain and consuming clients. Compare the imported material with the intended chain before changing Store intermediate. Keep private keys outside the investigation record and verify public certificate provenance through the organization’s established PKI process. For a proposed manually imported GUI certificate, review the leaf and intermediate material as one controlled import package. Ask a second administrator to compare certificate types and public fingerprints with the approved issuer record. Resolve an incomplete or incorrect package before broadening shared trust. If a shared-trust change is proposed, identify the applications expected to consume it and their actual configuration contexts. Record any custom trust configuration as a separate branch. Avoid promising that a global option repairs an application that has not been inspected. Preserve the initial certificate and trust configuration under the appropriate access controls. Use an attended maintenance window and a recovery route independent of the GUI connection being changed. Assign a removal owner to any newly approved trust material. ## Verification and evidence Proposed verification: connect from the actual approved client to the named endpoint without bypassing certificate validation. Inspect the presented chain and compare it with the intended issuer references. Record a GUI result and each separately reviewed application result independently. In a controlled test environment, include an unapproved-chain case where the PKI owner has defined the expected rejection. Preserve sanitized client errors and effective trust settings. Leave an untested custom-context application unresolved rather than extrapolating the GUI result to the whole firewall. ## Official references - [OPNsense — Trust](https://docs.opnsense.org/manual/certificates.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 — Trust - Authority: docs.opnsense.org - URL: https://docs.opnsense.org/manual/certificates.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Separate OPNsense certificate chain import from intermediate trust deployment,” DSE Security, https://update.dsesecurity.com/updates/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/ 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.