3

I am writing an OpenSSL SSL enabled client application which connects to a Google server. I have the SSL working and I can monitor the traffic and see that it is definitely encrypted. I am using OpenSSL API function SSL_CTX_load_verify_locations to load a .pem file containing public root certificates to verify that the server is a trusted server...I think!?

I've done LOADS of searching but I can't find a simple description of what I'm meant to do to make sure I am talking to a Google server. Is using a .pem file with root CA's the correct thing to do? How do I know I'm talking to Google and not someone else on the trusted list?

Also, am I meant to distribute the .pem file along with the application, or can it be compiled into my application?

Any help greatly appreciated.

Improve this question

2 Answers 2

Reset to default
1

The way you check to see if a certificate is valid is by checking the certificate parameters (expiration, subject, etc.) and verifying that the certificate was signed by a trusted authority.

As far as what authority to trust for Google certificates, Google publishes a Frequently Asked Questions document here. If you follow their guidelines you should be fine.

Improve this answer
1
  • Thanks for the helpful information, and to Steffen Ullrich. How about the question regarding the .pem? It looks like OpenSSL only offers the abilty to load from a file... is that the correct/normal method?
    – LongTom
    Commented May 26, 2014 at 11:29
1

First, you have ask yourself if you trust all the 100s of CAs which are trusted by the browser, which each can sign a certificate for google and each can create sub-CAs which again have same possibilities etc. If you believe that this process is save look at the incidents with Comodo and DigiNotar in 2011.

If you want to be better you do certificate pinning, e.g. either save a fingerprint of the certificate itself or its public key and make sure this is what you get when you connect to the server.

And of course you should do the right certificate verification, e.g.:

  • lifetime (not_after, not_before)
  • verified path to a trusted root CA
  • check revocation of certificate and all sub-CA within the path to the root CA, either with current CRLs or with OCSP - and don't just ignore OCSP errors. OpenSSL can do this for CRL if you download the CRL yourself and it can help you with OCSP although there is no documented API
  • and don't forget to verify the hostname against CN or SAN section according to RFC2818 and RFC6125. There is no support with the currently released OpenSSL versions for this, so you have to do it by hand and don't make the same errors like lots of others did (like allowing multiple wildcards or wildcards not only in leftmost label)
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .