CVE-2026-78323: Jss: jss: jsstrustmanager does not verify nss trust flags on ca certificates
A flaw was found in JSS (Java Security Services). The JSSTrustManager class does not verify NSS trust flags when validating CA certificates, allowing certificates present in the NSS database without TRUSTEDCA flags to be accepted as trust anchors for TLS connections. In non-default configurations where certificate revocation checking is disabled, this could allow a man-in-the-middle attacker to forge certificates accepted by PKI client connections.
Other sources
A flaw was found in JSS (Java Security Services). The JSSTrustManager class, which implements javax.net.ssl.X509TrustManager for JSS-based TLS connections, does not filter CA certificates by NSS trust flags when building its set of accepted issuers. The getAcceptedIssuers() method returns all certificates with basicConstraints CA=TRUE from the NSS database regardless of whether they carry TRUSTEDCA trust flags, and checkSignature() performs only cryptographic signature validation against this unfiltered set. This means a certificate present in the NSS database with only VALIDCA flags (as set by routine operations such as certificate enrollment via CERTImportCAChainTrusted) could be treated as a trust anchor for TLS connections. In default configurations, the native revocation verification check (certChainRevokeVerify) catches this condition because NSS's native verification properly validates trust flags. However, if revocation checking is disabled, an attacker controlling the private key of an under-trusted CA could forge certificates accepted by JSSTrustManager, enabling man-in-the-middle attacks on outbound PKI client connections.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure native revocation verification is enabled (certChainRevokeVerify) so that revocation checking is not disabled; otherwise a MITM attacker with control of an under-trusted CA private key could forge certificates accepted by JSSTrustManager.
JSS (Java Security Services) / JSSTrustManager certChainRevokeVerify (native revocation verification check) = enabled - Configuration
Update/adjust JSSTrustManager behavior so it verifies NSS trust flags on CA certificates (filter CA certificates by NSS trust flags, requiring TRUSTED_CA), rather than accepting CA certificates from the NSS database based only on basicConstraints CA=TRUE.
JSS (Java Security Services) / JSSTrustManager NSS CA trust flags verification in JSSTrustManager = enabled
Event History
Frequently Asked Questions
Which deployments are exposed to practical exploitation?
The issue is practically exploitable in non-default configurations where certificate revocation checking is disabled. TLS PKI client connections using JSSTrustManager may then accept CA certificates in the NSS database even when they lack TRUSTED_CA flags.
What does an attacker need to exploit this issue?
An attacker would need to perform a man-in-the-middle attack and forge a certificate that is accepted through an NSS database CA certificate lacking the TRUSTED_CA flags. No privileges or user interaction are required according to the supplied vector.
Is the default configuration affected?
The described attack condition requires certificate revocation checking to be disabled, which is identified as a non-default configuration. The provided information does not establish practical exploitation under the default configuration.
What can be done if patching cannot be performed immediately?
Ensure certificate revocation checking remains enabled. This removes the non-default condition identified as enabling the described man-in-the-middle scenario.