Well I solved both my issues. The latter issue - getting "Unable to verify OCSP Responder's signature" exception no matter what signing certificate I had used - was a responder issue, not a Java, CXF, or WSS4J issue at all. So that's solved.
The original issue I had was that I needed to be able to handle multiple OCSP signing certificates, and I think I've solved that one too, if anyone is interested. I wrote and configured a custom SignatureTrustValidator that looks for the "Unable to verify OCSP Responder's signature" exception, resets the relevant java.security.Security properties to the next one on the list, and retries the validation. I wouldn't call it elegant, but it works, so there's that. Thanx, Stephen W. Chappell -----Original Message----- From: Chappell, Stephen CTR (FAA) Sent: Friday, June 06, 2014 9:40 AM To: users@cxf.apache.org; cohei...@apache.org Subject: RE: CXF & OCSP Signers Well I was thinking more along the lines of completely removing it. It's totally removed from the maven repository now, and I wasn't using it in my code at all - I only added it as a dependency to test your theory about the ordering of entries in the HashSet. It seems like there must be some dirt left behind by it, but so far I haven't been able to find it. Stephen W. Chappell Engility Corporation, SWIM Task Lead William J. Hughes Technical Center, FAA Information Security Team, ANG-B31 (609) 485-6710 (office) (609) 980-9329 (cell) -----Original Message----- From: Colm O hEigeartaigh [mailto:cohei...@apache.org] Sent: Friday, June 06, 2014 9:37 AM To: users@cxf.apache.org Subject: Re: CXF & OCSP Signers Try using a more recent version of BouncyCastle? (e.g. 1.50). Colm. On Fri, Jun 6, 2014 at 1:53 PM, <stephen.ctr.chapp...@faa.gov> wrote: > Well strangely, after adding bcprov-jdk16 version 140 as a Maven > dependency, I consistently get the "Unable to verify OCSP Responder's > signature" exception, regardless of whether I have one OCSP signing > cert or multiple OCSP signers in the truststore. When I take out all > the signing certs, I get "Cannot find the responder's certificate (set > using the OCSP security properties)". I removed bcprov as a dependency > from Maven, and ran "mvn dependency:purge-local-repository" and > rebuilt the STS, but still get the same results. > > I have verified with OpenSSL that the responder is up and active, and > using the expected signing certificate to sign messages. So as far as > I can tell, this is something to do with adding bcprov as a maven > dependency, and I can't figure out how it's still impacting even after it's > been removed. > > Does anyone have any idea what might be going on? > > Thanx, > > Stephen W. Chappell > > -----Original Message----- > From: Chappell, Stephen CTR (FAA) > Sent: Wednesday, June 04, 2014 8:33 AM > To: users@cxf.apache.org > Subject: RE: CXF & OCSP Signers > > Colm - > > Adding bcprov-jdk16 version 140 as a Maven dependency did fix the > consistency issue - now I consistently get the "Unable to verify OCSP > Responder's signature" exception. I am guessing that's because of the > order of certificates in the truststore more so than anything else. > > The issue I think boils down to getting Java, etc., to utilize > multiple OCSP signing certificates. I've verified that multiple > entries in the java.security file aren't helpful, only the last one > parsed is used, so that's no help. And in my deployment, I'm not going > to be able to guarantee that any particular STS has to deal only with > a single OCSP signing certificate. So I really need a way to deal with > at least two OCSP signing certificates. > > I have a pretty messy solution in mind that I could try, but I'll look > into bouncy castle first to see if there's anything there that can help. > > Stephen W. Chappell > > > -----Original Message----- > From: Colm O hEigeartaigh [mailto:cohei...@apache.org] > Sent: Wednesday, June 04, 2014 6:24 AM > To: users@cxf.apache.org > Subject: Re: CXF & OCSP Signers > > You've reminded me of something I read recently: > > > http://stackoverflow.com/questions/19897598/bouncycastle-provider-and- > java-sun-provider-interopability-issue > > "The problem with your code is that SUN's provider implementation of > CertStore.getCertificates() returns HashSet. And HashSet makes no > guarantees as to the iteration order of the set; in particular, it > does not guarantee that the order will remain constant over time." > > If you add "bcprov" as a dependency do you see the same random failures? > > Colm. > > > On Tue, Jun 3, 2014 at 4:06 PM, <stephen.ctr.chapp...@faa.gov> wrote: > > > 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 > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
