On Sat, Jul 07, 2012 at 01:25:49PM -0600, Daniel Kahn Gillmor wrote: > On 07/07/2012 12:50 PM, Ángel González wrote: > > On 06/07/12 01:01, pro...@secure-mail.biz wrote: > >> Because SSL CA's have failed many times (Comodo, DigiNotar, ...) I wish to > >> have an option to pin a SSL certificate. The fingerprint may be optionally > >> provided through a new option. > > Have you tried using --ca-certificate option? > > I believe the OP wants to pin the certificate of the remote server (that > is, the end entity certificate), whereas --ca-certificate pins the > certificate of the issuing authority. > Indeed? I thought the --ca-certificate just makes the certificate trustful, so declaring server certificate using --ca-certificate could be enought.
Though there can be problem with HTTP redirects and of course some picky TLS libraries can insist on CA=true X.509 attribute. Also some TLS implementations checks the server hostname against certificate name. So if the TLS library cannot be cheated with --ca-certificate option, overriding root of trust in other way is good idea. I'm just little worried about the digest algorithm. One can claim the MD5 is too weak. There have been real successfull attacks exploiting MD5 collisions of signed object in X.509 certificate. The ability to specify different alogrithm is necessary. Also remember the HTTP redirect scenario where you need to verify two (or more) servers. It's necessary to be able to supply more pinning options. Maybe option pinning certificate to hostname would be the best choice. No hashes. Just supply the peer certificate content like with --ca-certificate. E.g. `--peer-certificate example.com:/tmp/example.cert'. -- Petr
pgpsNRlttrc9I.pgp
Description: PGP signature
