Testing “dark” SSL Sites

Home » CentOS » Testing “dark” SSL Sites
CentOS 9 Comments

So, with all the hubbub around POODLE and ssl, we’re preparing a new load balancer using HAProxy.

So we have a set of unit tests written using PHPUnit, having trouble validating certificates. How do you test/validate an SSL cert for a prototype
“foo.com” server if it’s not actually active at the IP address that matches DNS for foo.com?

For non-ssl sites, I can specify the url like http://1.2.3.4/path and pass an explicit “host: foo.com” http header but that fails for SSL certificate validation.

You can also set a hosts file entry, but that’s also rather painful. Is there a better option?

9 thoughts on - Testing “dark” SSL Sites

  • I just disabled SSLv3 altogether on my server and just use TLS. On my site I only use TLS 1.2 and not earlier versions or SSL so I was never affected by POODLE.

  • openssl s_client -connect ip.ad.dr.ess:443
    then decode the cert

    e.g.
    $ openssl s_client -connect 1.2.3.4:443 < /dev/null >| cert

    Now you can use the “x509” to look at various things eg
    $ openssl x509 -in cert -subject -noout subject= /description=foobar/C=US/CN=ssl.example.com/emailAddress=foo@example.com

    “man x509”

  • The issue is that I wouldn’t consider myself qualified to make sense of this output. Curl noticed when an intermediate SSL cert wasn’t installed correctly, so if possible I’d really like to use a CLI “browser” such as curl or wget. I’ve already confirmed for example, that using openssl s_client as you mention above doesn’t actually check the certs, just lists them.

    Thus, the recent issues with firefox and intermediate certs would be tough to look for….

  • Actually it does check them as well.

    e.g.
    openssl s_client -connect localhost:443 < /dev/null > /dev/null
    depth=0 /C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=a.example.com/emailAddress=root@a.example.com
    verify error:num:self signed certificate
    verify return:1
    depth=0 /C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=a.example.com/emailAddress=root@a.example.com
    verify error:num:certificate has expired
    notAfter=Aug 9 23:55:39 2014 GMT
    verify return:1
    depth=0 /C=–/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=a.example.com/emailAddress=root@a.example.com
    notAfter=Aug 9 23:55:39 2014 GMT
    verify return:1
    DONE

    Notice the “verify error” lines; it’s both self-signed _and_ expired.

    In chained certs it’ll check each of the chains.

    e.g.
    openssl s_client -connect http://www.google.com:443 < /dev/null > /dev/null
    CONNECTED(00000003)
    depth=3 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
    verify return:1
    depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
    verify return:1
    depth=1 /C=US/O=Google Inc/CN=Google Internet Authority G2
    verify return:1
    depth=0 /C=US/ST

  • Maybe I did misunderstood, in which case ignore my post and/or remove it as it didn’t help.

  • I ended up discovering that curl recently added the option –resolve that allows me to do what I need. I had to download a statically compiled version and install in /usr/local to get it working on EL6.