Am 02.01.22 um 16:07 schrieb Matthias Andree: > 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
Aha - O.K. >> 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. Thank you - that is very helpful. > 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). Just for understanding - the installation is the public certificate of the server, or must be a special file derived from the private certificate? >> >> 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". Yes - but the connection was still encrypted and not plain text. The connection was just not secure against all forms of attacks. >> 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. O.K. But how this helps to connect to a server with self-signed certificates? >> 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. First you send your certificate to the public CA to sign it. Then an client must connect the CA to proove that the public certificate is correct signed. Correct or wrong? > It uses OpenSSL's unless you override that (see man fetchmail for > --ssl... options). I promise to take the time to learn this part about using OpenSSL. > 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. I only used this silly OpenSSL command to generate the self-signed certificate and filled the questions OpenSSL asked. It should not be much more complicate to use a local trust store. > Figuratively speaking, you need to learn how to fish, not be given the fish. Fishing get's more and more complex. But it's true and i must learn it. >> 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. That's the way i thought it is working. TLS is used to establish a secure encrypted connection and afterwards the rest is tunneled through it? Then it is not crucial how complex the protocol is. when two or more ports are needed then more secure connections must be established. > 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. I have to go through each different service that uses encryption, email, ftp, xmpp, etc. Maybe i will find a general better way to manage the certificates for encryption. Thank you for your invested time! karsten
