Hide Forgot
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: 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?
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: 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.
Upstream gerrit review: https://review.gerrithub.io/#/c/394865/ `ca.ocspUseCache=true` must be set in CS.cfg for this enhancement to take effect.
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 \ -no_nonce 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.)
Upstream commit: fc3067f2e955e18405f735269bfe5fe135382d21
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
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. https://access.redhat.com/errata/RHBA-2018:0925