Try using a more recent version of BouncyCastle? (e.g. 1.50). Colm.
On Fri, Jun 6, 2014 at 1:53 PM, <[email protected]> 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: [email protected] > 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:[email protected]] > Sent: Wednesday, June 04, 2014 6:24 AM > To: [email protected] > 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, <[email protected]> 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
