I have managed to take a look at the problems we have seen with configuring revocation checking on incoming client auth certs for the various subsystems. Here is a recap and some further info.
Now that we have shared subsystems we have recommended that configuring OCSP for the shared instance makes no sense and will not work.
The second recommendation was to configure revocation checking within the subsystem. This sort of thing is configured allegedly as follows for a kra instance:
auths.instance.AgentCertAuth.agentGroup=Certificate Manager Agents auths.instance.AgentCertAuth.pluginName=AgentCertAuth auths.instance.TokenAuth.pluginName=TokenAuth auths.revocationChecking.bufferSize=50 auths.revocationChecking.enabled=true auths.revocationChecking.kra=kra auths.instance.AgentCertAuth.checkRevocation=true
The key setting is this one:
auths.revocationChecking.enabled=true
Also cfu had previously recommended that we put this one in:
auths.instance.AgentCertAuth.pluginName=AgentCertAuth More on this later.
Testing and conclusions:
Trying this setting on the CA appears to work just fine. After putting the admin cert "On Hold" the code intervenes and throws some sort of "Invalid credentials" error to the screen when trying to access the CA's agent page.
The key piece of code that enforces this NOW is in CertUserDBAuthentication.java:
if (mRevocationCheckingEnabled) { X509CertImpl cert0 = (X509CertImpl) x509Certs[0]; if (cert0 == null) { log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_AUTH_NO_CERT")); throw new EInvalidCredentials(CMS.getUserMessage("CMS_AUTHENTICATION_NO_CERT")); } if (CMS.isRevoked(x509Certs)) { log(ILogger.LL_FAILURE, CMS.getLogMessage("CMSCORE_AUTH_REVOKED_CERT")); throw new EInvalidCredentials(CMS.getUserMessage("CMS_AUTHENTICATION_INVALID_CREDENTIAL")); } }
The routine "CMS.isRevoked works in the CA case.
CFU is of the opinion that this used to work and perhaps something was changed along the way. The routine she flagged as a possibility is here:
private ICertificateRepository getCertDB() { ICertificateRepository certDB = null; try { ICertificateAuthority ca = (ICertificateAuthority) SubsystemRegistry.getInstance().get("ca"); if (ca != null) { certDB = ca.getCertificateRepository(); } } catch (Exception e) { CMS.debug("CMSEngine: " + CMS.getLogMessage("CMSCORE_AUTH_AGENT_CERT_REPO")); } return certDB; }
I believe the problem here is one subsystem needs to communicate across the web app boundary on the same instance to access the CA's cert db management classes. Here we would need to do searches on this data in a read only fashion from say a KRA or TKS.
Per CS/DS meeting of 11/17/2014: 10.3
The CMS.isRevoked() does not work on non-CA subsystems because the RA subsystem module is missing (see ticket #1250). Per discussion with cfu this functionality should be reimplemented using an OCSP client (not using the global OCSP in tomcatjss).
pki-edewata-0553-Fixed-revocation-checking-on-shared-instance.patch pki-edewata-0553-Fixed-revocation-checking-on-shared-instance.patch
Additional things to do:
master: 944372f857cd631c2cfc51ed7d090912fc2516ff
Per triage meeting of 2/25/2015: 10.2.3
Remove references to IRegistrationAuthority (ticket #1250).
Enable cert revocation checking by default (ticket #1134).
Fix documentation (ticket #1182).
The attached patch #553 provides the fix using Java OCSP client, which will work consistently on both shared instance and separate instances. The alternative is to use cross-context communication (http://blog.imaginea.com/cross-context-communication-between-web-applications/) for shared instance, and keep using TomcatJSS's OCSP for separate instances.
This is not required for 10.2.x.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1232039 (Red Hat Certificate System)
Per Offline Triage of 11/30/2016-12/01/2016: FUTURE - major
Metadata Update from @jmagne: - Issue set to the milestone: FUTURE
Metadata Update from @mharmsen: - Custom field feature adjusted to None - Custom field proposedmilestone adjusted to None - Custom field proposedpriority adjusted to None - Custom field reviewer adjusted to None - Custom field version adjusted to None - Issue close_status updated to: None - Issue set to the milestone: 10.5 (was: FUTURE)
[20171025] - Offline Triage ==> 10.6
Metadata Update from @mharmsen: - Issue set to the milestone: 10.6 (was: 10.5)
Per 10.5.x/10.6 Triage: FUTURE
RHBZ: CLOSED UPSTREAM
Metadata Update from @mharmsen: - Custom field rhbz reset (from https://bugzilla.redhat.com/show_bug.cgi?id=1232039) - Issue set to the milestone: FUTURE (was: 10.6)
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/1764
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Metadata Update from @dmoluguw: - Issue close_status updated to: migrated - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.