RUBY-3694 Use correct CA when verifying OCSP endpoint #2944
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alcaeus
reviewed
Aug 6, 2025
lib/mongo/socket/ssl.rb
Outdated
| @@ -460,7 +460,7 @@ def verify_ocsp_endpoint!(socket, timeout = nil) | |||
| end | |||
|
|
|||
| cert = socket.peer_cert | |||
| ca_cert = socket.peer_cert_chain.last | |||
| ca_cert = socket.peer_cert_chain[1] | |||
There was a problem hiding this comment.
Can we rely on this certificate always working or should we fall back to check all other certificates as well?
There was a problem hiding this comment.
There are two points for why I think this is correct (but I am absolutely not well-versed in SSL lore, and may have this all wrong).
- Per the Suggested OCSP Behavior section of our OCSP spec, item 8 says "If any unvalidated intermediate certificates remain and those certificates have OCSP endpoints, for each certificate, the driver SHOULD NOT reach out to the OCSP endpoint specified and attempt to validate that certificate." So, we don't try to validate the OCSP endpoints of any intermediate certs. (Not sure if that's what you were referring to, but figured I'd be thorough.)
- Given that we saw the warnings/errors happening because we were trying to validate using the last item in the chain, I'm assuming that using subsequent certificates to validate here would be similarly problematic. Or, is the correct behavior that we're supposed to try each certificate in the chain until one of them gives the green light, ignoring error messages along the way?
jamis
added a commit
to jamis/mongo-ruby-driver
that referenced
this pull request
Aug 7, 2025
* use the next cert in the chain as the CA when verifying OCSP * don't assume the issuer is at a particular position in the chain * Fix incorrect method description
jamis
added a commit
that referenced
this pull request
Aug 19, 2025
* RUBY-3694 Use correct CA when verifying OCSP endpoint (#2944) * use the next cert in the chain as the CA when verifying OCSP * don't assume the issuer is at a particular position in the chain * Fix incorrect method description * https for submodules * fix submodule syntax * update test configuration * bump drivers-evergreen-tools for DB version lookups * allow prepare_server to compute the distro in the format it needs * more evergreen config tweaks * more test tweaks * fix broken resolver specs * don't try to use mock_dns on ruby 2.7 * make sure and definie the minimum_mri_version constraint * use https to clone git repos * maybe we need to skip sooner to avoid the around hooks... * Gracefully handle the case where the issuer can't be found (#2946) * no need to test against latest; 2.20.x only supports up to 7.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The driver was incorrectly using the last certificate in the chain as the CA when performing OCSP verification. This worked for the case where the chain had only two elements, but for longer chains, it was causing the verification to fail.
This change searches the cert chain for the issuer of the peer certificate, and uses that as the CA for the verification request.