Piper.guy1 wrote: > Hi, > > Please understand I'm a newbie to security if my question sounds > rather elementary. > > The embedded product I'm working on requires a secure connection to > our server that uses a Verisign certificate to authenticate. I've been > porting the OpenSSL examples from the O'Reilly publication so far and > I have been successfully able to make a secure encrypted connection > without authentication. (example client1.c). Our next step it to > implement authentication using a Verisign cert.
Usually, when people talk about "authentication", they mean the server authenticating the client. The client always makes sure it has reached the correct server. I presume, what you are talking about is the same check that every browser does. When you punch "https://www.amazon.com"; into your browser, your browser makes sure the server you reach presents a certificate for "www.amazon.com" that is signed by a CA your browser trusts -- and then it makes the server prove it knows the private key corresponding to the public key in that certificate. Is that all you're trying to do? > 3rd party CA's are talked about in the book very nicely but the focus > is on the server, and very little is discussed regarding what the > client needs to implement, unless I'm not reading in the right place, > or there's very little else for the client to do. > > It would seem that I would have to implement much of example > client2.c; or essentially call: > > 1. SSL_CTX_load_verify_locations() with the trusted certificates file Correct. And the trusted files should include the root certificates your client trusts. It must include the Verisign root certificate that your server's trust chain starts with (or ends with, depending on how you look at it). > 2. SSL_CTX_set_verify() with the SSL_VERIFY_PEER flag set > > Do I have to add anything else to the trusted certificates file or > will OpenSSL magically know to authenticate with Verisign? > > Is this all I need to do? The problem with this is it will wind up accepting any certificate whose trust chain's root is one of your trusted certificates, yours or not. The best solution to this problem is to confirm that the certificate presented has as its common name the name your client is trying to reach. This is precisely what a browser does. Again, using the "https://www.amazon.com"; example, OpenSSL takes care of getting the certificate from the server, making sure the certificate is valid, checking that the server owns the certificate, and making sure the certificate's trust chain has a root CA that is on your trusted list. However, www.badguys.com could also pass all those tests. So that leaves you to check the common name on the certificate and make sure it's the *right* name -- that is, the server you wanted to reach. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
