[Pki-devel] Revocation investigation with Shared Tomcat instance

[John Magne]

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.

3. Testing and conclusions:

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

5. 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;
    }

Since we have a shared instance, the certDB should be found and thus allow the whole thing to work.
Now for some reason this bombs out and we are doomed from this point forward.


Questions:

1. edewata, alee, do you guys know of something that might have changed to have caused this.

2. auths.instance.AgentCertAuth.pluginName=AgentCertAuth setting no longer has an effect because the PKIRealm appears to be
hardcoding the authentication manager to be the above "CertUserDBAuthentication"manager. This is perhaps a side point but worth
asking about?

3. Looking for opinions upon how to deal with this? It may be a case of simply biting the bullet and figuring out why our code
no longer works and filing and completing a ticket for this. 

I have not tested the other non CA subs but I am pretty sure the problem will surface there as well.

thanks,
jack