#1202 Revocation Checking issue with client certs and shared PKI instances
Closed: migrated 3 years ago by dmoluguw. Opened 9 years ago by jmagne.

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.

  1. Now that we have shared subsystems we have recommended that configuring OCSP for the shared instance makes no
    sense and will not work.

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

  1. Testing and conclusions:

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

  1. I tried this in the KRA and the routine in question does not return a conclusive status of the certificate, thus fails.

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:

  • configure the revocation checking URL by default pointing to the issuing CA
  • change the self tests to use CMS.isRevoked()

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.

Per Offline Triage of 11/30/2016-12/01/2016: FUTURE - major

Metadata Update from @jmagne:
- Issue set to the milestone: FUTURE

7 years ago

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)

6 years ago

[20171025] - Offline Triage ==> 10.6

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

6 years ago

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)

5 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/1764

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.

Metadata Update from @dmoluguw:
- Issue close_status updated to: migrated
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata