Am 02.01.22 um 12:15 schrieb Matthias Andree: >> 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?
Do you want to help with this new certificate issue or discuss the ownership of domains? >> 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. I want to do this - what must be done? >> 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. When this method is "state of the art", why it is not explained somewhere? With the search "install OpenSSL trust store" i could find this article: https://support.code42.com/CP/Admin/On-premises/6/Configuring/Use_OpenSSL_to_install_a_keystore that explains much of the stuff, but not how to use an self-signed certificate. > The standard use case for fetchmail is to fetch mail from "big sites" > and those can be expected to handle proper certification chains. I agree - but is a private mail-server something that must be eliminated? > 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. This worked for more then 5 years with TLS1.2 without any problem. Why this must be a problem now? >>>> 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. Take the example Mozilla and please explain why it works without an "OpenSSL trust store" ? >> 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. O.K. Then you have no request to this CA-servers for every connect to a server with a certificate, but every private server is registered there and every client will request the "trust" once to access the server. So you can made a profil who is using a server. That's the simple goal of it. > https://manpages.debian.org/buster/ca-certificates/update-ca-certificates.8.en.html > might be a starting point. Thanks - but now i still have no idea where to search for the trust store of fetschmail? Why it is not possible to give the needed commands like before, like openssl req -x509 -newkey rsa:4096 -keyout /etc/exim4/exim.key.pem -out /etc/exim4/exim.cert.pem -days 365 -nodes ? The reason is the lack of understanding what has changed and what must be done and not to bother you. >> 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. When this is a standard procedure, why it is not possible to find existing examples how to handle it? Why it is still possible to fetch Data with TLS1.2 from the FTP-Server without similar problems? Thank you for your help - we are coming to an solution in little steps. Cheers karsten
