REDHAT-BUG-2521775: Medium severity NSS JSS (Java Security Services) vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Modify or configure JSSTrustManager so that getAcceptedIssuers() only returns CA certificates from the NSS database that carry the NSS TRUSTED_CA trust flags; do not build the accepted-issuer set solely on basicConstraints CA=TRUE, and ensure checkSignature() is evaluated against this filtered, trust-flag-approved set.
JSSTrustManager (JSS/Java Security Services) getAcceptedIssuers()/accepted issuers selection using NSS trust flags = Filter accepted issuer certificates by NSS trust flags (e.g., only include certificates marked as TRUSTED_CA) rather than CA=TRUE basicConstraints alone - Configuration
Ensure native revocation verification check certChainRevokeVerify is enabled so NSS's native verification properly validates trust flags and catches scenarios where revocation checking is disabled and an attacker could forge certificates accepted by JSSTrustManager.
NSS native revocation verification (certChainRevokeVerify) certChainRevokeVerify = enabled - Compensating control
If revocation checking must be disabled, add compensating network controls (e.g., restrict outbound TLS/PKI client connections with firewall/egress filtering and/or use a network TLS interception policy that prevents man-in-the-middle on outbound PKI connections).
Event History
Frequently Asked Questions
Are default JSS TLS configurations affected?
Default configurations are protected by the native revocation verification check, certChainRevokeVerify. NSS native verification validates trust flags and catches certificates that are not trusted CA anchors.
What conditions are required for exploitation?
Revocation checking must be disabled, and an attacker must control the private key for a CA certificate in the NSS database that has VALID_CA flags but lacks TRUSTED_CA trust flags. The attacker could then forge certificates accepted for outbound PKI client TLS connections.
What can be done if patching is not immediately possible?
Keep native revocation verification enabled, including certChainRevokeVerify. Also review NSS database CA certificates and avoid retaining under-trusted CA certificates whose private keys may be exposed or controlled by untrusted parties.
How can I identify potentially affected certificate entries?
Check the NSS database for certificates with basicConstraints CA=TRUE that have VALID_CA trust flags but do not have TRUSTED_CA flags. These certificates can be included in the accepted issuer set by JSSTrustManager even though they are not intended as trusted TLS anchors.