> It works if you use their root certificate instead > (AddTrustExternalCARoot.crt). PositiveSSLCA2.crt is just an > intermediate certificate. > > This is confusing and should really be simpler. Does anyone have a > good idea how we can simplify configuring a proper TLS/SSL setup? > > Currently the configuration work is only acceptable if the system > provides a default trust file that just works, such as > Debian's /etc/ssl/certs/ca-certificates.crt.
Wanted to say a few things on software, such as msmtp, that uses TLS... /etc/.../certs files... Yes, great for dumping this: https://mxr.mozilla.org/security/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1 with this... https://github.com/agl/extract-nss-root-certs.git into such files for a quick setup. Or get the equivalent data from your OS maker. However, you are then trusting every cert issuer out there. Which is very bad if you are at all security conscious.... there are MITM attacks and bad certs out there, etc... So software, such as msmtp, must have a way of specifying only the required certs and cert hashes per each expected TLS destination. Such software should be able to point the library at one file per destination containing only the certs required for that destination. If should also be able to specify the SHA1 hash for each required cert as additional protection against badness, change detection, etc. Minimally SHA1, but both SHA1 and MD5 would be nice. Both the file and hash config features should be usable separately and together per destination. Revocation checking (particularly external queries) should be optional, and if enabled, also allow for the same local file and hash check scheme. I would review how fetchmail, fdm, postfix, etc do things. Though I know at least fetchmail does not offer SHA1, leaving just MD5, which is broken and industry outdated. I'd bet GNUTLS and OpenSSL offer what is needed in their libraries. You can't eliminate the intermediate cert. In order for the server cert to validate, the full chain back to the self-signed root must exist. As to the OP case... the OP has set '--tls-certcheck=off', which is foolish security wise, but can be useful for testing. With it off, it should still check it and optionally issue a warning on check failure, but accept the TLS connection. With it on, it should abort the connection. OP did not specify whether 'off' results in an aborted connection, or just a log message. OP should load all needed certs for that destination in the specific tls_trust_file for that destination. That doesn't seem confusing, and is in the docs. If you really want security, it is necessary to validate both the server cert (hostname, cert chain, date, etc), and its fingerprint. Blindly trusting either could get you killed :) (Well, so could the lack of DNSSEC, IPSEC, and a web of trust rather than CA trust model to go along with that, but whatever.) The underscored, in particular, is bad handling... tls_fingerprint [fingerprint] This command sets or unsets the fingerprint of a particular TLS certificate. ______This certificate will then be trusted, regardless of its contents______. (no, also check cert if user requested) You can give either an SHA1 (recommended) _or_ an MD5 (and/or) The SHA3 contest will hopefully eliminate using the broken MD5 and shaky SHA1 hashes. Some people thus verify both. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ msmtp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msmtp-users
