Installing Bouncy Castle 1.85 or an Atlassian release that contains the fix should change a specific certificate-validation outcome. A test that only checks a normal certificate still validates can miss the vulnerability. The important regression case is a valid stapled OCSP response for a different certificate.

CVE-2026-58062 is present in affected Bouncy Castle for Java branches when the stapled OCSP path fails to require a CertID match. The fixed provider throws a recoverable path-validation exception after searching the response entries and finding no match. That exception can lead to CRL fallback or rejection, depending on the surrounding PKIX configuration.

Begin with the exact runtime under test

A test is only meaningful if it exercises the provider that production uses. Record the product release, Java runtime, Bouncy Castle package, provider name, provider order, and trust-store configuration. A patched Maven dependency does not prove that the application server loaded it.

For Atlassian platforms, use the product's supported diagnostic path to confirm the effective release. The October 20 bulletin maps fixed versions across Confluence, Crowd, Jira Software, and Jira Service Management. Some fixes are Data Center only or branch-specific. Confirm the installed build belongs to the intended branch before testing.

For custom Java applications, a startup log or controlled diagnostic endpoint can report the provider version. Avoid dumping private keys or complete trust stores. The minimum is enough to correlate the test with the implementation that executed it.

The regression condition

The upstream patch adds a test to PKIXRevocationTest. It creates a certificate path and supplies a stapled response that covers the CA certificate rather than the end-entity certificate. The response is legitimately signed, but its CertID is for the wrong certificate.

Before the fix, the checker scans the response list, finds no matching end-entity CertID, and returns successfully. The patched implementation reaches the end of the loop and throws RecoverableCertPathValidatorException with the message "no OCSP response found for certificate." The path can then try CRL validation or fail if no acceptable revocation evidence exists.

A good test fixture should contain:

  • A trusted CA and an end-entity certificate.

  • A valid OCSP response whose CertID matches the end-entity certificate.

  • A valid OCSP response whose CertID matches a different certificate from the same CA.

  • The same responder trust settings used by the application.

  • A path-validation configuration with PKIXRevocationChecker.Option.ONLY_END_ENTITY where that reflects production.

The response for the different certificate must be signed by an acceptable responder. Using arbitrary bytes would test signature rejection, not the binding defect.

Separate the expected outcomes

A matching good response should allow the normal validation path when every other condition is valid. A matching revoked response should reject the certificate. An unrelated good response should not be treated as evidence that the end-entity certificate is valid.

The unrelated-response case may produce a validation failure directly or a CRL fallback followed by a failure. The exact exception and log text depend on the caller, trust settings, and available CRL distribution points. Test the security outcome as well as the specific exception class. The certificate path must not silently complete on the strength of the wrong response.

Also test a response from an untrusted responder and an expired response. Those cases exercise signature and freshness checks and should fail independently. They help distinguish a binding regression from unrelated trust changes.

Check the calling application

The provider fix can throw a recoverable exception, but the application controls what happens next. A library or framework may catch the exception, retry, fall back to a network OCSP request, or accept the connection under a custom policy. The fixed behavior is only effective if the application handles the result correctly.

Search for catch blocks around CertPathValidatorException and RecoverableCertPathValidatorException. Determine whether they continue, downgrade, or log and fail closed. A broad catch that treats every validation exception as a reason to continue would create a different vulnerability even after the provider update.

Review callback behavior on successful mutual TLS. If authentication passes, what authorization does the peer receive? A revoked certificate accepted by an internal service can grant more than a failed HTTP request. Test both the certificate decision and the resulting access decision.

Validate the product patch, not only the library

Bouncy Castle 1.85, BC-LTS 2.73.12, BC-FJA 2.0.2, and BC-FJA 2.1.3 are the fixed branches. Atlassian's fixed releases include Confluence 11.0.0, 10.2.19 LTS, and 9.2.26 LTS; Crowd 7.2.4; and Jira Software and Jira Service Management 11.3.12 LTS or 10.3.26 LTS. Read the bulletin for the exact Data Center and Server support constraints.

Do not replace an Atlassian-managed jar unless the vendor supports that procedure. Product updates may include other library changes and configuration compatibility work. The objective is to validate the vendor-tested combination.

After the update, re-run the same fixture on each application node. Confirm the effective provider and the path-validation result. In a cluster, a rolling deployment can temporarily mix fixed and vulnerable nodes. Keep that condition within the planned change window and verify the cluster state before closing the change.

Preserve evidence

Store the input certificate and response fixtures in a controlled test environment. Record the provider versions, configuration, expected outcomes, and actual results. Remove private keys and real customer trust material from test logs.

The final evidence should show three things: the vulnerable build fails the unrelated-response test, the fixed build rejects or falls back, and the application does not convert that failure into success. That is more useful than a package-version check because it demonstrates the trust decision the vulnerability actually affects.

A test for the future

Certificate validation code often assumes that a signed response is sufficient. CVE-2026-58062 adds the missing question: does this response describe the certificate being validated? Regression tests should keep that condition in the suite.

The same test can be reused when a provider changes, a TLS framework is upgraded, or a product ships a new application server. A binding check is cheap to verify in a controlled environment and expensive to discover in production through a revoked certificate that still passes.

References