On Monday 23 Dec 2013 18:34:29 Marcus C. Gottwald wrote: > you wrote (Sun 2013-Dec-22 09:05:25 +0000): > > On Saturday 21 Dec 2013 20:50:39 Marcus C. Gottwald wrote:
> > 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. > > That appears to be the first half of the crux of the matter: Trusting > a self-signed certificate C has the effect of trusting every > certificate signed by certificate C. (The other half is that expired > certificates are still trusted as signing certificates.) The first half is to be expected. If a CA have been set as trusted by a receiving end, then any certificate signed by the same CA will also be deemed as trusted when received. The second half is questionable: normally, expired certificates will *not* be trusted. They ought to fail the openssl verification checks. > I verified that on a personal mail server: A newly generated self- > signed certificate created using "openssl req -x509 -key oldkey.pem > -out newcert.pem -days 123 -new" was immediately accepted by Mutt > which had a copy of an old certificate generated exactly the same > way (= same "oldkey.pem" file, same value for subject/issuer) in its > "mutt_certificates" file. The private key does not expire of course, but the certificate would. The modulus and public exponent between the two certificates (and private key) would be the same. You should be able to confirm this with: openssl x509 -noout -modulus -in cert.pem | openssl md5 openssl rsa -noout -modulus -in key.pem | openssl md5 Could it be that for some reason mutt only checks the modulus of any received certificates against any already accepted certificates (which if created by the same key they would have the same modulus), rather than perform the complete openssl verification, which would normally consider dates and other fields too? > > ... A quick check using openssl or gnutls will > > verify which certificate has been signed with what, before we drown in > > erroneous assumptions. > > Looking at a textual representation of the two certificates' field > values (using "openssl x509 -text"), I see differences in "Serial > Number", "Validity", "serial" field of "X509v3 Authority Key > Identifier", and the signature field. All other fields contain the > same values, notably "Issuer", "Subject", subject public key, and > "keyid" of "X509v3 Authority Key Identifier". We know that both > certificates are self-signed, so the identity of subject and issuer > must be machine-recognizable. > > Since the subject of the old certificate is purposely trusted as > the issuer of the new certificate, I guess the behaviour is to be > expected (ignoring the fact that the old certificate has expired). It is not just the subject field, but a number of additional verification tests which normally take place by openssl. Please have a look here, under "Verify Operation": http://www.openssl.org/docs/apps/verify.html > Let's assume that I don't trust any CA, told Mutt to not trust any > sytem-wide stuff, and only use the local "mutt_certificates" file. > But I presume that Mutt will always use the "mutt_certificates" file > in addition to the system-wide information, which would mean that > everybody should regularly check their "mutt_certificates" file for > expired certificates and remove them, right? > > > ... you should only include certificates that you trust in > > the ~.mutt/certificates store and make sure that you remove any which you > > don't. > > So there's the crucial point again: How do I tell Mutt to trust a > specific self-signed certificate for the purpose of authenticating > the subject it was issued for, but not for the purpose of verifying > another certificate? If the certificate in question has the corresponding X509v3 extensions and Basic Constraints corresponding to a CA, then you can't. It is a CA and any other certificate signed by it will be automatically accepted as trusted. However, I am puzzled that expired CA certificates are still accepted as valid Issuer authorities ... hmmm .... :-/ > I'll probably do this to avoid a cross-account authentication > weakness (when being presented a server certificate signed by a > certificate I only want to trust for the purpose of authenticating > a server, not for the purpose of signing other certificates); but > this will not help against a man-in-the-middle attack using a newly > generated self-signed certificate based on a no-longer-supposed-to- > be-used key which is trusted by Mutt because I once chose to trust > a self-signed certificate, which (may have expired a long time ago > but) is still present in "mutt_certificates". My point is that expired CA certificates should be removed from your "mutt_certificates", especially if as you observed their expiry alone is not a reason for failing SSL server verification tests. However this behaviour is at odd with my understanding of the verification tests that openssl performs. Just a thought: what version openssl are you using? Could it be that it is really old, or that it is configured to not perform full verification checks? > > 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... > > I'm not sure I understand that suggestion: How do I retrieve a > fingerprint of the Issuing Authority? I can fetch the whole > certificate, I can get a fingerprint of the whole certificate (which > differs from the old self-signed certificate to the new one), and > I can compare the certificates' contents as described above. Which > fields should I look at? Sorry, I didn't make myself clear - If the server is sending both a CA and server certificate chain then these two or more separate certificates in the chain would be returned when you try to login to the server with openssl s_client -showcerts. You can then separately examine their fingerprints and compare with whatever you may have in your local certificate store using: openssl x509 -in cert.pem -noout -fingerprint > Thanks again and happy holidays, > Marcus Happy Christmas to you and all mutters! :-) -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
