This might block enabling OCSP by default (ticket #1134).

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1174496

This TRAC ticket is being closed as wontfix since it is a documentation issue that will be fixed by ​https://bugzilla.redhat.com/show_bug.cgi?id=1174496.

The documentation provided at the link in the description seems accurate. But let's see if we can figure out what's wrong.
Could you confirm the following:
During testing, did you make sure the last crl update in the ocsp contain the revocation record of the agent cert before you perform the ssl client auth using the revoked agent cert? (please answer this question).

The following is a simple test case steps:
1. set up according to the link: https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/revocation-checking.html#enabling-ocsp-checking-for-the-tks-and-drm
2. make sure your test agent cert is issued by the same ca and is valid (make sure it works in the first place by acessing the agent page)
3. revoke the agent cert
4. make sure the updated crl contain the revocation record and publish to the ocsp server
5. test this case by using the now revoked agent cert to access the same agent page you tested in step 2

one thing to note: the doc currently does not contain the latest TLS changes, so you want to just modify the relevant fields in the latest builds/installation so not to lose the new TLS range parameters.

The paths and startup commands also need to be updated, for example:

• /var/lib/pki-ocsp/alias -> /var/lib/pki/<OCSP instance name>/alias
• /var/lib/pki-kra/conf/ -> /var/lib/pki/<KRA instance name>/conf/
• service pki-ca stop -> systemctl stop pki-tomcatd@<CA instance name>.service

We also need a Dogtag doc (as opposed to RHCS doc) either as a Wiki page or man page for the OCSP setup.

This ticket is needed to resolve #1134 in 10.2.2.

After following the steps in https://access.redhat.com/documentation/en-US/Red_Hat_Certificate_System/8.1/html/Admin_Guide/revocation-checking.html#enabling-ocsp-checking-for-the-tks-and-drm, I am not able to access the agent page using a valid agent cert. Accessing the agent page using the same valid agent cert is successful when ocsp revocation checking is not enabled. I modified KRA's CS.cfh with the following

auths.revocationChecking.enabled=true

OCSP's CS.cfg did not have any parameter that was associated with enable revocation checking, so I did not change anything in that file.

Server.xml look as below

<Connector name="Secure" port="30042" protocol="HTTP/1.1" SSLEnabled="true" sslProtocol="SSL" scheme="https" secure="true" maxHttpHeaderSize="8192" acceptCount="100" maxThreads="150" minSpareThreads="25" enableLookups="false" disableUploadTimeout="true" sslImplementationName="org.apache.tomcat.util.net.jss.JSSImplementation" enableOCSP="true" ocspResponderURL="<a href="http://sigma.lab.eng.rdu.redhat.com:30044/ca/ocsp"">http://sigma.lab.eng.rdu.redhat.com:30044/ca/ocsp" ocspResponderCertNickname="caocspsigningcert" ocspCacheSize="1000" ocspMinCacheEntryDuration="60" ocspMaxCacheEntryDuration="120" ocspTimeout="10" strictCiphers="true" clientAuth="want" sslOptions="ssl2=false,ssl3=false,tls=true" ssl2Ciphers="-SSL2_RC4_128_WITH_MD5,-SSL2_RC4_128_EXPORT40_WITH_MD5,-SSL2_RC2_128_CBC_WITH_MD5,-SSL2_RC2_128_CBC_EXPORT40_WITH_MD5,-SSL2_DES_64_CBC_WITH_MD5,-SSL2_DES_192_EDE3_CBC_WITH_MD5" ssl3Ciphers="-SSL3_FORTEZZA_DMS_WITH_NULL_SHA,-SSL3_FORTEZZA_DMS_WITH_RC4_128_SHA,+SSL3_RSA_WITH_RC4_128_SHA,-SSL3_RSA_EXPORT_WITH_RC4_40_MD5,+SSL3_RSA_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_DES_CBC_SHA,-SSL3_RSA_EXPORT_WITH_RC2_CBC_40_MD5,-SSL3_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA,-SSL_RSA_FIPS_WITH_DES_CBC_SHA,+SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA,-SSL3_RSA_WITH_NULL_MD5,-TLS_RSA_EXPORT1024_WITH_RC4_56_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA" tlsCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,+TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA" sslVersionRangeStream="tls1_0:tls1_2" sslVersionRangeDatagram="tls1_1:tls1_2" sslRangeCiphers="-TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,-TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,+TLS_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_RSA_WITH_AES_128_CBC_SHA,+TLS_RSA_WITH_AES_256_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,-TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_DSS_WITH_AES_128_CBC_SHA,+TLS_DHE_DSS_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA,+TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_CBC_SHA256,+TLS_RSA_WITH_AES_256_CBC_SHA256,+TLS_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,+TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,+TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,+TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256" serverCertNickFile="/var/lib/pki/pki-master/conf/serverCertNick.conf" passwordFile="/var/lib/pki/pki-master/conf/password.conf" passwordClass="org.apache.tomcat.util.net.jss.PlainPasswordFile" certdbDir="/var/lib/pki/pki-master/alias" />

I see the following results

[root@sigma dogtag]# curl --cacert /opt/rhqa_pki/certs_db/ca_cert.pem -E "ROOTCA_agentV:Secret123" -d "pageSize=50&crlIssuingPoint=MasterCRL&pageStart=1&crlDisplayType=cachedCRL" https://sigma.lab.eng.rdu.redhat.com:30042/ca/agent/ca/displayCRL
curl: (58) SSL peer cannot verify your certificate.

debug log has the following

[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet:service() uri = /ca/ocsp
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet: caOCSP start to service.
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: IP: 10.12.0.90
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet: no authMgrName
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet: in auditSubjectID
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet: auditSubjectID auditContext {locale=en_US, ipAddress=10.12.0.90}
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet auditSubjectID: subjectID: null
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet: in auditGroupID
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet: auditGroupID auditContext {locale=en_US, ipAddress=10.12.0.90}
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet auditGroupID: groupID: null
[SignedAuditEventFactory: create() message=[AuditEvent=AUTHZ_FAIL][SubjectID=$NonRoleUser$][Outcome=Failure][aclResource=certServer.ee.request.ocsp]Op=submit authorization failure

[26/Jan/2015:13:19:37]http-bio-30044-exec-7: In LdapBoundConnFactory::getConn()
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: masterConn is connected: true
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: getConn: conn is connected true
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: getConn: mNumConns now 5
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: returnConn: mNumConns now 6
[SignedAuditEventFactory: create() message=[AuditEvent=ROLE_ASSUME][SubjectID=$NonRoleUser$][Outcome=Failure]Role=<null> assume privileged role

[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet.java: renderTemplate
[26/Jan/2015:13:19:37]http-bio-30044-exec-7: CMSServlet: curDate=Mon Jan 26 13:19:37 EST 2015 id=caOCSP time=4

The problem seems to be caused by missing RA subsystem module (ticket #1250).

The Dogtag documentation will be added here:
http://pki.fedoraproject.org/wiki/Certificate_Revocation_Checking

The problem happens on shared instance only (ticket #1202). The documentation needs to be updated once the ticket is fixed.

This ticket depends on ticket #1202 which will be fixed in 10.3.

Per triage meeting of 2/25/2015: 10.2.3

This ticket is merged into #1202.

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/1745

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.