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.
