The OpenSSL library includes two very similar functions: int X509_digest( X509 *cert, const EVP_MD *digest, unsigned char *md, int *len);
int X509_pubkey_digest( const X509 *cert, const EVP_MD *type, unsigned char *md, int *len) The former generates the (raw binary form of) "fingerprint" of an X.509 certificate, which is printed in hex for example by $ openssl x509 -noout -fingerprint -<digest> The latter I had assumed for some time produces the corresponding public key fingerprint, but this turns out not to be case. Instead of producing the digest of the full key (algorithm, parameters and key data) as with: $ openssl x509 -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -<dgst> -c it produces a digest of just the key data. I believe this matches the digest used in constructing subject and authority key identifiers, (usually with the digest set to SHA-1). While this digest is thus potentially useful its security properties are entirely different from the similar X509_digest() function. The full certificate digest, with a suitably second-preimage resistant hash can be used a compact proxy for the full certificate, and some applications (e.g. RFC 6698 DANE TLSA) encourage or at least support the use of digests as secure replacements for the underlying certificate. The same can be said of the digest of the full public key (algorithm, parameters and key data), when one wants to trust the holder of the private key rather than any particular CA's name binding to that key. And indeed RFC 6698 also supports public-key fingerprint security bindings. In developing preliminary RFC 6698 support for Postfix, I was surprised to find that the X509_pubkey_digest() function was not the right tool. Instead I have to use: len = i2d_X509_PUBKEY(X509_get_X509_PUBKEY(peercert), NULL); buf2 = buf = OPENSSL_malloc(len); i2d_X509_PUBKEY(X509_get_X509_PUBKEY(peercert), (unsigned char **)&buf2); and then additional EVP functions to compute the digest of "buf" (can't use buf2 as this pointer is set to "buf + len" by i2d_X509_PUBKEY()). This is a rather non-obvious interface, and X509_get_X509_PUBKEY() is not documented. I'd like to request that the existing X509_pubkey_digest() be renamed to something like x509_pubkey_identifier() just for internal use by the library. At the same time, it would be very useful to have a manual page that describes X509_digest() and a new X509_pkey_digest() each of which produce intuitive results. The existing X509_pubkey_digest() can easily mislead even experienced OpenSSL users since key data that is safe for one algorithm and set of parameters may be entirely unsafe with another algorithm or set of parameters. -- Viktor. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org