Questions about self-signed Certificates' Fingerprints and Client-Server Interaction through SSL

Question

I have some questions about how the fingerprint function is performed. First of all, I have some knowledge about cryptography. However it seems to do not be good enough to understand hundreds of pages with vague or incomplete information.

Questions:

1. I am trying to know how to compare the fingerprint appeared when the Firefox warns about a self-signed certificate, showing the fingerprint in MD5 and SHA1.

   I am doing this because, in spite how beautiful and short they could seem, fingerprints really are not useful in all if you have the self-signed certificated (all the string) and not the fingerprint. Then, how can you know that such fingerprint shown by Firefox is that which matches the real fingerprint of your self-signed certificate?

   As far as I figured out, .crt file has the certificate (shown in base64).

   If, for example, I Export the Equifax Secure CA from Firefox's Certificate Manager, and I execute this command:

   $ openssl dgst -sha1 BuiltinObjectToken-EquifaxSecureCA.crt 
   SHA1(BuiltinObjectToken-EquifaxSecureCA.crt)=**e05110ddb9bcb9e47818ea6e955cc6ba78ec6627**
   
   $ openssl dgst -md5 BuiltinObjectToken-EquifaxSecureCA.crt     
   MD5(BuiltinObjectToken-EquifaxSecureCA.crt)=**54b6604a82d90ebdb9a8a3c544bb77f1**
   

   …there are shown the two fingerprints (SHA1 and MD5).

   However, when from the same Firefox client I select such Certificate, and click on 'View', what the Firefox's Certificate Manager shows this other two fingerprints:

   sha1: D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A
   
   md5: 67:CB:9D:C0:13:24:8A:82:9B:B2:17:1E:D1:1B:EC:D4
   

   

   Why are they so different?

2. Maybe this question will drive us to open another post. If that was the case, I would open a new post with so.

   If I understood correctly, the Certificate is the Public Key signed by someone (in this case by myself, and in other desired cases by a Certifying Authority) and adding some other functional and relevant data (such as domain-name, email-address, etc.).

   The Certificate is send by the Server to the Client (except those self-signed certificates pre-installed at the Client site, mainly from some sort of Certifying Authorities from the highest levels of the hierarchy).

   Then, my question. The fingerprint shown when some certificate is downloaded at the Client side from the Server: is this fingerprint the digest of the Public Key, or the digest of the Certificate itself?

3. The configuration of some Servers to allow Secure Connexions (those working over SSL: https, ftps, smtps, etc...), are including some directives at the SSL configuration to show to the Server which Files it shall use.

   For example, the Apache2 HTTPS Server could include these three directives:

   SSLCertificateFile - digital certificate (eg. your_domain_name.crt).
   SSLCertificateKeyFile - private key (eg. your_domain_name.key).
   SSLCertificateChainFile - intermediate (eg. DigiCertCA.crt), [OR  SSLCACertificateFile]
   

   To know the fingerprint that Firefox will show when the user is accessing this Server, on which files do I have to apply the commands shown at question 1 and obtain the fingerprints from? To the file specified at SSLCertificateFile, or to another file which only has the Public Key and is not included here?

4. Attending the above question. I am the administrator of that HTTPS Server with a self-signed Certificate, and I want to install to my Web Browser the Certificate, avoiding so to my Browser to download it (and in turn, avoiding any Main-In-The-Middle attack - some one giving me another Self-signed Certificate), which file do I have to 'Import' to my Web Browser? Is this last file generated by the Server or is directly the specified file at SSLCertificateFile directive?

   NOTE: I am asking this last question, because at the SSLCertificateFile directive, for example, you can specify a .pem file, instead of a .crt file. And the .pem file, as I checked in my own Web Server could contain the Private Key as well (something to do not be sent to the Web Browser). What, in fact, shows us that applying the fingerprint to the .pem file, the result would be different than such shown by the Web Browser, when it warns about a self-signed Certificate.

---

Thank you all of you!! and sorry for the long question, but I have found a lot of pages talking about the same information, infinite times, and no one has anything about this matter.

I feel this is an odd thing, since thousands of administrators are using cryptographic tools, and there is an important point that they do not discuss: the fingerprints. At the moment, I believe that when they see the warning of a self-signed certified, they simply accept the exception without checking anything. And I think so, because there are not information discussing this specific matter on the Internet (I think - an important one, if not the most).

Answer 1

1. The fingerprint of a certificate the digest of the binary certificate, i.e. DER/ASN.1 encoded. You use probably the PEM encoded form and because openssl dgst just uses whatever data you put in it will be different. To get the correct fingerprint:

   openssl x509 -in cert.crt -outform der | openssl dgst -sha1
   

2. The fingerprint of the certificate is shown in the browser for verification. Fingerprint of the public key is used in other places, i.e. chrome uses it for certificate pinning.

3. The fingerprint shown in the browser is the one for SSLCertificateFile, but again: you need to convert this file to DER before computing the fingerprint.

4. The browser has to know only the certificate for verification, not the private key. .pem is usually used for PEM encoded data, which does not say anything about whats inside these data (might be multiple certificates and public keys), while .der is used for DER encoded data. .crt on the other hand is used for certificates but says nothing about the format, but mostly PEM is used. All the file names are just conventions, at the end the server does not care about the extension and you can use any file you want.