[gelöst] ca-certificates ?

[TomL]

Moin

Warum gibt es den Ordner /usr/share/ca-certificates und wer benötigt diese Zertifikate?

Bislang dachte ich immer, ein eigenes Zertifikat bestätigt bei von mir ausgehenden Verbindungen, dass ich "ich" bin. Aber weil ich ja kein eigenes Zertifikat besitze, konnte ich auch nie ne Bestätigung mitsenden. Und jetzt stolpere ich über diesen Ordner mit hunderten Zertifikaten. Nach fast 3 Jahren Debian nehme ich die jetzt zum ersten Mal bewusst wahr und bin total überrascht. Welche Programme machen damit was oder benötigen diese Zertifikate? Da sind ja so merkwürdige Certs wie Hongkong-Post, Staat_der_Nederlanden, Swisscom, Turktrust, usw.usw. dabei. Wofür sind die? Welchen Nutzen haben die oder könnten die für mich haben? Was passiert ...oder anders gefragt... was geht danach nicht mehr, wenn ich die einfach löschen würde?

[sbruder]

Moin
Bislang dachte ich immer, ein eigenes Zertifikat bestätigt bei von mir ausgehenden Verbindungen, dass ich "ich" bin. Aber weil ich ja kein eigenes Zertifikat besitze, konnte ich auch nie ne Bestätigung mitsenden. Und jetzt stolpere ich über diesen Ordner mit hunderten Zertifikaten. Nach fast 3 Jahren Debian nehme ich die jetzt zum ersten Mal bewusst wahr und bin total überrascht. Welche Programme machen damit was oder benötigen diese Zertifikate? Da sind ja so merkwürdige Certs wie Hongkong-Post, Staat_der_Nederlanden, Swisscom, Turktrust, usw.usw. dabei. Wofür sind die? Welchen Nutzen haben die oder könnten die für mich haben? Was passiert oder besser, was geht danach nicht mehr, wenn ich die einfach löschen würde?

Das sind die Zertifikate denen Du vertraust (falls nicht, die entsprechenden deaktivieren). Das sind die, die einem Betreiber einer Internetseite bestätigen, dass er er ist. Die bringen Dir, dass jemand vertrauenswürdige Zertifikate raussucht und Du nicht immer alle einzeln bestätigen musst.
Löschen solltest Du die nicht, da man alles innerhalb von /usr (mit außnahme von /usr/local) nicht anfasst.

[guennid]

Das sind die Zertifikate denen Du vertraust

Na Thomas, da biste platt. Ich glaube, dass war nicht so wirklich das, was Thomas hören wollte. Und mich beschleicht weiterhin der Verdacht, dass ihm das nicht weiterhilft. Mir übrigens auch nicht.

[thoerb]

Vielleicht hilft das weiter: https://packages.debian.org/de/jessie/ca-certificates

[MSfree]

Bislang dachte ich immer, ein eigenes Zertifikat bestätigt bei von mir ausgehenden Verbindungen, dass ich "ich" bin.

Die CA-Certificates sind für die Gegenrichtung. Wenn du dich mit einem Server per HTTPS verbinden willst, z.B. zum Online-Banking, dann sollte ja auch ein gewisses Interesse darin bestehen, daß du wirklich mit https://deinehausbank.de verbunden bist und nicht versehentlich mit https://phishersbank.ru.

Dazu schickt der Server seinen öffentlichen Schlüssel zu deinem Webbrowser. Dieser öffentliche Schlüssel ist bei allen seriösen Betriebern von einer Art elektronischem Notar signiert. Die Signaturen dieser elektronischen Notare befindet sich im Verzeichnis /usr/share/ca-certificates.

Wenn du die Dateien löschst, kann dein Browser die Echtheit der reinkommenden Schlüssel nicht mehr gegen die CA-Certs prüfen und du bekommst ein Warnung, daß du dich womöglich mit einer nicht vertrauenswürdigen Webseite verbinden willst.

[TomL]

Nee, die Paketbeschreibung hilft nicht wirklich, da habe ich im Web besseres gefunden. Ebensowenig hilft wassbruder erklärt hat.

Nehmen wir mal an, wie sbruder gesagt hat, ich vertraue dem Zertifikat "turktrust" ... was ich nach den aktuellen Entwicklungen allerdings eher skeptisch betrachte. *lol* Jetzt kann ich mir drei Szenarien in meiner Phantasie vorstellen:

1. Ich nehme das Zertifikat bei einer eigenen ausgehenden Verbindung und behaupte "das bin ich... mit diesem Zertifikat bestätigt"
2. Eine neue Verbindung von/zu Turktrust kann ich mit meiner Kopie verifizieren
3. Beim surfen guckt der Browser in die Zertifikate, wenn ich eine zertifizierte Gegenseite ansurfe

Sind diese Zertifikate zum Senden gedacht oder zur Verifikation beim Empfang? Werden damit Verbindungen authentifiziert? Nach welcher Regel... vom Sender unaufgefordert gesendet...?... oder von der Gegenseit angefordert? Welche Programme nutzen diese Zertifikate?

Mit gehts eigentlich im wesentlich oben um den Punkt 1. Irgendwo im Web (ein HowTo) habe ich die Verwendung eines Zertifikats gesehen und mir gedacht "wieso kann der denn dieses Zertifikat verwenden... der IST das doch gar nicht."

[TomL]

@msfree

Danke, das hat jetzt mehr Licht ins Dunkel gebracht. Jetzt ist nur noch die letzte Frage aus meinem Vorposting offen.... die (mein erster Gedanke "missbräuchliche") Verwendung "fremder Zertifikate".

[thoerb]

Nee, die Paketbeschreibung hilft nicht wirklich

Ich wollte dir damit auch nur zeigen, wo das herkommt.

[dufty2]

Wenn du die Dateien löschst, kann dein Browser die Echtheit der reinkommenden Schlüssel nicht mehr gegen die CA-Certs prüfen und du bekommst ein Warnung, daß du dich womöglich mit einer nicht vertrauenswürdigen Webseite verbinden willst.

Das ist so nicht richtig.

Wenn wir unter Browser "firefox" verstehen, benutzt der seine eigenen Zertifikatsspeicher, gewöhnlich unter ~/.mozilla/
Chrome hat mW auch einen eigenen.
Weiterhin benutzt firefox die NSS-Bibliothek, wohingegen /etc/ssl/certs/ bzw. /etc/ca-certificates eher aus der "openssl-Ecke" kommen.

[MSfree]

die (mein erster Gedanke "missbräuchliche") Verwendung "fremder Zertifikate".

Es kommt vor, geht aber in der Regel auf Schlampereien der Zertifizierungsstelle zurück. Mit anderen Worten, der Notar macht seine Arbeit nicht richtig.

Solchen Zertifizierungsstellen wird dann aber auch das Vertrauen entzogen:
https://www.heise.de/security/meldung/A ... 53514.html

In der Konsequenz werden in der Regel auch Updatapakete mit neuen CA-Certs zur Verfügung gestellt.

[sbruder]

Also mit den Zertifikaten, die Du hast kannst Du nichts anfangen, die sind nur zum Verifizieren gedacht, zum Signieren brauchst du einen Teil den die CA (in dem Fall TÜRKTRUST) (hoffentlich) geheimhält. Wie MSfree schon geschrieben hat kommt eine Manipulation mal vor, geht aber nur wenn die CA was richtig verbockt.

[TomL]

Ah ja... das heisst, der Zertifikat-Inhaber hat nen eigenen geheimen Schlüssel, der zu meiner Version des Zertifikats passen muss. Jetzt ergibt das auch alles einen Sinn.

Du sagst, mit den bei mir liegenden Certs kann ich nix anfangen.... tja, eigentlich hatte ich mir das auch so gedacht. Aber wach geworden bin ich gestern abend, als ich beim Testen eines Programms für ausgehende (!) Connections ein beliebiges Cert aus diesem Verzeichnis in die Conf des Programms eintragen konnte. Bevorzugt "/etc/ssl/certs/ca-certificates.crt", aber in anderen HowTos wurden eben auch andere verwendet. Und ich konnte erst gar nicht glauben, dass das wirklich beliebig sein soll.

Die Man_Page dieses Programm zu TLS sagt:
When TLS is started, the server sends a certificate to identify itself. To verify the server identity, a client program is expected to check that the certificate is formally correct and that it was issued by a Certificate Authority (CA) that the user trusts. (There can also be certificate chains with intermediate CAs.)

The list of trusted CAs is specified using the tls_trust_file command. Usually there is some system-wide default file available, e.g. /etc/ssl/certs/ca-certificates.crt on Debian-based systems, but you can also choose to select the trusted CAs yourself.

Gestolpert bin ich über den Zusammenhang eines "beliebigen" Certs in der Conf und dieser Aussage oberhalb: "sends a certificate to identify itself" Und bei diesem Hintergrund kommt es mir so vor, als würde ich vorgeben, jemand anders zu sein.

[dufty2]

Du bringst hier einige Sachen durcheinander.
Unter /etc/ssl/certs/ liegen - in der Regel - nicht die Zerfikate der einzelnen Webserver (da wären ja hunderttausende) , sondern "nur" die der CAs. CAs sind Certificate Authorities.

Das sich der Client auch authentifiziert, ist auch möglich, nur unter dem "normalen" HTTPS nicht üblich.

Du versuchst anscheinend STARTTLS ("TLS für Mailserver") anzuwenden.

[sbruder]

Ja, wenn du das in ein Ausgehendes Programm eintragen musst, braucht das eine Angabe, welchen Zertifikaten es vertrauen kann. /etc/ssl/certs/ca-certificates.crt sind ALLE Zertifikate aus /etc/ssl/certs (symlinks zu /usr/share/ca-certificates/…)

[TomL]

Du bringst hier einige Sachen durcheinander.

Ja, davon gehe ich aus. Das ist ja auch ein Thema, mit dem ich vorher nie zu tun hatte.

Du versuchst anscheinend STARTTLS ("TLS für Mailserver") anzuwenden.

Ja, ich glaube das ist es. Wobei ich keinen Mailserver betreibe, sondern nur via CLI eine Mail versenden möchte. Ich habe gestern msmtp installiert und es funktioniert prima. Und im Verbose-Mode beim Senden mit Cert wird Strato auch eindeutig angegeben, mit Fingerabdruck und allem Pipapo

Code: Alles auswählen

TLS Zertifikatinformation:
    Eigentümer:
    Allgemeiner Name: smtp.strato.de

Nur ich verstehe hier den Zusammenhang nicht. Warum ich in meiner Conf eine beliebige Cert eintragen kann und es trotzdem immer funktioniert.

Das sich der Client auch authentifiziert, ist auch möglich, nur unter dem "normalen" HTTPS nicht üblich.

Indem er ein fremdes Cert aus der /etc/ssl/certs/ca-certificates.crt verwendet? Das ist ja genau das, was ich nicht verstehe... vor dem Hintergrund, dass die Verbindung ja von mir initiiert wurde.

[dufty2]

vor dem Hintergrund, dass die Verbindung ja von mir initiiert wurde.

Wenn Du die Verbindung zu smpt.strato.de auf Port 25 initiierst, bist Du der (TLS-)Client und Strato der (TLS-)Mail-Server.

Code: Alles auswählen

$ openssl s_client -connect smtp.strato.de:25 -starttls smtp
<snip>
i:/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2

So, und nun guckste unter /etc/ssl/certs was da liegt:
Deutsche_Telekom_Root_CA_2.pem

Du (bzw. Dein Programm) vertraut der Telekom und damit (automatisch) Strato.

[TomL]

Du (bzw. Dein Programm) vertraut der Telekom und damit (automatisch) Strato.

Genau dieser Weg leuchtet mir ein und ist auch plausibel. Ich öffne eine SSL-Verbindung nach Strato, der Server sendet mir ein Zertifikat, mein SSL verifiziert das anhand meines (bzw. eines passenden) gespeicherten öffentlichen Schlüssels in /etc/ssl/certs .... und wenn alles gut ist, steht die Verbindung.

Aber die gute Nachricht ist, mithilfe der Anregungen hier und nach einem neuen Test habe ich es jetzt endlich doch verstanden. Ich habs nämlich jetzt mal mit verschiedenen anderen Zertifikaten versucht. Alle "failed", obwohl die alle gültig sind, nicht eine Verbindung kam zustande. Dummerweise hatte ich vorher genau den einen erwischt, mit dem es auch geht... und zwar Telekom. Da lag natürlich der Rückschluss nah " wenn Telekom geht, gehen die anderen auch".... so ist es aber nicht.

Aber was bewirkt der Eintrag meines lokalen Certs in der Conf? Das ist -davon bin ich jetzt überzeugt- quasi 'ne Rückwärtseinschränkung... mal so salopp ausgedrückt. Das heisst, der Server (Strato) muss nicht nur ein gültiges Zertifkat senden, es muss auch zwingend zu meiner Vorgabe in der Conf passen. Sonst wäre es ja möglich, dass ich zwar nen gültiges Zertifikat bekomme, welches sogar in meinem Riesenpool auch noch verifiziert wird, aber tatsächlich gar nicht von Strato kommt. Das ist mit meiner Vorgabe ausgeschlossen.

