Hi Josh, I'm no SSL expert, just trying to shoot in the dark here. It may be caused by incomplete cert chain in the verification stage. A complete cert chain: root CA -> intermediate CA(s) -> your server cert. Perhaps you can try http://www.ssltool.com/?action=sslCheckOpenSSL to check if the server installation is fine. If it is, recheck your CA file (should contain the root CA cert). If not (server problem), you may need to put the intermediate CA cert(s) along with root CA in your CA file. BR, nanang On Thu, May 10, 2012 at 6:26 PM, Josh <area_51 at lavabit.com> wrote: > I have a particular problem I am hoping the list could shed a light on: I > have configured CA certificate and enforced server checks as well as > mandatory SRTP, but could not connect to my SIP provider over the main TLS > control channel. After doing a bit of digging into the code myself, I placed > the following marker in verify_cb (ssl_sock_ossl.c): > > err = X509_STORE_CTX_get_error(x509_ctx); > PJ_LOG(1,(ssock->pool->obj_name, "verify_cb: Error code is '%d'", err)); > > So, it turns out that during TLS negotiation X509_STORE_CTX_get_error > returns code 20 error, followed by multiple code 27 errors. The first one > corresponds to error in loading the actual certificate file and the second > error is that the certificate chain cannot be verified (this, I presume, > comes as a consequence of the CA certificate not being loaded). > > I have checked for the correct CA file path and file permissions and they > all seem OK, so I am a bit baffled what could be the underlying cause of > this? > > I did the following as a work-around: since there is no direct way to > download/store the server certificate (the one which is presented by my SIP > provider), I implemented such function in the same file (ssl_sock_ossl.c), > which stores that server certificate in a file as soon as TLS negotiation is > completed (I do this in "update_certs_info"). I then look at it (openssl > x509 does wonders for this type of operation) and when I decide that I can > trust this particular certificate I add it as an option for my "CA" > certificate and enforce the server check again. I then implemented my own > "verify_cb", which *matches* the certificate received from my provider with > the one I have "trusted" previously. This is how I get around the above > problem. > > This, obviously, is not ideal because when my provider's certificate > inevitably changes (before expiration date for example) I have to update my > "trusted" certificate as well, but certificate "matching" has its > advantages: tanstagi, for example, uses a made-up certificate (which also > has a made-up CA) and they, to my knowledge, don't provide CA certificates > (or any certificates for that matter), so by using my "matching" > implementation I get around this problem and have a reliable and trusted > connection. > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
