Pinning SSL certificates / check SSL fingerprints

A great idea!

Feel free to join us on the curl-library list and help us write code to make this feature a reality!

Does this really buy you anything you wouldn't get by storing a copy of the certificate on the local machine and passing that in?

curl ---cacert pins the certificate authority, not the certificate.

You can not easily use the certificate locally. That would require a new feature, which I am requesting here.

You can also not easily run a local certificate authority. This is because you can not easily sign a certificate, if you do not have a certificate signing request.
"OpenSSL users mailing list: Sign public key without having CSR or private key?"
http://www.mail-archive.com/openssl-users@openssl.org/msg67968.html
http://www.mail-archive.com/openssl-users@openssl.org/msg67962.html

I haven't played with this much, but passing the certificate in with --cacert seemed to work for me on an OpenSSL-based curl.

As far I understand --cacert pins the SSL Certificate Authority. There is no option to pin the SSL Certificate directly.

If I am wrong,
1. please try to download a SSL certificate from a website
2. get it into curl usable form
3. deactivate systems ca-certificates (rename /usr/share/ca-certificates for testing)
4. use the --cacert option with the downloaded certificate

It didn't work for me. If it does for your, please document your steps. It's nowhere documented. I've been looking for this for some weeks already.

Here's a self-contained script using stunnel that works for me (using stunnel 4.53, OpenSSL 1.0.0d and curl 7.21.5 or git HEAD). The stunnel cert is self-signed so curl fails without the --cacert (or -k) option.

#!/bin/bash -x
python /usr/lib/python2.7/SimpleHTTPServer.py &
PYPID=$!
stunnel /dev/stdin << EOF
debug=6
foreground=no
pid=/tmp/s$$.pid
[http]
client=no
cert=/etc/pki/tls/certs/stunnel.pem
key=/etc/pki/tls/private/stunnel.pem
connect=8000
accept=8443
EOF
sleep 1
curl -v --cacert /etc/pki/tls/certs/stunnel.pem https://$(hostname):8443/
kill $PYPID
kill $(< /tmp/s$$.pid)

Ok, thank you very much, looks like this is becoming a documentation enhancement rather than a feature request.

For myself to remember or anyone else interested....

For testing we need a .pem. Go to [CAcert's root certificate download site](http://www.cacert.org/index.php?id=3) and download [Root Certificate (PEM Format)](http://www.cacert.org/certs/root.crt).

While testing *sudo mv /usr/share/ca-certificates /usr/share/ca-certificates_* was used.

Working:

curl --cacert ./root.crt https://www.cacert.org/ > cacert.html

Obviously failing:

curl https://www.cacert.org/ > cacert.html

And it obviously also fails, if something inside the certificate gets modified. Fine.

The only open question which remains is, how to get the .pem from any website?

Created a list with all required steps for SSL certificate pinning. From getting the certificate, converting into right format and using it with curl.

Link

Is there documentation available on what information you would like the certificate to be pinned on? For example:
- subject / issuer (hash)
- Expected public key
- Subject (hash) + serial nr + issuer (hash)

And does anybody have a good proposal on how to configure this? Easiest is to pass the certificate itself as input, but it partially defeats the point. :-)

Documentation:

As my Link states, curl supports already directly pinning the certificate. I didn't know and few people else did. This assumes it was manually downloaded. The part of manually downloading it was difficult. (The question was nowhere answered.) I just put together all the bits of information floating around on different websites.

If you like to have a look at my Link and to create a curl documentation chapter "Pin SSL certificate" or faq entry "How do I pin the SSL certificate for a website?", more people could know about it.

New code:

If you are willing to add new code to ease pinning of SSL certificates, why not use the (sha256/512) fingerprint of the certificate? It looks practical and secure. I could be wrong.

In comparison to validate a gpg key or otr key, we also use the fingerprint. I think it would be logical to extend that to ssl keys as well.