Skip to content

check all ocsp response records for cert serial number

  • check all ocsp response records for cert serial number

Signed-off-by: Jeff Mattson jmattson@sei.cmu.edu

Checklist

  • Commits have Signed-off-by: with name/author being identical to the commit author
  • Code modified for feature
  • Test suite updated with functionality tests
  • Test suite updated with negative tests
  • Documentation updated / NEWS entry present (for non-trivial changes)
  • CI timeout is 2h or higher (see Settings/CICD/General pipelines/Timeout)

Reviewer's checklist:

  • Any issues marked for closing are addressed
  • There is a test suite reasonably covering new functionality or modifications
  • Function naming, parameters, return values, types, etc., are consistent and according to CONTRIBUTION.md
  • This feature/change has adequate documentation added
  • No obvious mistakes in the code

Discussion

OCSP verification fails when the certificate in question does not match the first response record of a stapled OCSP response.

Some servers return a stapled ocsp response with multiple certificate status records, and this codebase only compares the certificate with the first response record.

Since Ubuntu builds git with gnuTLS, this leaves a large population needing to rebuild git with OpenSSL or turning off ssl verification in order to work with some (well established) server's that staple multiple cert status in an OSCP response.

This MR changes the ocsp checking behavior by ignoring the indx parameter (which in this codebase is always set to 0) and instead iterating through the responses for a record with a matching certificate serial number.

The indx parameter remains in order to preserve the api, but ignoring it is not a breaking change since the new behavior matches the previous behavior (where it was working). For external clients of this api that do actually pass in an index, it might cost negligible performance iterating to find the same index that was passed in.

This issue was also reported in #1372 (closed).

Edited by Daiki Ueno

Merge request reports

Loading