Re: [msmtp-users] Issue with certificate

[grarpamp <grarpamp@...20...>]

> 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.