Andrei - Before running your code, I ran a few tests to make sure I wasn't losing my mind. Here's the results:
*** Test 1: STS trust store configured with only one OCSP signing certificate (ocsp2) ... When sending revocation checks to ocsp1, I consistently get an exception, regardless of the revocation status of the certificate: Jun 4, 2014 7:22:43 AM org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor handleMessage WARNING: org.apache.ws.security.WSSecurityException: General security error (Error during certificate path validation: Unable to verify OCSP Responder's signature) *** Test 2: STS trust store configured with only one OCSP signing certificate (ocsp1) ... When sending revocation checks to ocsp1, I consistently get the correct response - either nothing logged and I get a token issued, or a fault response with an exception logged stating that the certificate has been revoked. *** Test 3: Trust store configured with two OCSP signing certificates (ocsp3) ... When sending a revocation check for a valid certificate to ocsp1, three times I got the correct response (nothing logged, and token issued). On tries 4-6, I got the exception listed under Test 1, above. On the 7th try, I got the correct response. Based on those results, I'm fairly certain that what I'm seeing is that the WSS4JInInterceptor is throwing a WSSecurityException whenever it can't match the certificate that signed the OCSP response with whichever certificate it happened to pull out of the HashSet it loads the truststore into (based on the link and description that Colm provided). So given that, I think I have two problems: 1. Java/WSS4J doesn't know which responder cert to pull out of the HashSet. I'm guessing (yes, I should look in the code, I will look in a bit) that it is pulling out the first cert it finds that matches the criteria in the java.security file - for me right now, that's the cert subject name. Both of my certs have the same subject name, which I think is not ideal but is also not in my control at the moment. 2. java.security only really gives you a way to specify on OCSP signing certificate, I think. At least, it's not obvious how java will react to having e.g., multiple ocsp.responderCertSerialNumber entries. I'll try it, but I'm predicting that chaos will ensue. Thanx, Stephen W. Chappell -----Original Message----- From: Andrei Shakirin [mailto:[email protected]] Sent: Tuesday, June 03, 2014 5:16 PM To: [email protected] Subject: RE: CXF & OCSP Signers Hi, Interesting ... as far as I can see java throws "Unable to verify OCSP Responder's signature" only if responderCert is null in OCSPResponse. Strange that it happens only time to time. Could you experiment a bit with OCSP validation explicitly, using something like this: Set certSet = new HashSet(); X509Certificate ocspCert = getCertFromFile(OCSP_SERVER_CERT); certSet.add(ocspCert); CertStoreParameters storeParams = new CollectionCertStoreParameters(certSet); CertStore store = CertStore.getInstance("Collection", storeParams); // init PKIX parameters PKIXParameters params = null; params = new PKIXParameters(trustedCertsSet); params.addCertStore(store); // enable OCSP Security.setProperty("ocsp.enable", "true"); if (ocspServer != null) { Security.setProperty("ocsp.responderURL", args[1]); Security.setProperty("ocsp.responderCertSubjectName", ocspCert.getSubjectX500Principal().getName()); } // perform validation CertPathValidator cpv = CertPathValidator.getInstance("PKIX"); PKIXCertPathValidatorResult cpv_result = (PKIXCertPathValidatorResult) cpv.validate(cp, params); X509Certificate trustedCert = (X509Certificate) cpv_result.getTrustAnchor().getTrustedCert(); Perhaps you will be able to reproduce the problem and investigate it in details. Regards, Andrei. > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: Dienstag, 3. Juni 2014 17:07 > To: [email protected] > Subject: CXF & OCSP Signers > > My apologies if this is the wrong place for this question, as it's not > strictly a CXF issue, but I'm hoping someone might be able to kick me in the > right direction ... > > In my architecture, the STS I am building will need to check > certificate revocation against one of a set of OCSP responders. > Revocation checking works well using the standard Java configuration, > that is not an issue. What is an issue though is that we are using a > hierarchical OCSP architecture, with multiple OCSP signers, each with > their own certificate. So when checking the status of a cert against a > responder, depending on the health of everything in the system, the > revocation response could be signed with any one of those OCSP signing certs. > > With a single signing cert, I can add that cert to the CXF STS's > truststore, and revocation checking works perfectly. I had thought > that if I added additional signing certs to the trust store, Java > would just match the cert in the OCSP response against any of the > certs in the truststore, but instead it looks like Java just gets > confused and randomly picks one to match against - it may not be > random, but it's not consistent as I'll sometimes get "Unable to verify OCSP > Responder's signature" errors kicked out, and sometimes get the proper status. > > Again, my apologies if this question is misdirected. Any help would be > greatly appreciated. > > Stephen W. Chappell
