--- On Wed, 10/21/09, Damian Krzeminski <[email protected]> wrote:
> From: Damian Krzeminski <[email protected]> > Subject: Re: [sipX-dev] SSLHandshakeException while connecting to Google > service > To: [email protected] > Date: Wednesday, October 21, 2009, 3:35 AM > Scott Lawrence wrote: > > On Tue, 2009-10-20 at 15:59 -0700, George Niculae > wrote: > >> javax.net.ssl.SSLHandshakeException: > >> sun.security.validator.ValidatorException: PKIX > path building failed: > >> > sun.security.provider.certpath.SunCertPathBuilderException: > unable to > >> find valid certification path to requested > target" > >> > > The first thing to figure out is: which certificate is > the problem? > > This is not as obvious as it might seem. > > > > The 'validity' of a certificate depends on a few > things: > > > > * is it constructed in > a syntactically correct way, using the > > right magic > values in the right places? The certs our > > generation > script does this right, as do all the commercial CAs > > I've > encountered, so this is unlikely to be your problem. > > > > * are the dates valid - > certs have a start and stop time, and > > outside those > times they are no good (the times are in UT, so > > timezones don't > matter). Unless you were careless with your > > system time, > this is not likely to be your problem. > > > > * is the signature > valid? the signature is a hash value encrypted > > with the private > key of the signer - if you rehash the inputs > > (all contents of > the cert) and decode the signature using the > > signers public > key and get the same value, then the signature is > > valid. > > > > > * do you have the public key of the signer > (the CA)? you > > > can't perform the check above unless you > have the public > > > key of the CA. The openssl software > comes with a bunch > > > of built-in certificates, but they are by > no means all > > > the CAs in the world, and if you're > missing the one that > > > signed the cert you're trying to validate, > then you're > > > just out of luck. > > > > > > * The CA certificate is itself a > certificate that must be > > > signed by something, and to validate any > cert, you have > > > to check the whole chain back to something > that is just > > > a priori trusted (that's what that bundle > that comes > > > with openssl is really about). Those > 'root' CA > > > certificates are self-signed (just like > the one we > > > generate for our own internal certificate > authority). > > > > You can use the generate-ssl-keys --show-cert option > to dump a > > certificate in readable form, which will help you > decode who/what signed > > it. > > > > Then there's the additional problem that java has it's > own idiosyncratic > > way of storing certificates and keys and all that has > to be sychronized > > with everything else to be useful... > > > > > > > > Google cert is signed by a "real" CA. So basically what's > going on here - > google tells us "Hey, I am Google, you can check with > important CA if you > don't believe". And sipXconfig says "I do not see your > important CA in my > cert chain, I only trust bogus CA that we generated during > install". > > One way of fixing this would be adding couple of well known > CAs to our > truststore. (Specifically adding the one that google is > using.) Aparently > it's already in default java trust store since everything > works if you run > your code outside of sipXconfig (to test my theory you can > just remove > truststore param - sipXconfig will use default, replication > will fail but > you'll be able to import addresses) Scott, Damian, thanks for the hints! It worked as Damian suggested - I removed the truststore param and successfully imported the gmail contacts fine. However, I am wondering how this will work in the real life (as suggested, adding google CA to our trustore would be an option). Should I file an issue for this and set it as a dependency to the one I am working on? Thanks, George _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
