[reSIProcate] TLS handshake failure
Bob Bramwell
bob at jasomi.com
Wed May 18 19:16:25 CDT 2005
I haven't been following this discussion from the start, but it is ringing
really loud bells for me. Some time ago we had a rather similar discussion on
this list in which the following snippet appeared:
> Cullen Jennings wrote:
>
> On 10/22/04 5:51 PM, "Bob Bramwell" <bob at jasomi.com> wrote:
>
>
>> This note is part reality check and part change proposal. Your constructive
>> feedback will be most welcome.
>>
>> I am trying to set things up to allow TLS connections to do client
>> authentication. There are a number of things, notably in the Security class,
>> that will need to change to accomodate this.
>>
>> At present a Security object has two public certificates associated with it:
>> its publicCert and its publicIdentityCert. The former is used as the certificate
>> presented to a TLS client when it connects to a TlsConnection created in
>> server mode. The latter only appears to be used for signing stuff (computeIdentity
>> and checkIdentity functions). No provision is made for a client side certificate
>> per se.
>
>
> uhmm the PublicCert would be used for this
I remain convinced that there *are* scenarios where distinct client and server
certificates have to be presented. IMO there ought to be provision for this.
Presenting the server cert if no client cert were specified seems to be a
reasonable default position to take.
Hope that helps,
Bob.
Sandeep Sharma wrote:
> I do not think it was doing the correct thing. For a TlsTransport that
> was created with a domain, it was not presenting the right certificate
> when acting as a client.
>
> I changed some code in there so that the certificate and key are 'used'
> for a client and my TLS handshake issues are solved now.
>
> By the way, once resip establishes a TLS connection to a remote side,
> 1) How long is the connection kept around?
> 2) Under what conditions does resip disconnect?
> 3) Is it like: "Connect, Send SIP message, Disconnect" ?
>
> Thanks
>
>
> On Wed, 2005-05-04 at 09:16 -0700, Cullen Jennings wrote:
>
>>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 at jabber.com> 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 at jabber.com> 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
--
Bob Bramwell Jasomi Networks (Canada) | This space
Ph: 403 269 2938 x155 #310 602 11th Ave SW | intentionally
FX: 403 269 2993 Calgary, AB, T2R 1J8 | left blank.
More information about the resiprocate-devel
mailing list