Re: [reSIProcate] TLS handshake failure
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>
