Re: [reSIProcate] TLS handshake failure
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@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
--
Sandeep Sharma <ssharma@xxxxxxxxxx>
