#2661 HAProxy rejects OCSP responses due to missing nextupdate field
Closed: fixed 7 years ago Opened 8 years ago by jaosorior.

The OCSP responder currently doesn't provide the nextupdate field.

Services such as HAProxy require this field, or else they will reject the OCSP response.


+1.

See also https://tools.ietf.org/html/rfc5019: The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, and https://github.com/sleevi/cabforum-docs/pull/2/files?diff=split for more info on current practices / client expectations for OCSP stapling.

A few knobs to configure how the OCSP responder should behave would be no bad thing.

Metadata Update from @ftweedal:
- Custom field component adjusted to General
- Custom field feature adjusted to ''
- Custom field origin adjusted to Community
- Custom field proposedmilestone adjusted to ''
- Custom field proposedpriority adjusted to ''
- Custom field reviewer adjusted to ''
- Custom field type adjusted to defect
- Custom field version adjusted to ''

8 years ago

Metadata Update from @mharmsen:
- Issue set to the milestone: 0.0 NEEDS_TRIAGE

8 years ago

Metadata Update from @mharmsen:
- Issue priority set to: ---

8 years ago

Per PKI Bug Council of 04/27/2017: 10.5 - major

Metadata Update from @mharmsen:
- Issue priority set to: major (was: ---)
- Issue set to the milestone: 10.5 (was: 0.0 NEEDS_TRIAGE)

8 years ago

Per CS/DS Meeting 09/25/2017: 10.5 critical

Metadata Update from @mharmsen:
- Issue priority set to: critical (was: major)

7 years ago

Metadata Update from @mharmsen:
- Issue assigned to ftweedal

7 years ago

Some thoughts on this:

  1. if the CRL cache is enabled and OCSP responder is configured to use it,
    then nextUpdate for the OCSP response should match the nextUpdate of
    the CRL.

  2. if the cache is not used, semantically the nextUpdate is "now" because the
    the status information is retrieved afresh from the database each time. If a
    cert gets revoked this information is immediately available to the OCSP responder.
    But we cannot set a nextUpdate of now, because delivery/processing delays or
    clock skew may mean that the client sees it as "the past", which means it must reject
    the request. From RFC 5019: https://tools.ietf.org/html/rfc5019

Clients MUST check for the existence of the nextUpdate field and MUST
ensure the current time, expressed in GMT time as described in
Section 2.2.4, falls between the thisUpdate and nextUpdate times. If
the nextUpdate field is absent, the client MUST reject the response.

So we need to push the nextUpdate time out a little bit. I have no idea
what value we should use here... probably something around 5m to 30m
would be appropriate? @cfu what do you think?

Metadata Update from @mharmsen:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1523443

7 years ago

Here is my take on this. First of all, Dogtag OCSP was not originally developed with the lightweight OCSP in mind. From the OCSP responder server point of view, according to RFC 6960:
https://tools.ietf.org/html/rfc6960#section-4.2.2.1
nextUpdate CAN be lef out:
"If nextUpdate is not set, the responder is indicating that newer
revocation information is available all the time"

My understanding is that the purpose of the "nextUpdate" field in an OCSP response is to allow clients to save themselves a trip if (currentTime < nextUpdate).

That being said, there is no reason to add support for the clients adhering to rfc5019.
From the cited "Time" section in the RFC 6960, thisUpdate and nextUpdate should naturally match that of the CRL.
It seems like tfc5019 already addressed the concerns of time skew:
"... Clients MAY allow configuration
of a small tolerance period for acceptance of responses after
nextUpdate to handle minor clock differences relative to responders
and caches. "
So that's up to the client to resolve it.

My conclusion is that we can set ocsp response to match that of the CRL and leave it at that.

Pushed to master (fc3067f2e955e18405f735269bfe5fe135382d21)

Metadata Update from @ftweedal:
- Issue close_status updated to: fixed

7 years ago

Metadata Update from @mharmsen:
- Issue set to the milestone: 10.5.4 (was: 10.5)

7 years ago

Metadata Update from @mharmsen:
- Custom field fixedinversion adjusted to pki-core-10.5.4-1.fc27

7 years ago

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/2781

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.

Log in to comment on this ticket.

Metadata