On Saturday 21 Dec 2013 20:50:39 Marcus C. Gottwald wrote: > Good morning! > > I am using Mutt (1.5.21 from Debian wheezy package 1.5.21-6.2+deb7u1) > to access an IMAP server using an "imaps"-URL. That particular server > is presenting a self-signed SSL certificate of which a copy is stored > in "~/.mutt_certificates". A while ago, the certificate expired and > Mutt started prompting me for "(r)eject, accept (o)nce" -- so far, so > good. > > The server admin generated a new self-signed certificate and installed > it, and what surprised me was that Mutt immediately accepted the > new certificate without prompting me. (I had expected to be asked > "(r)eject, accept (o)nce, (a)ccept always", verify the fingerprint, > then choose "a".) It took me a while to figure out that this behaviour > probably was to be expected, because the new certificate was issued > by the same issuer as the old certificate (same name, same key), and > Mutt trusts the old certificate (in local storage) for use as a CA > certificate.
As I understand it, this is only a partially correct assumption. Mutt will trust any certificates you have accepted by pressing (a). It will not automatically trust their CA, or any other certificates in their preceding chain of trust, unless you have separately accepted those too. If you had accepted the old CA then any new certificates signed by it would be automatically accepted too. A self-signed certificate is de facto a CA of itself. If it is used to sign another certificate then it becomes a CA of the other certificate too. For your scenario to be true the ISP would have to have used the old certificate which you had accepted already, as the CA for the new certificate. It is unlikely that he would have done this, if the old certificate had expired or was about to expire. A quick check using openssl or gnutls will verify which certificate has been signed with what, before we drown in erroneous assumptions. > However, I am now wondering whether the observed behaviour really is > intended. Let's assume that the server admin does generate a new key > for each new self-signed certificate and the old key is not supposed > to be ever used again. What happens if the old key gets stolen or lost > a few years later (think: hard drive with backup ends up on eBay)? > Anybody could generate a new self-signed certificate and become a > man-in-the-middle without me ever noticing. It depends on the "X509v3 Basic Constraints:" field in the certificate in question. If it says: "CA:FALSE" it will not be usable as a CA to sign other certificates with. If it says "CA:TRUE" then it is a self-signed certificate with the correct X509v3 Basic Constraints field to be used as a CA. Even *if* it says CA:TRUE, the stolen certificate would not be usable once it has expired. In addition, the (public) certificate itself is useless for this purpose, without it being accompanied with its (private) key. Of course, if the drive is stolen and the private key is kept in the same drive, the key could be used with the unexpired CA certificate to sign other certificates under the following scenarios: 1. The private key had not been encrypted. 2. The passphrase is cracked by brute force, or is known because the sysadmin left it unencrypted in the same drive - e.g. under "My Secrete passwords.txt" > Should I regularly remove all expired certificates from > "~/.mutt_certificates"? Should Mutt ignore all such certificates (or > prompt for acceptance each time such a certificate becomes part of a > verification chain)? As far as I know mutt does not use CRLs or OCSP to examine revoked certificates - but I could be wrong here. I do not know to what extent it uses openssl to undertake verification tests. If it only uses the local mutt certificates store to compare and contrast certificate validity, then any certificates that are no longer valid should be removed manually. > Assuming my understanding of the "accept locally stored certificates > as CA certificate"-feature is correct, a related question: Can I > ask Mutt to never accept a locally stored certificate as a signing > certificate? (I don't trust that server admin, but he could use the > self-signed certificate (which I have to trust) to issue a certificate > for some other subject, and Mutt would trust it, correct?) If I can't, > would my best choice currently be to only add certificates issued by > really trustworthy people to "~/.mutt_certificates", and to manually > verify the fingerprint on each other connection? (Hm, using a specific > "mutt_certificates" file per server would also help, I guess.) The purpose of certificates is to automate these checks of trust. I'm stating the obvious here, that you should only include certificates that you trust in the ~.mutt/certificates store and make sure that you remove any which you don't. You can use separate certificate stores for each of your imaps accounts, with: set certificate_file=/your_chosen_path_here/certificates I suggest that you use 'openssl s_client -showcerts' or equivalent to connect and check what each server is sending and manually compare the fingerprint of the Issuing Authority. For certificates already in your .mutt/certificates store you can check the same with, e.g.: openssl x509 -in your_cert.pem -text or if they are in a p12 bundle use: openssl pkcs12 -in your_cert.p12 info Hope this helps. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
