Repository navigation
Parse OCSP GeneralizedTime in UTC and reject invalid dates - #470
Closed
SougataXdev wants to merge 1 commit into
Closed
SougataXdev wants to merge 1 commit into
SougataXdev wants to merge 1 commit into
Conversation
parseX509Date ignored the trailing Z in GeneralizedTime values, so dates parsed as NaN and the freshness check in checkOCSPStatus never rejected stale responses. It also used the local timezone for values without Z. Parse explicitly with Date.UTC, validate the components round-trip, and throw on malformed input. nextUpdate is optional per RFC 6960, so skip only the expiry half of the check when absent.
Collaborator
|
Resolved via #473 |
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
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.
Fixes #447.
parseX509Date only matched 14 digits with no suffix, so GeneralizedTime values ending in Z fell through to new Date unchanged and parsed as Invalid Date. NaN timestamps made both sides of the freshness check in checkOCSPStatus false, so stale or future-dated good responses were accepted. Values without Z were also parsed in the local timezone instead of UTC.
This change parses the supported format explicitly with Date.UTC, verifies the calendar components round-trip (Date.UTC normalizes overflow), and throws FAILURE on malformed input so it can never pass the gate as NaN. nextUpdate is optional per RFC 6960, so when absent only the thisUpdate half of the check applies.
Tests: