Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #6350 > unrolled thread

Allgemeine Frage zur Annahme von Zertifikaten

Back to article view | Back to de.comm.software.mailserver

Contents

  Allgemeine Frage zur Annahme von Zertifikaten Edzard Egberts <news@edzeg.net> - 2021-04-15 13:46 +0200
    Re: Allgemeine Frage zur Annahme von Zertifikaten Tim Ritberg <tim@server.invalid> - 2021-04-15 16:00 +0200
      Re: Allgemeine Frage zur Annahme von Zertifikaten Edzard Egberts <news@edzeg.net> - 2021-04-15 16:47 +0200
        Re: Allgemeine Frage zur Annahme von Zertifikaten Tim Ritberg <tim@server.invalid> - 2021-04-15 18:12 +0200
          Re: Allgemeine Frage zur Annahme von Zertifikaten Thomas Hochstein <thh@thh.name> - 2021-04-15 18:18 +0200
        Re: Allgemeine Frage zur Annahme von Zertifikaten Thomas Hochstein <thh@thh.name> - 2021-04-15 18:16 +0200
          Re: Allgemeine Frage zur Annahme von Zertifikaten Edzard Egberts <news@edzeg.net> - 2021-04-16 09:13 +0200
          Re: Allgemeine Frage zur Annahme von Zertifikaten Edzard Egberts <news@edzeg.net> - 2021-04-16 11:17 +0200
        Re: Allgemeine Frage zur Annahme von Zertifikaten Andreas Metzler <ametzler@bebt.de> - 2021-04-15 18:37 +0200
        Re: Allgemeine Frage zur Annahme von Zertifikaten Arno Welzel <usenet@arnowelzel.de> - 2021-04-16 14:55 +0200
    Re: Allgemeine Frage zur Annahme von Zertifikaten Thomas Hochstein <thh@thh.name> - 2021-04-15 18:16 +0200
      Re: Allgemeine Frage zur Annahme von Zertifikaten Kay Martinen <usenet@martinen.de> - 2021-04-15 20:26 +0200
        Re: Allgemeine Frage zur Annahme von Zertifikaten Thomas Hochstein <thh@thh.name> - 2021-04-16 00:03 +0200
          Re: Allgemeine Frage zur Annahme von Zertifikaten Kay Martinen <usenet@martinen.de> - 2021-04-16 20:50 +0200
            Re: Allgemeine Frage zur Annahme von Zertifikaten Thomas Hochstein <thh@thh.name> - 2021-04-16 23:29 +0200
            Re: Allgemeine Frage zur Annahme von Zertifikaten Arno Welzel <usenet@arnowelzel.de> - 2021-04-17 20:59 +0200
            Re: Allgemeine Frage zur Annahme von Zertifikaten Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-18 08:17 +0000
              Re: Allgemeine Frage zur Annahme von Zertifikaten Thomas Hochstein <thh@thh.name> - 2021-04-18 13:32 +0200
                Re: Allgemeine Frage zur Annahme von Zertifikaten Paul Muster <exp-311221@news.muster.net> - 2021-04-18 14:35 +0200
                  Re: Allgemeine Frage zur Annahme von Zertifikaten Thomas Hochstein <thh@thh.name> - 2021-04-18 14:53 +0200
              Re: Allgemeine Frage zur Annahme von Zertifikaten Kay Martinen <usenet@martinen.de> - 2021-04-18 18:28 +0200
                Re: Allgemeine Frage zur Annahme von Zertifikaten Arno Welzel <usenet@arnowelzel.de> - 2021-04-19 13:55 +0200
                Re: Allgemeine Frage zur Annahme von Zertifikaten "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2021-04-19 14:57 +0200
              Re: Allgemeine Frage zur Annahme von Zertifikaten Arno Welzel <usenet@arnowelzel.de> - 2021-04-19 13:52 +0200
                Re: Allgemeine Frage zur Annahme von Zertifikaten Juergen Ilse <news@usenet-verwaltung.de> - 2021-04-19 12:34 +0000
                  Re: Allgemeine Frage zur Annahme von Zertifikaten Arno Welzel <usenet@arnowelzel.de> - 2021-04-21 20:13 +0200
                    Re: Allgemeine Frage zur Annahme von Zertifikaten Heiko Schlichting <heiko@cis.fu-berlin.de> - 2021-04-22 07:45 +0000
    Re: Allgemeine Frage zur Annahme von Zertifikaten Edzard Egberts <news@edzeg.net> - 2021-04-16 09:17 +0200
    Re: Allgemeine Frage zur Annahme von Zertifikaten Arno Welzel <usenet@arnowelzel.de> - 2021-04-16 14:50 +0200
      Re: Allgemeine Frage zur Annahme von Zertifikaten Edzard Egberts <news@edzeg.net> - 2021-04-16 15:04 +0200
        Re: Allgemeine Frage zur Annahme von Zertifikaten Arno Welzel <usenet@arnowelzel.de> - 2021-04-16 19:47 +0200
        Re: Allgemeine Frage zur Annahme von Zertifikaten Edzard Egberts <news@edzeg.net> - 2021-04-20 09:24 +0200
    [Off-Topic] Sternstunde des deutschen Usenet [War: Allgemeine Frage zur Annahme von Zertifikaten] Michael Uplawski <michael.uplawski@uplawski.eu> - 2021-04-19 07:47 +0200

Page 1 of 2  [1] 2  Next page →

#6350 — Allgemeine Frage zur Annahme von Zertifikaten

Diese Newsgroup könnte so mit Ach und Krach passen:

Es geht um Zertifikate (X509Certificate) bei der Verbindungsaufnahme mit 
einem Mailserver, POP3 und SMTP, mit einem eigenen Mailclienten (Poco). 
Wenn ein Socket die TLS-Verbindung aufnimmt, bekomme ich bei der 
Zertifikatsprüfung die Meldung "Invalid Certificate", "The certificate 
host names do not match the server host name", dann das Zertifikat 
bestätigen und es läuft. Dieses Verhalten ist unabhängig vom Provider.

Ich habe von der ganzen Materie kaum Ahnung, deshalb ein paar recht 
grundsätzliche Fragen:

* Was hat diese Meldung zu bedeuten, kann ich das ignorieren, oder muss 
ich ein Zertifikat mit dieser Meldung als ungültig einstufen?

* Was hat es mit den Cert-Stores (MS-Windows) auf sich? Mein Kollege 
meint, das wird alles automatisch getestet und das Zertifikat wäre eben 
fehlerhaft, das ist die Meldung vom automatischen Test. Ich frage mich 
dabei, ob ich das Zertifikat nicht selber irgendwo eintragen muss, weil 
ich mir unter "automatisch" vorstelle, dass ich das nur einmal 
bestätigen muss. Müsste der Mailclient ein bestätigtes Zertifikat nicht 
in den Cert-Store eintragen, oder wie geht das "automatisch"?

* Zertifikatsbestätigung ausschalten oder Zertifikat automatisch 
bestätigen ist also *nicht* mein Problem, sondern ich müsste wissen, wie 
das normalerweise abläuft (z.B. beim Thunderbird), so dass man eine 
korrekt bestätigte, sichere Verbindung benutzt, ohne jedes Mal das 
Zertifikat zu bestätigen.

[toc] | [next] | [standalone]

#6351

Am 15.04.21 um 13:46 schrieb Edzard Egberts:
> Diese Newsgroup könnte so mit Ach und Krach passen:
> 
> Es geht um Zertifikate (X509Certificate) bei der Verbindungsaufnahme mit 
> einem Mailserver, POP3 und SMTP, mit einem eigenen Mailclienten (Poco). 
> Wenn ein Socket die TLS-Verbindung aufnimmt, bekomme ich bei der 
> Zertifikatsprüfung die Meldung "Invalid Certificate", "The certificate 
> host names do not match the server host name", dann das Zertifikat 
> bestätigen und es läuft. Dieses Verhalten ist unabhängig vom Provider.
Das von dir genannte Verhalten sollte gar nicht auftreten.
Ordentliche (EU) Mailprovider haben gültige Zertifikate.

> 
> Ich habe von der ganzen Materie kaum Ahnung, deshalb ein paar recht 
> grundsätzliche Fragen:
> 
> * Was hat diese Meldung zu bedeuten, kann ich das ignorieren, oder muss 
> ich ein Zertifikat mit dieser Meldung als ungültig einstufen?
Bedeutet, die Verbindung ist wahrscheinlich unsicher und weitermachen 
wäre dumm.

> 
> * Was hat es mit den Cert-Stores (MS-Windows) auf sich? Mein Kollege 
> meint, das wird alles automatisch getestet und das Zertifikat wäre eben 
> fehlerhaft, das ist die Meldung vom automatischen Test. Ich frage mich 
> dabei, ob ich das Zertifikat nicht selber irgendwo eintragen muss, weil 
> ich mir unter "automatisch" vorstelle, dass ich das nur einmal 
> bestätigen muss. Müsste der Mailclient ein bestätigtes Zertifikat nicht 
> in den Cert-Store eintragen, oder wie geht das "automatisch"?
https://de.wikipedia.org/wiki/X.509

> 
> * Zertifikatsbestätigung ausschalten oder Zertifikat automatisch 
> bestätigen ist also *nicht* mein Problem, sondern ich müsste wissen, wie 
> das normalerweise abläuft (z.B. beim Thunderbird), so dass man eine 
> korrekt bestätigte, sichere Verbindung benutzt, ohne jedes Mal das 
> Zertifikat zu bestätigen.
Doch ist dein Problem, weil deine Daten. Schon das Benutzen eines 
"falschen" Hostnamens führt zu Zertifikats-Warnungen, auch wenn du mit 
dem richtigen System verbinden würdest. Z. B. mail.gmx.de, pop3.gmx.de 
oder post.gmx.com können schon auf das richtige System zeigen, aber das 
Zertifikat gibt es vielleicht nur für mail.gmx.de.

Tim

[toc] | [prev] | [next] | [standalone]

#6352

Am 15.04.21 um 16:00 schrieb Tim Ritberg:
> Am 15.04.21 um 13:46 schrieb Edzard Egberts:
>> "The certificate host names do not match the server host name"

> Das von dir genannte Verhalten sollte gar nicht auftreten.
> Ordentliche (EU) Mailprovider haben gültige Zertifikate.

Ich bin mir sicher, dass das Zertifikat in Ordnung ist und mit einem 
anderen Mailclienten erscheint diese Meldung ja auch nicht. Was macht 
der also besser, bzw. ich falsch?


> Doch ist dein Problem, weil deine Daten. Schon das Benutzen eines 
> "falschen" Hostnamens führt zu Zertifikats-Warnungen, auch wenn du mit 
> dem richtigen System verbinden würdest. Z. B. mail.gmx.de, pop3.gmx.de 
> oder post.gmx.com können schon auf das richtige System zeigen, aber das 
> Zertifikat gibt es vielleicht nur für mail.gmx.de.

Also eine Warnung - Warnungen kann man doch ignorieren, wenn man (im 
Gegensatz zu mir) weiß, was man macht.

Also ein Zertifikat sieht so aus:

"
Issuer Name:  /C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, 
Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure 
Certificate Authority - G2

Subject Name: /C=DE/ST=Nordrhein-Westfalen/L=Köln/O=Host Europe 
GmbH/CN=*.webpack.hosteurope.de

The certificate yielded the error: The certificate host names do not 
match the server host name

The error occurred in the certificate chain at position {Leerstring}
"

Verbindung will ich mit "wp#####.mail.server-he.de" aufnehmen (### ist 
eine Kontonummer) und bekomme dann wohl den Fehler, weil 
"webpack.hosteuroe.de" nicht der gleiche Name wie "mail.server-he.de" ist?

Ein weiteres Zertifikat sieht so aus:

"
Issuer Name:  /C=US/O=Google Trust Services/CN=GTS CA 1O1

Subject Name: /C=US/ST=California/L=Mountain View/O=Google 
LLC/CN=pop.gmail.com

The certificate yielded the error: The certificate host names do not 
match the server host name

The error occurred in the certificate chain at position {Leerstring}
"

Da nehme ich aber wirklich eine Verbindung mit "pop.gmail.com" auf, 
warum bekomme ich denn trotzdem diesen Fehler?

Gibt es irgendwelche Möglichkeiten das einzustellen? Ich kann einen 
Certstore konfigureren (z.B. My, Root, Trust) und sogar eine 
Zertifikatsdatei angeben. Ich denke mir, das muss für etwas gut sein, 
aber ich weiß nicht so wirklich wofür. Wenn ich das Zertifikat irgendwo 
als "vertrauenswürdig" speichere, stimmt der Hostname ja immer noch 
nicht, wie wird so etwas denn gemacht? Also wenn ich dem Mailclienten 
sagen will "das stimmt schon, Zertifikat verwenden", muss ich das von 
Hand in meine Prüfung einbauen, oder gibt es da eine übliche Vorgehensweise?

[toc] | [prev] | [next] | [standalone]

#6353

Am 15.04.21 um 16:47 schrieb Edzard Egberts:

> 
> Verbindung will ich mit "wp#####.mail.server-he.de" aufnehmen (### ist 
> eine Kontonummer) und bekomme dann wohl den Fehler, weil 
> "webpack.hosteuroe.de" nicht der gleiche Name wie "mail.server-he.de" ist?
RTFM;
https://www.hosteurope.de/faq/webhosting/sicherheit-ssl/ssl-zertifikate-webhosting-bereich/


> 
> blablablabla
Ich hab dir nicht umsonst den Link zu Wikipedia gegeben!

Tim

[toc] | [prev] | [next] | [standalone]

#6356

Tim Ritberg schrieb:

> Am 15.04.21 um 16:47 schrieb Edzard Egberts:
> > Verbindung will ich mit "wp#####.mail.server-he.de" aufnehmen (### ist 
> > eine Kontonummer) und bekomme dann wohl den Fehler, weil 
> > "webpack.hosteuroe.de" nicht der gleiche Name wie "mail.server-he.de" ist?
> RTFM;
> https://www.hosteurope.de/faq/webhosting/sicherheit-ssl/ssl-zertifikate-webhosting-bereich/

Das löst, soweit ersichtlich, nicht sein Problem: er verwendet den
vorgesehenen Hostnamen, der Client bemängelt nicht ein fehlendes
(Root-)Zertifikat, sondern einen unpassenden Hostnamen, aber das
Zertifikat hat einen Wildcard-Eintrag als SAN für den Hostnamen, den
er verwendet.

-thh

[toc] | [prev] | [next] | [standalone]

#6354

Edzard Egberts schrieb:

[...]
> Subject Name: /C=DE/ST=Nordrhein-Westfalen/L=Köln/O=Host Europe 
> GmbH/CN=*.webpack.hosteurope.de
[...]
> Verbindung will ich mit "wp#####.mail.server-he.de" aufnehmen (### ist 
> eine Kontonummer) und bekomme dann wohl den Fehler, weil 
> "webpack.hosteuroe.de" nicht der gleiche Name wie "mail.server-he.de" ist?

Korrekt. Das wäre Murx. Allerdings enthält das Zertifikat aller
Voraussicht nach "Subject Alternative Names", darunter auch die
passenden. Für "wp1190649.mailout.server-he.de" (das fiel bei Google
als gültige URL raus) sieht das so aus:
| Subject: C = DE, ST = Nordrhein-Westfalen, L = K\C3\B6ln, O = Host Europe GmbH, CN = *.webpack.hosteurope.de
aber eben auch:
| X509v3 Subject Alternative Name: 
| DNS:*.webpack.hosteurope.de, DNS:webpack.hosteurope.de, DNS:*.mail.server-he.ch, DNS:*.mailout.server-he.ch, DNS:*.mail.server-he.de, DNS:*.ftp.server-he.de, DNS:*.storage.hosteurope.de, DNS:*.server-he.ch, DNS:*.ftp.server-he.ch, DNS:*.mywebdav.de, DNS:*.mailout.server-he.de, DNS:*.server-he.de

Das Zertifikat deckt also auch "*.mail.server-he.de" ab. Vermutlich
kann Poco schlicht nicht mit SANs umgehen.

> Da nehme ich aber wirklich eine Verbindung mit "pop.gmail.com" auf, 
> warum bekomme ich denn trotzdem diesen Fehler?

Vermutlich ist da was bei Dir kaputt[tm].

-thh
-- 
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>

[toc] | [prev] | [next] | [standalone]

#6360

Am 15.04.21 um 18:16 schrieb Thomas Hochstein:
> Edzard Egberts schrieb:
> 
> [...]
>> Subject Name: /C=DE/ST=Nordrhein-Westfalen/L=Köln/O=Host Europe
>> GmbH/CN=*.webpack.hosteurope.de
> [...]
>> Verbindung will ich mit "wp#####.mail.server-he.de" aufnehmen (### ist
>> eine Kontonummer) und bekomme dann wohl den Fehler, weil
>> "webpack.hosteuroe.de" nicht der gleiche Name wie "mail.server-he.de" ist?
> 
> Korrekt. Das wäre Murx. Allerdings enthält das Zertifikat aller
> Voraussicht nach "Subject Alternative Names", darunter auch die
> passenden. Für "wp1190649.mailout.server-he.de" (das fiel bei Google
> als gültige URL raus) sieht das so aus:
> | Subject: C = DE, ST = Nordrhein-Westfalen, L = K\C3\B6ln, O = Host Europe GmbH, CN = *.webpack.hosteurope.de
> aber eben auch:
> | X509v3 Subject Alternative Name:
> | DNS:*.webpack.hosteurope.de, DNS:webpack.hosteurope.de, DNS:*.mail.server-he.ch, DNS:*.mailout.server-he.ch, DNS:*.mail.server-he.de, DNS:*.ftp.server-he.de, DNS:*.storage.hosteurope.de, DNS:*.server-he.ch, DNS:*.ftp.server-he.ch, DNS:*.mywebdav.de, DNS:*.mailout.server-he.de, DNS:*.server-he.de
> 
> Das Zertifikat deckt also auch "*.mail.server-he.de" ab. Vermutlich
> kann Poco schlicht nicht mit SANs umgehen.

Danke, das mit dem Alternative Name ist eine ganz heiße Spur, darüber 
könnte ich eine erweiterte Prüfung zusammenbasteln und auch im Poco-Code 
mal nachschauen.

 > Vermutlich ist da was bei Dir kaputt[tm].

Ja, das habe ich mir auch gedacht, nur war das wie bei einem Auto, das 
nicht fährt - hat es bloß kein Benzin, oder ist der Motor explodiert - 
mir war das nicht klar! ;o)

Sorry übrigens, habe mich verklickt, per Mail sollte das nicht herausgehen.

[toc] | [prev] | [next] | [standalone]

#6362

Am 15.04.21 um 18:16 schrieb Thomas Hochstein:
> Edzard Egberts schrieb:
>> Da nehme ich aber wirklich eine Verbindung mit "pop.gmail.com" auf,
>> warum bekomme ich denn trotzdem diesen Fehler?
> 
> Vermutlich ist da was bei Dir kaputt[tm].

Also wenn man weiß, worauf man achten muss:

Die Poco-Klasse für das X509Certificate hat eine Methode 
verify(hostName) mit der der Hostname geprüft wird. Beim aktuellen Debug 
ist der hostName "10.0.2.15" (LOL!) und wenn ich im davon ausgelösten 
Fehler-Callback das verify mit einem Hostnamen wie "pop.gmail.com" 
aufrufe, bekomme ich ein true für "Verify Okay".

Das Problem ist also gelöst, auch ohne die Poco-Lib zu fixen muss ich 
nur im Callback noch einmal ein verify() mit dem bekannten Hostnamen 
probieren und weiß dann, ob ich das Zertifikat "automatisch" bestätigen 
kann, oder die Verbindung ablehnen muss.

[toc] | [prev] | [next] | [standalone]

#6357

Edzard Egberts <news@edzeg.net> wrote:
[...]
> Ein weiteres Zertifikat sieht so aus:

> "
> Issuer Name:  /C=US/O=Google Trust Services/CN=GTS CA 1O1

> Subject Name: /C=US/ST=California/L=Mountain View/O=Google 
> LLC/CN=pop.gmail.com

> The certificate yielded the error: The certificate host names do not 
> match the server host name

> The error occurred in the certificate chain at position {Leerstring}
> "

> Da nehme ich aber wirklich eine Verbindung mit "pop.gmail.com" auf, 
> warum bekomme ich denn trotzdem diesen Fehler?

Hallo,

Das muss dann wohl am Programm liegen. pop.gmail.com präsentiert auf
Port 995 (pop3s) in der Tat ein korrektes, zum Server passendes
Zertifikat, welches von einer üblicherweise akzeptierten CA ausgestellt
ist.

Da das fragliche Programm kein Mailserver ist, würde ich den Thread
hier schliessen.  Eventuell kann der Herstellersupport helfe.

lg Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[toc] | [prev] | [next] | [standalone]

#6364

Edzard Egberts:

[...]
> Verbindung will ich mit "wp#####.mail.server-he.de" aufnehmen (### ist 
> eine Kontonummer) und bekomme dann wohl den Fehler, weil 
> "webpack.hosteuroe.de" nicht der gleiche Name wie "mail.server-he.de" ist?

Korrekt. Frage Hosteurope, welchen Server Du verwenden sollst oder schau
in deren Dokumentation nach. Üblicherweise ist das
wpXXXX.webpack.hosteurope.de, wobei XXXX eine dreistellige Zahl ist.

> Ein weiteres Zertifikat sieht so aus:
> 
> "
> Issuer Name:  /C=US/O=Google Trust Services/CN=GTS CA 1O1
> 
> Subject Name: /C=US/ST=California/L=Mountain View/O=Google 
> LLC/CN=pop.gmail.com
> 
> The certificate yielded the error: The certificate host names do not 
> match the server host name
> 
> The error occurred in the certificate chain at position {Leerstring}
> "
> 
> Da nehme ich aber wirklich eine Verbindung mit "pop.gmail.com" auf, 
> warum bekomme ich denn trotzdem diesen Fehler?

Weil die Zertifikatskette (certificate chain) unvollständig ist. Hier
würde ich Google fragen, was bei denen kaputt ist.

Für den Zugang per IMAP mit imap.gmail.com gibt es aktuell keine Probleme.

> Gibt es irgendwelche Möglichkeiten das einzustellen? Ich kann einen 
> Certstore konfigureren (z.B. My, Root, Trust) und sogar eine 

Nein.



-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6355

Edzard Egberts schrieb:

> Es geht um Zertifikate (X509Certificate) bei der Verbindungsaufnahme mit 
> einem Mailserver, POP3 und SMTP, mit einem eigenen Mailclienten (Poco). 
> Wenn ein Socket die TLS-Verbindung aufnimmt, bekomme ich bei der 
> Zertifikatsprüfung die Meldung "Invalid Certificate", "The certificate 
> host names do not match the server host name", dann das Zertifikat 
> bestätigen und es läuft. Dieses Verhalten ist unabhängig vom Provider.

Wohl nur, wenn alle Provider eigenartige Konfigurationen fahren (oder
Poco sich eigenartig verhält).

> * Was hat diese Meldung zu bedeuten,

Poco verbindet sich mit mail.example.com, das Zertifikat ist aber
nicht für mail.example.com ausgestellt (sondern vielleicht für
mail01.example.com oder auch für einen ganz anderen Host).

> kann ich das ignorieren, oder muss 
> ich ein Zertifikat mit dieser Meldung als ungültig einstufen?

Das Zertifikat passt nicht zum Host. Das bedeutet entweder Böses, dass
Du nämlich in Wahrheit gar nicht mit dem Mailserver verbunden bist,
mit dem Du verbunden zu sein glaubst, oder - in der ganz weit
überwiegenden Mehrzahl der Fälle - dass eine Fehlkonfiguration
vorliegt, weil der Server unter einem Hostnamen erreichbar ist, den
das Zertifikat nicht abdeckt. Das kann zum Beispiel passieren, wenn
hinter dem Hostnamen "mail.example.com" nicht nur ein Server, sondern
viele stehen, die natürlich jeder auch einen eigenen Namen haben, und
deren Zertifikat nur auf diesen Namen ausgestellt ist.

> * Was hat es mit den Cert-Stores (MS-Windows) auf sich?

Da finden sich Zertifikate, die entweder Microsoft oder Du für
vertrauenswürdig hältst. Das können entweder spezifische Zertifikate
für einen Host sein, oder - regelmäßig - Zertifikate von
Zertifizierungsstellen, die dann die Zertifikate für spezifische Hosts
zertifizieren.

> Ich frage mich 
> dabei, ob ich das Zertifikat nicht selber irgendwo eintragen muss, weil 
> ich mir unter "automatisch" vorstelle, dass ich das nur einmal 
> bestätigen muss. Müsste der Mailclient ein bestätigtes Zertifikat nicht 
> in den Cert-Store eintragen, oder wie geht das "automatisch"?

Das kannst Du natürlich tun, aber Du weisst doch gar nicht, ob Du
wirklich (!) mit dem Mailserver verbunden bist, mit dem Du verbunden
zu sein glaubst, und ob das Zertifikat dementsprechend "echt" ist oder
nicht.

Letztlich soll TLS ja zwei Zwecke erfüllen: zum einen die Verbindung
zwischen Dir und der Gegenstelle (dem Mailserver) verschlüsseln, damit
der Datenverkehr nicht mitgelesen werden kann, zum anderen aber auch
sicherstellen, dass Du überhaupt mit der richtigen Gegenstelle
verbunden bist (und niemand die Verbindung "gekapert" hat, bspw. durch
Manipulation am DNS). Wenn es Dir nur um ersteres geht, dann kannst Du
die Zertifikatsprüfung abschalten oder ignorieren, wenn Dein Client
das unterstützt; ob es klug ist, ein unbekanntes Zertifikat in den
Cert-Store aufzunehmen, ist eine andere Frage - vielleicht hat der
Aussteller es ja auch für *.google.com oder für den Hostname Deiner
Bank ausgestellt?

Wenn Du ein Zertifikat prüfen willst (also zum zweiten vorstehend
genannten Zweck, der Prüfung, ob Du mit dem richtigen Host verbunden
bist), kann und wird zunächst geprüft, ob das Zertifikat zeitlich
gesehen gültig ist (also schon gültig und noch nicht abgelaufen) und
ob es überhaupt für den Hostname ausgestellt ist, mit dem Du verbunden
zu sein glaubst. Natürlich kann aber jeder Zertifikate für beliebige
Hosts ausstellen; deshalb wird als drittes geprüft, ob das Zertifikat
von einer Zertifizierungsstelle signiert ist, der "Du" vertraust,
deren Zertifikat sich also im Cert-Store findet. (In der Regel finden
sich da genau die Zertifikate, die andere für vertrauenswürdig halten,
die also dort ausgeliefert werden.) Aufgabe der Zertifizierungsstellen
ist es, sich zu versichern, dass derjenige, der sein Zertifikat
signiert haben möchte, befugt ist, ein Zertifikat für diesen Hostnamen
zu erhalten, also der Berechtigte ist. Das funktioniert mal mehr, mal
weniger gut. Funktioniert es oft genug weniger gut, wird man der
Zertifizierungsstelle das Vertrauen entziehen, und dann fliegt deren
Zertifikat aus dem Cert-Store.

> * Zertifikatsbestätigung ausschalten oder Zertifikat automatisch 
> bestätigen ist also *nicht* mein Problem, sondern ich müsste wissen, wie 
> das normalerweise abläuft (z.B. beim Thunderbird), so dass man eine 
> korrekt bestätigte, sichere Verbindung benutzt, ohne jedes Mal das 
> Zertifikat zu bestätigen.

Es ist Aufgabe des Serverbetreibers, dafür zu sorgen, dass das
verwendete Zertifikat

- für alle Hostnamen gültig ist, unter denen der Host angesprochen
werden kann (also bspw. sowohl für mail.example.com als auch
smtp.example.com, pop3.example.com, imap.example.com und
mailhost1234.example.com),

- nicht abgelaufen ist und

- von einer Zertifizierungsstelle signiert ist, der in der Breite
vertraut wird.

Tut er das, musst Du gar nichts tun; das Zertifikat wird einfach
akzeptiert. Das ist bei TLS-Zertifikaten für Webseiten eigentlich der
Regelfall; darauf wird geachtet. Niemand möchte, dass beim Kunden
jedesmal Alarmmeldungen im Browser erscheinen, wenn er die seite
aufruft.

Für andere Protokolle (Mail, ...) wird da nach meiner Erfahrung oft
weniger Sorgfalt drauf verwendet. Da passt gerne mal der Hostname
nicht, oder das Zertifikat ist vom Aussteller selbst oder von einer
nicht bekannten Zertifizierungsstelle signiert. Es erfüllt dann weder
den Zweck, eine verschlüsselte Verbindung zu ermöglichen, kann dann
aber nicht den weiteren Zweck erfüllen, die Authentität der
Gegenstelle zu bestätigen. In dem Fall kannst Du dann die
Zertifikatsbestätigung ausschalten; das ist in der Regel ein
brauchbarer Weg. Du könntest das Zertifikat natürlich auch selbst als
gültig akzeptieren und in den Cert-Store aufnehmen, aber wenn Du nicht
genau geprüft hast, für welche Hostnamen dieses Zertifikat gilt, kann
man Dir auf diesem Wege etwas unterschieben. Letzteres ist daher in
der Regel keine kluge Idee.

-thh
-- 
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>

[toc] | [prev] | [next] | [standalone]

#6358

Am 15.04.21 um 18:16 schrieb Thomas Hochstein:
> Edzard Egberts schrieb:
> 
>> Es geht um Zertifikate (X509Certificate) bei der Verbindungsaufnahme mit 
>> einem Mailserver, POP3 und SMTP, mit einem eigenen Mailclienten (Poco). 

>>  Meldung "Invalid Certificate", "The certificate 
>> host names do not match the server host name", 

> Wohl nur, wenn alle Provider eigenartige Konfigurationen fahren (oder

Vielleicht nicht alle. Aber viele hosten auf einem Server evtl. viele
domains (mail u.a.)

> Das Zertifikat passt nicht zum Host. Das bedeutet entweder Böses, dass

> überwiegenden Mehrzahl der Fälle - dass eine Fehlkonfiguration
> vorliegt, weil der Server unter einem Hostnamen erreichbar ist, den
> das Zertifikat nicht abdeckt. Das kann zum Beispiel passieren, wenn
> hinter dem Hostnamen "mail.example.com" nicht nur ein Server, sondern
> viele stehen, die natürlich jeder auch einen eigenen Namen haben, und
> deren Zertifikat nur auf diesen Namen ausgestellt ist.

Oder man hat einen Sparhoster der unter *.hosterdomain.net die
Zertifikate ausstellt und dem MUA diese anbietet für mailkonten die
unter meinedomain.de laufen. Auf den die aber nur durch einen CNAME
kommen der smtp.meinedomain.de auf mxblabla.hosterdomain.net lenkt.

Und was bleibt einem dann übrig wenn man den Provider nicht wechseln
will? Zertifikat händisch prüfen und als ausnahme speichern. Oder?

> Letztlich soll TLS ja zwei Zwecke erfüllen: zum einen die Verbindung
> zwischen Dir und der Gegenstelle (dem Mailserver) verschlüsseln, damit
> der Datenverkehr nicht mitgelesen werden kann, zum anderen aber auch
> sicherstellen, dass Du überhaupt mit der richtigen Gegenstelle
> verbunden bist (und niemand die Verbindung "gekapert" hat, bspw. durch
> Manipulation am DNS). Wenn es Dir nur um ersteres geht, dann kannst Du

Hä. ;-) ist ein CNAME auf einen MX schon eine Manipulation oder nur
übliche Praxis - bei hostern? Die hier die Verschlüsselung bricht?
Blöder wäre da wohl das ein PTR nicht auf den CNAME sondern den A Record
des MX verweist. Was dann vermutlich wieder einen Zertifikats- oder
Mailer-fehler wirft.

Falls ein Interner MTA mit so einem Externen MTA verschlüsselt reden
will. An der stelle hakts bei mir dann auch mit dem Verständnis aus.

> die Zertifikatsprüfung abschalten oder ignorieren, wenn Dein Client
> das unterstützt; ob es klug ist, ein unbekanntes Zertifikat in den
> Cert-Store aufzunehmen, ist eine andere Frage - vielleicht hat der
> Aussteller es ja auch für *.google.com oder für den Hostname Deiner
> Bank ausgestellt?

Ich weiß nicht wie mein MUA mit einer Zertifikats-ausnahme umgeht. Ich
würde gern glauben das er dann immer noch die domain prüft. Und wenn er
blabla.de erreichen will und bekommt antworten von google.com würde ich
eine Warnmeldung erwarten.

> - für alle Hostnamen gültig ist, unter denen der Host angesprochen
> werden kann (also bspw. sowohl für mail.example.com als auch
> smtp.example.com, pop3.example.com, imap.example.com und
> mailhost1234.example.com),

> Tut er das, musst Du gar nichts tun; das Zertifikat wird einfach
> akzeptiert. Das ist bei TLS-Zertifikaten für Webseiten eigentlich der
> Regelfall; darauf wird geachtet. Niemand möchte, dass beim Kunden
> jedesmal Alarmmeldungen im Browser erscheinen, wenn er die seite
> aufruft.
> 
> Für andere Protokolle (Mail, ...) wird da nach meiner Erfahrung oft
> weniger Sorgfalt drauf verwendet. Da passt gerne mal der Hostname
> nicht, oder das Zertifikat ist vom Aussteller selbst oder von einer

S.o. Mein Mailprovider macht das so. Zert. ist auf seinen host
ausgestellt und der client wirft ne Warnung weil foo ungleich bar.de
ist. Im TB kann man dann nur ne Ausnahmeregel machen, bei älterem iphone
ging das auch noch (letztes Jahr) aber m.W. erlauben neuere (5s oder IOS
12.x?) das nicht mehr. Mail ist da dann IMHO faktisch nicht nutzbar oder
man muß zu kruden Hacks greifen.

> nicht bekannten Zertifizierungsstelle signiert. Es erfüllt dann weder
> den Zweck, eine verschlüsselte Verbindung zu ermöglichen, kann dann

Ist da ein Logischer oder Tippfehler drin? Ein Gültiges Zertifikat für
Host X soll die verschlüsselung damit nicht erlauben wenn Host X über
hostname Y angesprochen würde?

> aber nicht den weiteren Zweck erfüllen, die Authentität der
> Gegenstelle zu bestätigen. In dem Fall kannst Du dann die

Ja, da müsste man schon regelmäßig die IPs von Host X und Host Y
abfragen und speichern und auch festhalten ob und wann sich diese
änderten. Und dann... passiert nix weiter! ? :-)

> Zertifikatsbestätigung ausschalten; das ist in der Regel ein
> brauchbarer Weg. Du könntest das Zertifikat natürlich auch selbst als
> gültig akzeptieren und in den Cert-Store aufnehmen, aber wenn Du nicht

Meine Linux(e) haben keinen Cert-store - soweit ich weiß. FF und TB
haben ihren Eigenen. KDE/Konqueror wohl auch. Der rest... ich weiß nicht.


Kay

-- 
Posted via leafnode

[toc] | [prev] | [next] | [standalone]

#6359

Kay Martinen schrieb:

> Am 15.04.21 um 18:16 schrieb Thomas Hochstein:
> > Wohl nur, wenn alle Provider eigenartige Konfigurationen fahren (oder
> 
> Vielleicht nicht alle. Aber viele hosten auf einem Server evtl. viele
> domains (mail u.a.)

Und die absolute Mehrzahl bekommt es trotzdem hin, TLS auf die Reihe
zu bekommen; der Provider des OP ja auch (das Zertifikat ist korrekt).

> Und was bleibt einem dann übrig wenn man den Provider nicht wechseln
> will? Zertifikat händisch prüfen und als ausnahme speichern. Oder?

Den realen Hostnamen verwenden?

> > nicht bekannten Zertifizierungsstelle signiert. Es erfüllt dann weder
> > den Zweck, eine verschlüsselte Verbindung zu ermöglichen, kann dann
> 
> Ist da ein Logischer oder Tippfehler drin?

Ja. "Es erfüllt dann ZWAR den Zweck ..." war gemeint.

> Meine Linux(e) haben keinen Cert-store - soweit ich weiß.

Meiner liegt in /etc/ssl/certs/.

-thh
-- 
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>

[toc] | [prev] | [next] | [standalone]

#6367

Am 16.04.21 um 00:03 schrieb Thomas Hochstein:
> Kay Martinen schrieb:
> 
>> Am 15.04.21 um 18:16 schrieb Thomas Hochstein:
>>> Wohl nur, wenn alle Provider eigenartige Konfigurationen fahren (oder
>>
>> Vielleicht nicht alle. Aber viele hosten auf einem Server evtl. viele
>> domains (mail u.a.)
> 
> Und die absolute Mehrzahl bekommt es trotzdem hin, TLS auf die Reihe
> zu bekommen; der Provider des OP ja auch (das Zertifikat ist korrekt).

Pro gehostete (mail)domain einen A record oder Zertifikate auf einen
CNAME ausgestellt? Letztes darf m.E. nicht sein oder?


>> Und was bleibt einem dann übrig wenn man den Provider nicht wechseln
>> will? Zertifikat händisch prüfen und als ausnahme speichern. Oder?
> 
> Den realen Hostnamen verwenden?

Ich glaub das hab ich mal versucht und konnte mich nicht einloggen oder
irgendwas anderes. Könnte es sein das der dortige MTA beim SMTP-Dialog
schauen kann ob er über den CNAME oder seinen Richtigen Namen
angesprochen wird? Und dann schlichtweg den login verweigert wenn
user@domain.de nicht zu smtp.domain.de passt?

Erklären kann ich's nicht und ich glaub auch nicht das so was geht, ist
aber die einzige Erklärung die mir einfiele.

Wie der MTA rausfinden wollte mit welchem namen seine IP ermittelt wurde
kann m.E. nur gehen wenn der MUA dabei einen Fehler machte. Und den
"falschen" namen im SMTP verwendete. Falsch im sinne von "nicht meine
domain"

>> Meine Linux(e) haben keinen Cert-store - soweit ich weiß.
> 
> Meiner liegt in /etc/ssl/certs/.

Ist das nicht für so'n lokale Zertifizierungs-Stelle dingens?


Kay

-- 
Posted via leafnode

[toc] | [prev] | [next] | [standalone]

#6368

Kay Martinen schrieb:

> Pro gehostete (mail)domain einen A record oder Zertifikate auf einen
> CNAME ausgestellt? Letztes darf m.E. nicht sein oder?

Warum nicht? www.example.org als CNAME für example.org und Zertifikate
für beides scheint mir ein völlig naheliegender Anwendungsfall zu
sein.

> Ich glaub das hab ich mal versucht und konnte mich nicht einloggen oder
> irgendwas anderes. Könnte es sein das der dortige MTA beim SMTP-Dialog
> schauen kann ob er über den CNAME oder seinen Richtigen Namen
> angesprochen wird?

Normalerweise nicht.

> Wie der MTA rausfinden wollte mit welchem namen seine IP ermittelt wurde
> kann m.E. nur gehen wenn der MUA dabei einen Fehler machte. Und den
> "falschen" namen im SMTP verwendete. Falsch im sinne von "nicht meine
> domain"

Jo.

> >> Meine Linux(e) haben keinen Cert-store - soweit ich weiß.
> > Meiner liegt in /etc/ssl/certs/.
> 
> Ist das nicht für so'n lokale Zertifizierungs-Stelle dingens?

Hm? Da liegen jedenfalls - bei Debian zumeist in Form von symlinks -
die Zertifikate, denen vertraut wird.

-thh
-- 
Informationen rund um E-Mail und Mailserver:
<https://th-h.de/net/mail/>

[toc] | [prev] | [next] | [standalone]

#6369

Kay Martinen:

> Am 16.04.21 um 00:03 schrieb Thomas Hochstein:
>> Kay Martinen schrieb:
>>
>>> Am 15.04.21 um 18:16 schrieb Thomas Hochstein:
>>>> Wohl nur, wenn alle Provider eigenartige Konfigurationen fahren (oder
>>>
>>> Vielleicht nicht alle. Aber viele hosten auf einem Server evtl. viele
>>> domains (mail u.a.)
>>
>> Und die absolute Mehrzahl bekommt es trotzdem hin, TLS auf die Reihe
>> zu bekommen; der Provider des OP ja auch (das Zertifikat ist korrekt).
> 
> Pro gehostete (mail)domain einen A record oder Zertifikate auf einen
> CNAME ausgestellt? Letztes darf m.E. nicht sein oder?

Doch, das darf sein. Ob eine Domain über einen CNAME-Record indirekt
aufgelöst wird oder A-Record, ist rein technisch für das Ergebnis egal.

Einige Spamfilter sind aber etwas "picky" und bestehen auf einen
A-Record und einen korrekten Reverse-Eintrag für die IP-Adresse des
Mailservers, wenn dieser etwas zustellen will.

[...]
> Wie der MTA rausfinden wollte mit welchem namen seine IP ermittelt wurde
> kann m.E. nur gehen wenn der MUA dabei einen Fehler machte. Und den
> "falschen" namen im SMTP verwendete. Falsch im sinne von "nicht meine
> domain"
> 
>>> Meine Linux(e) haben keinen Cert-store - soweit ich weiß.
>>
>> Meiner liegt in /etc/ssl/certs/.
> 
> Ist das nicht für so'n lokale Zertifizierungs-Stelle dingens?

Nein, da liegen u.A. auch alle Zertifikate der bekannten
Zertifizierungsstellen.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6370

Kay Martinen <usenet@martinen.de> wrote:
> Pro gehostete (mail)domain einen A record oder Zertifikate auf einen
> CNAME ausgestellt? Letztes darf m.E. nicht sein oder?
 
Eigentlich sollte ein MX *niemals* auf einen CNAME zeigen, somit waere es
wohl unsinnig, fuer Mail ein Zertifikat auf einen CNAME auszstellen ...

Tschuess,
	Juergen Ilse			(juergen@usenet-verwaltung.de)

[toc] | [prev] | [next] | [standalone]

#6371

Juergen Ilse schrieb:

> Kay Martinen <usenet@martinen.de> wrote:
> > Pro gehostete (mail)domain einen A record oder Zertifikate auf einen
> > CNAME ausgestellt? Letztes darf m.E. nicht sein oder?
>  
> Eigentlich sollte ein MX *niemals* auf einen CNAME zeigen, somit waere es
> wohl unsinnig, fuer Mail ein Zertifikat auf einen CNAME auszstellen ...

Nicht, wenn der Kunde seine E-Mail unter dem Hostnamen
"meinedomain.example" abrufen soll.

[toc] | [prev] | [next] | [standalone]

#6372

On 18.04.21 13:32, Thomas Hochstein wrote:
> Juergen Ilse schrieb:
>> Kay Martinen <usenet@martinen.de> wrote:

>>> Pro gehostete (mail)domain einen A record oder Zertifikate auf einen
>>> CNAME ausgestellt? Letztes darf m.E. nicht sein oder?
>>   
>> Eigentlich sollte ein MX *niemals* auf einen CNAME zeigen, somit waere es
>> wohl unsinnig, fuer Mail ein Zertifikat auf einen CNAME auszstellen ...
> 
> Nicht, wenn der Kunde seine E-Mail unter dem Hostnamen
> "meinedomain.example" abrufen soll.

E-Mail-"Abruf" erfolgt nicht von Servern, die man über MX-Records 
herausfindet. Jedenfalls normalerweise, d.h. außerhalb von komischen 
Spezialkonfigurationen.


mfG Paul

[toc] | [prev] | [next] | [standalone]

#6373

Paul Muster schrieb:

> On 18.04.21 13:32, Thomas Hochstein wrote:
> > Juergen Ilse schrieb:
> >> Eigentlich sollte ein MX *niemals* auf einen CNAME zeigen, somit waere es
> >> wohl unsinnig, fuer Mail ein Zertifikat auf einen CNAME auszstellen ...
> > Nicht, wenn der Kunde seine E-Mail unter dem Hostnamen
> > "meinedomain.example" abrufen soll.
> 
> E-Mail-"Abruf" erfolgt nicht von Servern, die man über MX-Records 
> herausfindet. Jedenfalls normalerweise, d.h. außerhalb von komischen 
> Spezialkonfigurationen.

Ja, eben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comm.software.mailserver

csiph-web