0

I use getmail, a tool written in Python, to retrieve my mail via IMAP. Today it suddenly stopped working because it complains about an SSL fingerprint mismatch. (I always specify the fingerprint to check in getmail's configuration file, and I get this fingerprint from the OpenSSL command-line tool.)

According to the openssl command line below, my mail server's SSL certificate fingerprint is 393c7c58738fa6643cedd9943ffb6e951b2d3b576991d9671d86921ee79bb68a:

openssl s_client -connect onza.mythic-beasts.com:443 < /dev/null 2>/dev/null \
| openssl x509 -fingerprint -sha256 -noout -in /dev/stdin \
| cut -f2 -d= | tr -d : | tr '[:upper:]' '[:lower:]'

However, according to getmail and to the following simple Python fingerprint checker (which I essentially ripped out of the getmail source code), the certificate is actually 63d1c9e28c51aebd0c26463563be30e4df6814fa5406bab1787d1b9bdd19f15e.

#!/usr/bin/env python

import imaplib
import hashlib

conn = imaplib.IMAP4_SSL('onza.mythic-beasts.com')
sslobj = conn.ssl()
peercert = sslobj.getpeercert(True)
actual_hash = hashlib.sha256(peercert).hexdigest().lower()
print(actual_hash)
conn.logout()

I'm seeing the same results on a lot of different computers running different GNU/Linux distributions and connected to different networks.

Why are openssl and Python reporting different fingerprints for the same host? How do I know which one is correct? Is Python or OpenSSL perhaps caching an old copy of the certificate? If so, how do I clear the cache?

1 Answer 1

2

According to the openssl command line below, my mail server's SSL certificate fingerprint is 393c7c58738fa6643cedd9943ffb6e951b2d3b576991d9671d86921ee79bb68a:

openssl s_client -connect onza.mythic-beasts.com:443 < /dev/null 2>/dev/null \

You are using port 443 for checking the fingerprint. Port 443 is your web server (https) and not the mail server as you claim. The mail server is instead on port 993 (imaps). If you replace the onza.mythic-beasts.com:443 with onza.mythic-beasts.com:993 you'll get the fingerprint you've expected, i.e. 63d1c9e28c51aebd0c26463563be30e4df6814fa5406bab1787d1b9bdd19f15e.

1
  • Thanks! Evidently this was a stupid error on my part that I made many years ago. It had been working fine until now, presumably because my host had been using the same certificate for the web and IMAP services. Or maybe they still are, but they take a while to synchronize once a new certificate is deployed.
    – Psychonaut
    Commented Jul 9, 2018 at 8:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .