Scott Lawrence wrote:
> On Tue, 2009-10-20 at 15:59 -0700, George Niculae wrote:
>> Hello,
>>
>> I am working on XX-6247 (support uploading phonebook from gmail
>> address book) and I am facing the following problem: I've created a
>> client that connects to the gmail account and retrieves address book
>> contacts (using GData API). Everything works fine while running it
>> outside sipxconfig, however, when I am trying the same code within
>> sipxconfig (https) it fails with SSLHandshakeException:
>>
>> 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"
>>
>> I am thinking that this is due to invalid SSL certificate in my
>> sipxconfig but I don't know exactly how to work around this problem -
>> do I have to generate certificate and then have it signed by an
>> authorized CA? I have tried to generate valid SSL certificates using
>> gen-ssl-keys.sh 
>> and install them using install-cert.sh, but it didn't solve the
>> problem.
>>
>> Any suggestion is highly appreciated,
> 
> 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)

D.


_______________________________________________
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/

Reply via email to