>> I'm looking through the manual and I'm not seeing where I can: >> >> 1) Specify, in the fixed muttrc configuration, a sha1 certificate >> fingerprint that must match on a per host basis before continuing >> with the connection. > > This is not supported directly, but here is what you can do: > > $certificate_file contains the certs that you have accepted permanently via > the SSL/TLS dialog.
This would like to be a option for per host $certificate_file so rogue host cannot present any other cert that just happens to be in this bundled file leading to unwanted acceptance. > So if you verify the certificate fingerprint during the > initial connection, that cert will go into your certificate store. This would like to be a option for hardcoded FP in config per host so as not to risk human compare or 'y' typo error in GUI leading to unintended acceptance. Bonus here is that no $certificate_file for host certs is needed, or need be managed, it's just live FP comparison at that point. Backed secondarily with an optional [per host] chain check as below. Good user will set up config offline with openssl tools. > However, this will not prevent the cert chain from validating with a > *different* certificate. So if you need that feature, after you have > accepted the cert as described above, you want to make sure to prevent mutt > from using any other certs: > > unset ssl_ca_certificates_file > unset ssl_usesystemcerts > >> 2) Additionally, and optionally, validate the cert presented by any >> ssl/tls (or starttls upgraded) connection back to the respective >> root ca using a per host cert/bundle file linked to from a muttrc. > > You could do this probably with an account-hook and setting > $ssl_ca_certificates_file and ensuring that $ssl_usesystemcerts is unset. The 'per-host' basis is pretty important because you don't want a file full of host, intermediate, or CA cetificates to end up validating other hosts for which you mean to employ fully compartmented checking. Commonly as resistance to MITM, stolen certs, and CA's which aren't doing what people think they do. And the fingerprint is the critical item today for final and best control over actual security, not CA games. (Along with the needed secure DNS and transport tomorrow). I should say 'per-host' could just as better be 'per-account' as most mail setup is thought of as an on account basis. You might want to review some of the certificate checking and static configuration models in fetchmail, fdm, msmtp, mpop, etc. Particularly in regards to fingerprints, which are the most secure. Then as to storage of certs in separate files, or in bundles for the less concerned and convenience oriented. In the meantime, yes, I will go see further from the hints above how well Mutt can currently handle fingerprint checking and cert storage. The account_hook may help for some of these cases but enhancment would be needed to cover others. There is this for people to use as well... https://github.com/agl/extract-nss-root-certs
