< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] TLS handshake failure


This is a part that may need some refactoring. Most clients that are phones
or softphones won't have a cert and won't do mutual TLS. However, some will
and proxy to proxy connection will often do mutual TLS and have one proxy
acting as the client.

The design idea was that when you create a TlsTransport, you say if it has a
certificate or not. If it does, then it should use it when acting as client
or server. If it does not, then it can only act as a client.

Not sure if the code does this or not.



On 5/4/05 8:55 AM, "Sandeep Sharma" <ssharma@xxxxxxxxxx> wrote:

> 
> I noticed that in TlsConnection.cxx there is code such as:
> 
>    if ( mServer )
>    {
>       assert( mSecurity );
> 
>       X509* cert =
> mSecurity->getDomainCert(mDomain); //mDomainCerts[mDomain];
>       if (!cert)
>       {
>          ErrLog(<< "Don't have certificate for domain " << mDomain );
>       }
> 
>       if( !SSL_use_certificate(mSsl, cert) )
>       {
>          throw Security::Exception("SSL_use_certificate failed",
>                                    __FILE__,__LINE__);
>       }
> 
>       EVP_PKEY* pKey =
> mSecurity->getDomainKey(mDomain); //mDomainPrivateKeys[mDomain];
>       if (!pKey)
>       {
>          ErrLog(<< "Don't have private key for domain " << mDomain );
>       }
>       if ( !SSL_use_PrivateKey(mSsl, pKey) )
>       {
>          throw Security::Exception("SSL_use_PrivateKey failed.",
>                                    __FILE__,__LINE__);
>       }
>    }
> 
> Why are SSL_use_certificate and SSL_use_PrivateKey only called for
> server? I think they should be called regardless. (even if we are acting
> as client).
> 
> Thoughts?
> 
> 
> 
> On Tue, 2005-05-03 at 15:06 -0600, Sandeep Sharma wrote:
>> Thanks for the information.
>> 
>> The code for a resip client verifying the server cert is in the function
>> computePeerName that is called after the SSL_do_handshake. My
>> application is failing in SSL_connect itself, so I think it is a issue
>> of not being able to find the cert issuer in the trusted list. This
>> statement is based on the fact that when I run openssl s_client I am
>> able to connect successfully (but I do see errors related to cert
>> verification - errors are in my initial post).
>> 
>> So I am trying to understand how the verification works. My machine has
>> a file called /usr/share/ssl/cert.pem that has 61 (CA) certs in it. 13
>> of these are from Verisign. I created 13 files with prefix root_cert_
>> under my application directory and the logs indicate that the preload
>> function is loading these certificates now.
>> 
>> I connect to the server and the server presents this certificate. (some
>> portions have been replaced with XXXX or ....)
>> 
>> Certificate:
>>     Data:
>>         Version: 3 (0x2)
>>         Serial Number:
>>             XXXX
>>         Signature Algorithm: sha1WithRSAEncryption
>>         Issuer: O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign
>> International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by
>> Ref. LIABILITY LTD.(c)97 VeriSign
>>         Validity
>>             Not Before: Dec  6 00:00:00 2004 GMT
>>             Not After : Dec  6 23:59:59 2006 GMT
>>         Subject: C=US, ST=Virginia, L=XXXX, O=XXXX, OU=XXXX, OU=Terms of
>> use at www.verisign.com/rpa (c)00, CN=XXXX
>>         Subject Public Key Info:
>>             Public Key Algorithm: rsaEncryption
>>             RSA Public Key: (2048 bit)
>>                 Modulus (2048 bit):
>>                     ....:
>>                     ....:
>>    ....:        
>>    ....:
>>                 Exponent: 65537 (0x10001)
>>         X509v3 extensions:
>>             X509v3 Basic Constraints:
>>                 CA:FALSE
>>             X509v3 Key Usage:
>>                 Digital Signature, Key Encipherment
>>             X509v3 CRL Distribution Points:
>> 
>> URI:http://crl.verisign.com/Class3InternationalServer.crl
>> 
>>             X509v3 Certificate Policies:
>>                 Policy: 2.16.840.1.113733.1.7.23.3
>>                   CPS: https://www.verisign.com/rpa
>> 
>>             X509v3 Extended Key Usage:
>>                 Netscape Server Gated Crypto, TLS Web Server
>> Authentication, TLS Web Client Authentication
>>             Authority Information Access:
>>                 OCSP - URI:http://ocsp.verisign.com
>> 
>>             1.3.6.1.5.5.7.1.12:
>>                 0_.].[0Y0W0U..image/gif0!
>> 0.0...+..............k...j.H.,{..0%.#http://logo.verisign.com/vslogo.gif
>>     Signature Algorithm: sha1WithRSAEncryption
>> ....:
>> ....:
>> ....:
>> ....:
>> 
>> What happens during verification? I am guessing something in this cert
>> should match one of the root certs for verification to succeed? What is
>> that bit? 
>> 
>> I even tried adding this to Security.cxx but it did not help.
>> SSL_CTX_set_options(mSslCtx, SSL_OP_ALL);
>> 
>> Another thing I noticed is that resip uses calls to X509_STORE*. I
>> looked at another SSL based app and it uses stuff like this:
>> SSL_CTX_set_client_CA_list();
>> SSL_CTX_load_verify_locations()
>> 
>> Are both of these approaches basically doing the same thing behind the
>> scenes? 
>> 
>> If anyone has successfully tested a scenario similar to what I described
>> above, please let me know.
>> 
>> FWIW, the other side is able to successfully establish a TLS connection
>> with my application and send in SIP messages. It is just not working
>> from me to them.
>> 
>> I am at my wit's end here. Any help, pointers are welcome.
>> 
>> Thanks
>> Sandeep
>> 
>> 
>> 
>> On Mon, 2005-05-02 at 17:22 -0700, Cullen Jennings wrote:
>>> Try and answer a few of your questions here - there should be better
>>> documentation on all of this ...
>>> 
>>> the root_cert* files are the certs for CA that you trust - so you would need
>>> to copy the versign cert to one of these.
>>> 
>>> The domain_cert are the things that are used for TLS  - so this would be
>>> your certificate for the serer.
>>> 
>>> The user_cers are only used for S/MIME and don't have anything to do with
>>> TLS 
>>> 
>>> Some of the code on a Resip client verifying the server cert has been
>>> changing and I'm a not up to date on it. It should be checking the
>>> SubjectAltName of the cert and that the date of the cert is valid. It is not
>>> checking CRL stuff.
>>> 
>>> 
>>> On 5/2/05 4:57 PM, "Sandeep Sharma" <ssharma@xxxxxxxxxx> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> I am looking for some help on how resiprocate validates/verifies server
>>>> certificates presented as part of TLS handshake.
>>>> 
>>>> The client is my application linked with resiprocate. The server is
>>>> another application that uses openssl.
>>>> 
>>>> The client tries to establish a TLS connection to server. On the client
>>>> (resip) side, following errors are seen..
>>>> 
>>>> TlsConnection.cxx:176 | TLS connection failed ok=-1 err=5
>>>> error:00000005:lib(0):func(0):DH lib
>>>> TlsConnection.cxx:196 |  (SSL Error want syscall)
>>>> TlsConnection.cxx:197 | Error may be because trying ssl connection to
>>>> tls server
>>>> TlsConnection.cxx:228 | Couldn't TLS connect
>>>> Write failed on socket: 18, closing connection
>>>> 
>>>> On server side, they report errors like this:
>>>> SSL3_GET_CLIENT_CERTIFICATE: peer did not return a certificate.
>>>> 
>>>> I CAN establish a connection using openssl s_client using -ssl2, so I
>>>> know that the server is SSL2 (not TLS). In my application, I am using
>>>> SSLv23 as the method. This also proves that the server has been
>>>> provisioned with my (client's) self signed cert.
>>>> 
>>>> I read that openssl s_client does server certificate verification but
>>>> still continues if the verification fails. But looks like resip stops if
>>>> the verification fails.
>>>> 
>>>> I looked back into the logs from openssl s_client and sure enough, there
>>>> were messages related to server certificate verification failure.
>>>> 
>>>> openssl s_client -connect server:port -verify 10 -cert cert.pem -key
>>>> key.pem -showcerts -debug -nbio_test -state -crlf -ssl2
>>>> 
>>>> verify error:num=20:unable to get local issuer certificate
>>>> verify return:1
>>>> verify error:num=27:certificate not trusted
>>>> verify return:1
>>>> verify error:num=21:unable to verify the first certificate
>>>> verify return:1
>>>> 
>>>> The server cert is issued by Verisign and the CN matches the machine
>>>> name that I am trying to connect to.
>>>> 
>>>> When I copy the server certificate on to my box and run openssl verify
>>>> on that cert, I get similar (not exactly same) errors.
>>>> 
>>>> I looked in resip code and found that there is some processing done with
>>>> files with prefix domain_cert_, user_cert_ and root_cert_ but did not
>>>> really understand what needs to be done.
>>>> 
>>>> So my specific questions are:
>>>> 
>>>> 1) How does resip verify server certs presented as part of TLS
>>>> handshake? Where does it look for trusted issuers?
>>>> 
>>>> 2) What is the difference between domain_cert_*.pem, user_cert_*.pem and
>>>> root_cert_*.pem? How are they used?
>>>> 
>>>> Any feedback, answers, suggestions and questions are welcome.
>>>> 
>>>> Thanks