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.
\nThe OPNsense Trust reference 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.
\nThis 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.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE 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.
\nFor 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.
\nIf 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.
\nPreserve 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.
\nProposed 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.
\nIn 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.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: what the authority says\nThe OPNsense Trust reference 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact endpoint and client report the validation problem?\nWhat issuer and intermediate chain are actually presented?\nWas the certificate imported with the required chain and intended type?\nDoes the consuming application use the default OpenSSL context or its own configuration?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nFor 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.\nIf 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.\nPreserve 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.\nVerification and evidence\nProposed 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.\nIn 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.\nOfficial references\n\nOPNsense — Trust — 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: 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.\n\n## Source fact: what the authority says\n\nThe [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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which exact endpoint and client report the validation problem?\n\n- What issuer and intermediate chain are actually presented?\n\n- Was the certificate imported with the required chain and intended type?\n\n- Does the consuming application use the default OpenSSL context or its own configuration?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE 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.\n\nFor 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.\n\nIf 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.\n\nPreserve 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.\n\n## Verification and evidence\n\nProposed 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.\n\nIn 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.\n\n## Official references\n\n- [OPNsense — Trust](https://docs.opnsense.org/manual/certificates.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/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/", "url": "https://update.dsesecurity.com/updates/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/#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": "Separate OPNsense certificate chain import from intermediate trust deployment", "item": "https://update.dsesecurity.com/updates/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/#article", "identifier": "https://update.dsesecurity.com/updates/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/", "url": "https://update.dsesecurity.com/updates/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/", "headline": "Separate OPNsense certificate chain import from intermediate trust deployment", "description": "OPNsense distinguishes manually including intermediates in an imported certificate from deploying intermediate CAs to the shared trust store.", "abstract": "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.", "articleBody": "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.\nSource fact: what the authority says\nThe OPNsense Trust reference 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact endpoint and client report the validation problem?\nWhat issuer and intermediate chain are actually presented?\nWas the certificate imported with the required chain and intended type?\nDoes the consuming application use the default OpenSSL context or its own configuration?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE 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.\nFor 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.\nIf 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.\nPreserve 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.\nVerification and evidence\nProposed 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.\nIn 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.\nOfficial references\n\nOPNsense — Trust — 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:39+00:00", "dateModified": "2026-10-29T19:50:08+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/" }, "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/separate-opnsense-certificate-chain-import-from-intermediate-trust-deployment/#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": "Separate OPNsense certificate chain import from intermediate trust deployment" }, "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": 515, "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 — Trust", "url": "https://docs.opnsense.org/manual/certificates.html" } } ] } }