Boaar ist das alles ein kompliziertes Denken....

Danke für Eure Hilfe bei der Auflösung dieses Knotens....

[dufty2]

Aber was bewirkt der Eintrag meines lokalen Certs in der Conf? Das ist -davon bin ich jetzt überzeugt- quasi 'ne Rückwärtseinschränkung... mal so salopp ausgedrückt.

Nope.

Mittels ‘tls_trust_file [file]’ vertraust Du der Telekom.

Mittels ‘tls_fingerprint [fingerprint]’ vertraust Du Strato resp. dessen Zertifikat direkt, bräuchtest also kein /etc/ssl/certs/... bzw. kein Telekom-Root-Zertifikat mehr.

Mittels ‘tls_cert_file [file]’ machst Du die sog. Client Authentication (die - wie bereits erwähnt - sehr unüblich ist) gegenüber Strato, würde Dich aber nicht vor einem falschen Strato-zertifikat schützen.

[TomL]

Aber was bewirkt der Eintrag meines lokalen Certs in der Conf? Das ist -davon bin ich jetzt überzeugt- quasi 'ne Rückwärtseinschränkung... mal so salopp ausgedrückt.

Nope.
Mittels ‘tls_trust_file [file]’ vertraust Du der Telekom.

Code: Alles auswählen

openssl s_client -connect smtp.strato.de:587 -starttls smtp

Code: Alles auswählen

Certificate chain
 0 s:/C=DE/O=Strato AG/OU=Rechenzentrum
    i:/C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center
 1 s:/C=DE/O=T-Systems International GmbH/OU=T-Systems Trust Center
    i:/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2

Ich interpretiere das wie folgt... die
- Telekom bestätigt als Cert-Herausgeber die Identität von T-Systems
- T-Systems betätigt als Cert-Herausgeber die Identität von Strato

Somit kann ich doch sicher sein, mit Strato verbunden zu sein. Die Effekt ist, wenn ich in der Conf der "Hongkongpost" vertraue, wogegen ja erst mal nix einzuwenden ist, wird der Sendevorgang mit der Nachricht beendet:

Code: Alles auswählen

msmtp: TLS Zertifikatverifikation fehlgschlagen: das Zertifikat hat keinen bekannten Aussteller

Das kann ich mit etlichen anderen probieren, immer das selbe Ergebnis. Es funktioniert hingegen tadellos, wenn ich entweder gar kein Cert angebe, oder das der Telekom. Ich schließe daraus, wenn ich eines angebe, muss es zu der o.g. Chain passen, beginnend mit Herausgeber am eine Ende und Strato am anderen. Alles andere failed. Ist das nicht richtig?

[sbruder]

Die Effekt ist, wenn ich in der Conf der "Hongkongpost" vertraue, wogegen ja erst mal nix einzuwenden ist, wird der Sendevorgang mit der Nachricht beendet:

Code: Alles auswählen

msmtp: TLS Zertifikatverifikation fehlgschlagen: das Zertifikat hat keinen bekannten Aussteller

Das kann ich mit etlichen anderen probieren, immer das selbe Ergebnis. Es funktioniert hingegen tadellos, wenn ich entweder gar kein Cert angebe, oder das der Telekom. Ich schließe daraus, wenn ich eines angebe, muss es zu der o.g. Chain passen, beginnend mit Herausgeber am eine Ende und Strato am anderen. Alles andere failed. Ist das nicht richtig?

Das Zertifikat, dass du angibst muss klar zu dem der Gegenseite passen. dein Client nimmt wahrscheinlich automatisch alle bekannten, wenn Du keines gesondert angibst. Prinzipiell ist es so, dass sobald einem Glied in der Vertrauenskette vertraut wird, allen (oder bis zu einer bestimmten Stufe) Untergeordneten auch vertraut wird (Falls also Telekom vertraut wird, welche T-Systems vertraut, welche Strato vertraut, verlässt Du dich drauf, dass die Telekom sich Mühe beim Verifizieren gibt und nur dann ein Zertifikat ausstellt.) Schau dir mal den Wikipedia Artikel zu Web of Trust an, da ist das gut erklärt [1]

Alice signiert den Schlüssel von Bob und vertraut Bobs Schlüsselsignaturen
Bob signiert den Schlüssel von Carl
(Bobs Vertrauen in Carls Schlüsselsignaturen ist weder bekannt noch relevant)
Somit betrachtet Alice den Schlüssel von Carl als gültig.

[1] https://de.wikipedia.org/wiki/Web_of_Trust