Bug 1523443 - HAProxy rejects OCSP responses due to missing nextupdate field
Summary: HAProxy rejects OCSP responses due to missing nextupdate field
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pki-core
Version: 7.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 7.5
Assignee: Fraser Tweedale
QA Contact: Asha Akkiangady
Marc Muehlfeld
Depends On:
TreeView+ depends on / blocked
Reported: 2017-12-08 01:09 UTC by Matthew Harmsen
Modified: 2020-10-04 21:27 UTC (History)
5 users (show)

Fixed In Version: pki-core-10.5.1-6.el7
Doc Type: Enhancement
Doc Text:
The Certificate System CA subsystem's OCSP provider now includes the "nextUpdate" field in responses If the Certificate Authority (CA) is configured to use the Certificate Revocation List (CRL) cache, the CA subsystem's Online Certificate Status Protocol (OCSP) responder now includes the "nextUpdate" field in OCSP responses. As a result, in such scenarios, clients which conform to the Lightweight OCSP Profile (RFC 5019) are now able to process OCSP responses.
Clone Of:
Last Closed: 2018-04-10 17:02:54 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github dogtagpki pki issues 2781 0 None None None 2020-10-04 21:27:46 UTC
Red Hat Product Errata RHBA-2018:0925 0 None None None 2018-04-10 17:03:37 UTC

Description Matthew Harmsen 2017-12-08 01:09:19 UTC
The folllowing bug was cloned from dogtag Pagure Issue #2661 by ftweedal:

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.

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.

Some thoughts on this:

    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.

    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:

    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?

Comment 2 Matthew Harmsen 2017-12-08 02:33:56 UTC
cfu wrote the following:

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:
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.

Comment 5 Fraser Tweedale 2018-01-16 04:11:01 UTC
Upstream gerrit review: https://review.gerrithub.io/#/c/394865/

`ca.ocspUseCache=true` must be set in CS.cfg for this enhancement to
take effect.

Comment 6 Fraser Tweedale 2018-01-17 03:22:02 UTC
Verification steps:

- install Dogtag.
- set ca.ocspUseCache=true in CS.cfg and restart
- perform an OCSP request.  Verify that OCSP response contains
  `nextUpdate' field.  e.g.:

    % openssl ocsp \
        -CAfile /etc/ipa/ca.crt \
        -issuer /etc/ipa/ca.crt \
        -url http://f27-1.ipa.local:8080/ca/ocsp \
        -serial 1 \
    Response verify OK                                                     
    1: good                                                                
            This Update: Jan 16 03:45:00 2018 GMT                          
            Next Update: Jan 16 06:00:00 2018 GMT                          

(Vary certificate paths, URL and serial as appropriate.)

Comment 7 Fraser Tweedale 2018-01-17 03:22:36 UTC
Upstream commit: fc3067f2e955e18405f735269bfe5fe135382d21

Comment 9 Sumedh Sidhaye 2018-01-31 05:58:04 UTC
Build used for verification:
root@csqa4-guest01 ecc_setup # rpm -qi pki-server
Name        : pki-server
Version     : 10.5.1
Release     : 6.el7
Architecture: noarch
Install Date: Monday 29 January 2018 10:37:10 PM EST
Group       : System Environment/Base
Size        : 4805315
License     : GPLv2
Signature   : RSA/SHA256, Tuesday 23 January 2018 10:44:40 PM EST, Key ID 199e2f91fd431d51
Source RPM  : pki-core-10.5.1-6.el7.src.rpm
Build Date  : Tuesday 23 January 2018 10:14:38 PM EST
Build Host  : ppc-016.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
URL         : http://pki.fedoraproject.org/
Summary     : Certificate System - PKI Server Framework

Procedure for verification:

1. install dogtag
2. set ca.ocspUseCache=true in CS.cfg and restart instance
3. perform a OCSP request and verify that the OCSP response contains the nextUpdate field using the following command:

openssl ocsp -CAfile ca.crt -issuer ca.crt -url http://csqa4-guest01.idm.lab.eng.rdu.redhat.com:8080/ca/ocsp -serial 0x96a64e2 -no_nonce
Response verify OK
0x96a64e2: good
	This Update: Jan 31 05:52:39 2018 GMT
	Next Update: Jan 31 06:00:00 2018 GMT

Comment 15 errata-xmlrpc 2018-04-10 17:02:54 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.