[Pki-devel] Revocation investigation with Shared Tomcat instance
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