Am 01.01.22 um 14:26 schrieb Karsten:
Hello Matthias,
Am 01.01.22 um 14:10 schrieb Matthias Andree:
Notice something?
i notice everything. :-)
You hijack somebody else's domain for "anonymization" purposes and
expect someone to help you, and you did not respond to hints the server
CA's signing certificate might be missing from the trust store.
I am the owner of the domain so nobody is hijacked!
Are you the owner of "mydomain.de" or of the unnamed domain you intended
not to show to the public?
A self signing certificate is absolutely sufficient and perfect for private use.
Then install your own CA or (if marked as CA-suitable) issuer
certificate it into your fetchmail client's OpenSSL trust store, or a
separate location, and move on.
The same TLS1.2 as before shall be used, so it is not understandable why
addtional things are mandantory now?
Why old certificates cannot be used any more when the client that uses a server
is upgraded?
It is not about certificates, but - as László pointed out - about
repairing fetchmail's security requirements from substandard to "Stand
der Technik". fetchmail 6.4.0 made --sslcertck the default, as various
places of the documentation (man page, NEWS file) point out.
The standard use case for fetchmail is to fetch mail from "big sites"
and those can be expected to handle proper certification chains.
Your use case is "run my own TLS server"; in that case fetchmail can
safely assume people are aware what they are doing and how to handle trust.
In the Internet are a mass of similar problems with fetchmail, but no
description what exactly must be done to solve it.
Because "similar problems" are usually a broken setup of either
server-side certificates that don't trace back to commonly used and
trusted stores (Mozilla's trusted CA package, mostly), or local broken
setups.
This "stores" are a big problem of public monitoring, because every certificate causes
requests to this central "stores".
Untrue. Mozilla's certificates are installed for offline use by Debian,
Fedora, FreeBSD and derived distros under names such as ca-certificates,
ca_root_nss or similar. AFAICS and up to and including OpenSSL 3.0.0,
OpenSSL does not perform Online Certificate Status Protocol (OCSP)
polls, so no calling home involved to date.
https://manpages.debian.org/buster/ca-certificates/update-ca-certificates.8.en.html
might be a starting point.
But it would be helpful for others what must be done to create and install this new
"client side certificate" that
appears about 2018?
That's standard TLS library procedure and not specific to fetchmail. The
only specific part is that fetchmail uses OpenSSL, so your self-signing
server certificate belongs into OpenSSL's trust store, or you can use
one or both of the --sslcert* options to fetchmail.
