Am 02.01.22 um 14:03 schrieb Karsten:
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?
In this case, the latter. There are dedicated domain names for everyone
to use for documentation and test purposes,
https://datatracker.ietf.org/doc/html/rfc6761#section-6.5
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.
https://unix.stackexchange.com/questions/90450/adding-a-self-signed-certificate-to-the-trusted-list/
but check the fine print and lower rated comments, too -- for recent
ca-certificates packages.
Basically you can install the self-signed certificate (if you or a
trusted party signed it, and you have transmitted it over a secure
channel, for instance, via SFTP or SCP) into the trust store (assuming
it suits both the TLS server and the signing CA roles - which was set
when you created it).
This worked for more then 5 years with TLS1.2 without any problem.
Why this must be a problem now?
Because "working" does not imply "working safely and securely".
Take the example Mozilla and please explain why it works without an "OpenSSL trust
store" ?
Mozilla applications ship with their own trust store and do not use
OpenSSL, but incorporate their own TLS library called NSS.
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.
No, where does that access happen? The trust store is local to your
computer and fetchmail might use your system's DNS resolver (which can
have privacy implications) and will connect to the servers you point it to.
Thanks - but now i still have no idea where to search for the trust store of
fetschmail?
It uses OpenSSL's unless you override that (see man fetchmail for
--ssl... options).
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.
I understand, but too many variables involved and neither of us has time
for guesswork. I don't know how your CA (even if only implied for that
certificate) is set up or whatever else is needed, and I don't intend to
do consulting.
Figuratively speaking, you need to learn how to fish, not be given the fish.
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?
fetchmail doesn't do FTP, and FTP is being phased out because it's hard
to get right with its two connections, active/passive mode,
firewalls/NAT/conntrack, TLS being added afterwards and I guess it was
superseded by many other protocols that either tunnel through SSH or use
one TLS connection, for instance, DAV.
It is probably not about TLS version numbers anyways, but generally
tightened security. You upgraded the entire client system, and that
brought a lot of changes.
https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
might also be involved.
