Zertifikate

This transcript was generated automatically and has not been manually reviewed. It may therefore contain errors. The spoken word in the recording is always authoritative.

 Lucas Dohmen: Hallo und herzlich willkommen zur zweiten Folge vom INNOQ-Security-Podcast, heute ist wieder der Christoph mit dabei. Hallo Christoph!

Christoph Iserlohn: Hallo Lucas!

Lucas Dohmen: Wir wollen heute über Zertifikate reden. Warum eigentlich?

Christoph Iserlohn: In der letzten Folge hatten wir viel über Verschlüsselung geredet, über Kryptografie und vor allem, zum Großteil, über asymmetrische Kryptografie. Und in Zertifikaten kommt sehr viel asymmetrische Kryptografie zum Einsatz, und deshalb ist das jetzt ein ganz gutes Thema. Doch vorher würde ich gerne nochmal einen Einschub machen, und wir sollten vielleicht darüber reden, was digitale Signaturen sind. Denn die Zertifikate selber haben meistens den Zweck, dass man damit digitale Signaturen macht bzw. die überprüfen kann.

Lucas Dohmen: Was ist denn eine digitale Signatur?

Christoph Iserlohn: Eine digitale Signatur… Vereinfacht gesagt: Wenn wir ein Stück Bytes haben, ein elektronisches Dokument, können wir darüber eine Integritätssicherung machen, und zwar so, dass jemand anders das auch überprüfen kann. Das heißt, wenn ich ein elektronisches Dokument habe, dann kann ich eine Signatur darunter machen. Und dann könntest du überprüfen, ob ich genau dieses Dokument gesehen habe.

Lucas Dohmen: Okay, das ist also erst mal was anderes, als einfach nur sicherzustellen: Wenn ich jetzt beispielsweise dir etwas schicke und du schickst mir das zurück, dass ich noch weiß, dass du daran nichts verändert hast. Richtig?

Christoph Iserlohn: Das ist nochmal ein bisschen was anderes, ja. Es geht darum, dass ich, wenn ich etwas habe und ich dir das schicken möchte, dass du dann überprüfen kannst, dass ich genau das dir geschickt habe und gesehen habe.

Lucas Dohmen: Okay.

Christoph Iserlohn: Und die Funktionsweise ist einfach so, dass es mit asymmetrischer Kryptografie funktioniert. Ich bilde über dieses Dokument, über die ganzen Bytes irgendeine Prüfsumme, am besten mit einer Kryptografischen Hashfunktion, zum Beispiel SHA-256 oder SHA-3, erstmal ein Hash und den verschlüssele ich dann mit meinem privaten Schlüssel. Und dann setze ich das sozusagen an das Dokument dran. Da muss man ein bisschen aufpassen, da gibt es ein paar Verfahren, wie man das richtig macht, so dass es auch sicher ist. Zum Beispiel RSA-PSS heißt eines dieser Verfahren. Und wenn ich dir das schicke, dann kannst du das mit meinem öffentlichen Schlüssel wieder entschlüsseln und siehst dann den Hash und kannst ihn auch über das Dokument berechnen. Und dann vergleichst du die. Wenn die gleich sind, dann weißt du, dass ich genau dieses Dokument signiert habe. Und wenn der Hash nicht übereinstimmt, dann weißt du, ich habe ein anderes Dokument signiert mit anderem Inhalt, da wurde vielleicht was rausgenommen oder was dazugefügt. Oder es ist etwas ganz anderes.

Lucas Dohmen: Okay. Ist das denn auch das gleiche Verfahren, wenn ich ein offizielles Dokument mit meinem Personalausweis digital signiere? Ist das die gleiche Idee, oder ist das was anderes?

Christoph Iserlohn: Das eine, was wir heute besprechen wollen, ist die technische Seite. Das andere ist ein bisschen auch die rechtliche Seite. Das technische Verfahren ist im Prinzip das gleiche. Das Problem ist: Du muss ja auch wissen, mit wessen Schlüssel das unterschrieben wurde sozusagen. Und wenn wir beide uns kennen, dann kann ich dir den Schlüssel, wenn wir uns treffen, vielleicht geben. Aber wenn das irgendjemand macht, den du nicht kennst, dann weißt du ja gar nicht, ob der öffentliche Schlüssel, mit dem das signiert ist, genau dieser Person gehört, die das vermeintlich unterschrieben hat. Und das stellt man dann entsprechend sicher. Und da kommt dann vielleicht auch der elektronische Personalausweis oder sowas, solche anderen Verfahren, ins Spiel. Obwohl ich jetzt gar nicht weiß, ob man mit einem elektronischen Personalausweis selber was signieren kann, ob da ein Schlüssel drauf ist. Ich glaube eher nicht.

Lucas Dohmen: Ich hatte immer gedacht, das wäre so, aber vielleicht habe ich mich da auch verguckt.

Christoph Iserlohn: Auf jeden Fall ist das ein sehr guter Übergang. So ein Zertifikat, wenn wir darüber jetzt sprechen wollen, beweist nämlich sozusagen genau diese Zuordnung von Schlüsseln zu einer jeweiligen Person. Also, das Zertifikat im Allgemeinen muss gar nicht unbedingt sagen, dass ein öffentlicher Schlüssel zu einer bestimmten Person gehört. Sondern das kann auch sagen, das sind dann sogenannte Attribut-Zertifikate, dass bestimmte Eigenschaften einem Schlüssel oder auch einer Person zugeordnet werden. Aber der Haupteinsatzzweck beim Zertifikat ist es, zu sagen: Dieser öffentliche Schlüssel gehört XY, zum Beispiel dem Lucas.

Lucas Dohmen: Okay. Das ist einfach ein Transportformat für meinen öffentlichen Schlüssel?

Christoph Iserlohn: Das ist ein Transportformat, zum einen, zum anderen stellt es aber sicher, dass ich damit sagen kann: Dieser Schlüssel gehört genau dem Lucas. Oder: Irgendwem gehört dieser Schlüssel. Wenn ich jetzt im Internet unterwegs bin und eine Website aufrufe, zum Beispiel von meiner Bank, dann möchte ich auch gerne, dass die Verschlüsselung so ist, dass ich auch mit meiner Bank spreche. Und der muss ich ja irgendwie vertrauen. Und die Zertifikate stellen dieses Vertrauen einfach sicher.

Lucas Dohmen: Okay. Das heißt also, ein Zertifikat ist eine Mischung aus Informationen darüber, wer das ist und dass sie das auch wirklich ist?

Christoph Iserlohn: Ganz genau.

Lucas Dohmen: Okay, verstanden. Bevor wir ganz genau in die Zertifikate eintauchen, habe ich noch eine Frage. Wir haben ja gerade noch über das Signieren gesprochen. Ein Bereich, wo mir auch signieren noch bekannt vorkommt: In der Webentwicklung sind signierte Cookies. Sind die auch mit einem Zertifikat signiert? Oder wie sieht das aus?

Christoph Iserlohn: Man kann das machen, dass man die mit einem Zertifikat signiert, das ist aber üblicherweise nicht der Fall. Normalerweise nimmt man beim sogenannten signierten Cookie einen Message Authentication Code, einen MAC. Da der typischerweise basierend auf einem Hash-Verfahren arbeitet, ist das dann ein HMAC, also ein Hash-based Message Authentication Code. Und der hat insoweit Ähnlichkeit mit dem Signieren, dass das auch dafür ist, dass man die Integrität sicherstellt. Das heißt, wenn ich den Cookie rausgebe, dann kommt dieser Message Authentication Code dran, und wenn der zurück kommt, vom Browser, dann kann ich den nochmal neu berechnen und sehe, dass keiner den Cookie manipuliert hat. Der große Unterschied dabei ist, dass dieser Message Authentication Code mit einem Geheimnis arbeitet, das nur ich kenne, also mit einem symmetrischen Verfahren. Und bei einer normalen digitalen Signatur ist es so, dass da ja ein asymmetrisches Kryptografieverfahren zum Einsatz kommt und da kann jeder diesen Cookie überprüfen mit dem öffentlichen Schlüssel. Das ist der Unterschied. Weil eigentlich will ich ja, wenn ich so einen MAC hab, meinen geheimen Schlüssel nicht rausgeben, weil dann kann man ja auch wieder valide Cookies erzeugen mit einem MAC - mit dem Geheimnis - der manipuliert wurde. Deshalb ist streng genommen der Begriff “signierte Cookies” eigentlich falsch, sondern die werden integritätsgeschützt. Aber das hat sich so eingebürgert, dass man das auch “signiert” nennt. Und das ist auch gut, weil das ein schönes Verb ist, “signieren”. Integritätsgeschützt ist halt ein Nomen, das passt nicht so gut. Da kann man kein gutes Verb draus machen.

Lucas Dohmen: Das stimmt. Aber wahrscheinlich ist das der Grund dafür, dass es wieder schneller ist, oder? Weil es symmetrisch ist.

Christoph Iserlohn: Das ist schneller und es gibt ja auch bei Cookies keinen Grund, dass jemand anderes, dass der User oder der Browser überprüfen könnte, ob der geschützt ist, sondern das will ich ja nur auf der Serverseite wissen, wenn ich den rausgebe und ihn wiederbekomme, dass der dann noch genau dasselbe ist, wie als ich ihn rausgegeben habe, und nicht manipuliert wurde.

Lucas Dohmen: Und das ist einfach ein Shared Secret zwischen den Application-Servern?

Christoph Iserlohn: Genau.

Lucas Dohmen: Okay, das habe ich verstanden. Gut, dann lass uns nochmal zu den Zertifikaten zurückkommen. Du hast jetzt schon gesagt, irgendwie steht da drauf: “Ich bin der Lucas, und das ist mein Public Key.” Wie kann ich diesem Zertifikat denn jetzt vertrauen? Woher weiß ich denn: Das ist korrekt, was da draufsteht?

Christoph Iserlohn: Das wird so sichergestellt, dass das Zertifikat selber wieder auch signiert ist von jemand anders. Der sagt dann: “Ja, das ist wirklich Lucas' Key. Ich habe das Zertifikat jetzt so gesehen. Da steht der Key drin, und wem er gehört.” Und dieses Zertifikat, das signiert hat, ist vielleicht wieder signiert und wieder signiert, da bildet sich eine Kette, wo ganz am Schluss ein sogenanntes “Root-Zertifikat” steht. Und dieses Root-Zertifikat ist selbst-signiert. Weil diese Kette kann ja nicht endlos weitergehen. Und diesen Root-Zertifikaten muss ich halt irgendwie vertrauen, das ist sehr hierarchisch aufgebaut. Es gibt da eine ganze Reihe von Root-Zertifikaten, denen man vertraut, typischerweise. Und zwar ist es so, dass das Betriebssystem oder auch der Browser, der Firefox hat einen eigenen Zertifikat-Store, noch eine ganze Reihe von Root-Zertifikaten mitbringt, denen einfach vertraut wird. Sagen wir: Das sind Institutionen, denen vertrauen wir und deren Zertifikaten vertrauen wir. Die stellen dann wieder Zertifikate aus, um weitere Zertifikate zu signieren und so weiter und so fort. Und irgendwann ist unten mein eigenes Zertifikat, das ist dann ein sogenanntes “End-Entity-Zertifikat”, das sagt: “Da ist der Schlüssel drin, der mir gehört” oder “der Schlüssel, der zu einem Server gehört”, wenn es sich um TLS-Zertifikate handelt.

Lucas Dohmen: Okay, aber das heißt also, das gesamte System bricht zusammen, wenn man dem Root-Zertifikat nicht mehr vertrauen könnte. Weil, dann ist alles dahinter ja auch quasi dahin, oder?

Christoph Iserlohn: Ja. Es ist schon mal passiert, dass Schlüssel verloren gegangen sind oder kompromittiert wurden. Und es gibt Mechanismen, um Zertifikate zurückzuziehen. Dass man sagt, diese sind nicht mehr gültig. Das kann man überprüfen, und dann wird denen halt nicht vertraut. Wenn natürlich so ein Root-Zertifikat kompromittiert wird, ist das schon sozusagen der Super-GAU. Weil da hängen ganz viele Zertifikate dran. Die müssen dann alle zurückgezogen werden, und deshalb werden die Root-Zertifikate typischerweise auch offline gelagert, auf Rechnern und Storage, der nicht ans Internet angeschlossen wird. Aber dafür machen wir dann vielleicht mal eine Extrafolge über Certificate Authorities, die diese Root-Zertifikate haben und andere Zertifikate ausstellen.

Lucas Dohmen: Okay, das klingt gut. Dann klammern wir das Thema mal aus und konzentrieren uns wieder auf das Zertifikat. Da gibt es ja wahrscheinlich irgendein Format, in dem die abgelegt werden und ausgetauscht werden. Wie sieht das aus? Wie heißt das? Was macht das?

Christoph Iserlohn: Es gibt mehrere Zertifikatstandards, aber der gebräuchlichste ist der X.509-Standard. Darüber reden wir auch heute. Die anderen besetzen eher Nischen. Und die haben ein ganz bestimmtes Format und definieren, welche Daten da mindestens drin stehen müssen. Das wäre dann zum einen erstmal natürlich der Public Key, der da drinsteht. Dann steht da drin das Subject, das ist sozusagen: Wem gehört dieser Public Key? Das wäre dann zum Beispiel beim E-Mail-Zertifikat deins oder beim Server stände der Servername drin, und dann steht da sowas drin wie die Seriennummer des Zertifikats, die Gültigkeit. Weil, Zertifikate sind immer nur begrenzt gültig. Da steht also dann “Datum von… bis…” drin und welcher Signaturalgorithmus benutzt wurde und wer dieses Zertifikat ausgestellt hat. Das sind sozusagen die Basics, die da drin stehen. Und dann gibt es noch Extensions, die dabei sein können. Da muss man unterscheiden zwischen kritischen Extensions. Die haben ein Flag “critical”. Oder nicht-kritischen, da ist das Flag nicht gesetzt. Bei den kritischen ist es so: Wenn ich sie nicht verstehe, als Client, der dieses Zertifikat verarbeitet, dann muss ich einfach abbrechen. Dann sage ich, “das kann ich nicht”. Bei einer nicht-kritischen Extension ist es so, die kann ich auch im Zweifel ignorieren. Damit schaffe ich einen Übergang. Wenn neue Extensions eingeführt werden, dann kann ich ja nicht davon ausgehen, dass alle Clients das sofort können. Dann wird die wahrscheinlich im ersten Moment als nicht kritisch deklariert, und die alten Clients kommen auch noch damit klar, und irgendwann kommt dann der Übergang, dass die als kritisch markiert werden. Es gibt auch ein paar Extensions, die immer dabei und auch kritisch sind. Da wäre zum Beispiel das Basic Usage Extension (Anmerkung: gemeint sind Basic Constraint Extension). Da geht es darum: Was ist dieses Zertifikat? Ist das jetzt ein End-Entity-Zertifikat, mit dem ich als Endnutzer arbeite oder mein Server arbeitet? Oder ist das ein Zertifikat von einer Certificate Authority, mit dem ich andere Zertifikate unterschreiben kann? Dann gibt es noch weitere Extensions, zum Beispiel: Wozu kann ich diesen Schlüssel überhaupt benutzen? Das ist die Key Usage-Extension. Davon gibt es sogar zwei, es gibt die Key Usage und die Enhanced Key Usage- oder Extended Key Usage-Extension. Da steht dann drin: “Das kann ich jetzt nutzen, um zum Beispiel eine TLS-Verbindung aufzubauen”, oder “so, dass ich ein Client bin”. Oder dass es das Zertifikat einer E-Mail-Adresse ist, damit ich mit dem Schlüssel E-Mails signieren kann. Es gibt ganz verschiedene Extensions, die da genutzt werden.

Lucas Dohmen: Okay. Ich habe gerade mal hier in mein E-Mail-Zertifikat reingeguckt, da steht dann zum Beispiel auch “Key Usage”. Und bei der Extended Key Usage steht zum Beispiel “E-Mail Protection” und “Client Authentication” drin. Das wäre dann ein Beispiel?

Christoph Iserlohn: Genau.

Lucas Dohmen: Okay, das heißt, das ist also ein standardisierter Aufbau von so einem Zertifikat und den können dann verschiedene Anwendungen lesen.

Christoph Iserlohn: Den können alle Anwendungen lesen, die sich an diesen Standard halten. Da gibt es einmal den ASN.1-Standard, die Abstract Syntax Notation 1, die definiert die Struktur: Jetzt kommen Teil XY und dann kommen die Extensions, und die werden codiert als String, der so-und-so lang ist, oder als Bytefolge, die so-und-so lang ist. Das wird mit der Abstract Syntax Notation definiert. Und dann gibt es noch konkrete Encodings, die benutzt werden, um das wirklich in Bytes umzuwandeln. Da gibt es das BER- und das DER- Verfahren. Das BER sind die Basic Encoding Rules und DER sind die Distinguished Enoding Rules. Die sind eine Untermenge vom BER. Und das liegt daran: Beim BER kann es sein, dass man gleiche Sachen verschieden codieren kann und das ist valide. Wenn man als Vergleich mal nehmen würde: Mit Unicode kann man ja zum Beispiel Umlaute, ein “ü”, auch mit zwei Zeichen codieren, einmal das “u” und einmal die Striche darüber, und Unicode weiß dann, wie man die verbindet. Oder direkt als “ü”. Da hat man beide Male ein “ü”, aber verschiedene Bytes. Und das DER hat eine ganz eindeutige Codierung. In Unicode-Sprache wäre das dann sozusagen “normalisiert”. Und da das Bytes sind, werden die meistens auch gar nicht als Bytes direkt gespeichert, sondern als Base64. Und dann kommt noch das sogenannte PEM-Format zum Einsatz. Das sieht man vielleicht öfter auf der Platte, wenn man ein Zertifikat hat, dass da Dateien die Endung “.pem” haben. Das ist “Privacy Enhanced Mail”. Das kommt eigentlich aus dem PGP-Umfeld. Und die beginnen immer mit ein paar Strichen und dann steht da “BEGIN” und dann, was-weiß-ich, “BEGIN CERTIFICATE” oder whatever und unten steht ein “END”. Und dazwischen ist ein Block mit Base64, da stehen Zertifikate drin. Das hat den Vorteil, dass ich zum Beispiel eine ganze Zertifikatskette, vom Root-Zertifikat runter bis zu meinem Zertifikat, in eine Datei schreiben kann und dann sind Marker dazwischen, halt “BEGIN”, “END”. Und dann weiß ich immer, was das ist, dann kann ein Programm die vielleicht nachher gut zusammensetzen.

Lucas Dohmen: Können wir nochmal kurz zum BER und DER zurückgehen? Das heißt, hier hat man die Wahl, was man nimmt, oder wie ist das genau?

Christoph Iserlohn: Normalerweise wird man das DER nehmen, dass man eine eindeutige Codierung hat. Weil: Wenn du überlegst, dass du was signierst, und so ein Zertifikat ist ja signiert, von einer CA zum Beispiel. Dann willst du ja ein Hash. Und der Hash würde ja ganz anders ausfallen, je nachdem, wenn ich mehrere Encodings für dasselbe hätte. Und dann würde der Hash nicht mehr übereinstimmen. In dem Fall ist das DER natürlich dann besser geeignet als Encoding, weil das eindeutig immer dasselbe ergibt. Dann muss ich mich da nicht entscheiden.

Lucas Dohmen: Okay, wenn ich an das PEM denke: Das habe ich auch schon gesehen in der Anwendungsentwicklung. Aber wenn ich mein eigenes Zertifikat exportiere, dann gibt es ja dieses P7-Format, oder P7B-Format, heißt es, glaube ich. Was ist das?

Christoph Iserlohn: Es gibt noch eine ganze Reihe andere Formate. Java hat auch zum Beispiel ihren eigenen Keystore. Und bei diesem PK7 ist das, glaube ich, ich weiß die Dateiendung nicht (Anmerkung: .p7b und .p7c). Es gibt die PKCS, das sind die Public Key Cryptographic Standards. Da gibt es eine ganze Reihe von Standardsachen, die sich alle um den Bereich Public Keys oder Public Key Infrastructure, wie man die speichert oder wie die codiert werden oder so, drehen. Da gibt es auch noch ein paar Binärformate. Also, so ein Storage-Format, das dann zum Beispiel vielleicht auch passwortgeschützt ist. So ein Zertifikat will man vielleicht ja nicht unbedingt immer zugänglich haben. Deshalb sind die oft in einem Keystore drin, und da gibt es dann auch noch einige verschiedene Formate, wie man die verschlüsseln kann und so weiter.

Lucas Dohmen: Verstanden. Alles klar. Jetzt habe ich so ein Zertifikat. Was kann ich jetzt damit tun?

Christoph Iserlohn: Da gibt es ganz verschiedene Anwendungsmöglichkeiten. Die bekannteste ist wahrscheinlich TLS. Das heißt, wenn ich mit einem Server kommunizieren will, dann will ich das ja irgendwie verschlüsseln. Wir haben ja keinen gemeinsamen Schlüssel. Also muss der Schlüssel irgendwie ausgetauscht werden. Und da bietet sich natürlich an, dass ich einen Vorschlag für einen Schlüssel mache, indem ich den mit dem Public Key des Servers verschlüssele und ihm den schicke. Das ist eine Möglichkeit. Das ist jetzt nicht unbedingt das Verfahren, das man heutzutage nehmen würde. Aber das kann man machen. Das andere ist, um die Identität festzustellen. Da steht ja drin, wem der Schlüssel gehört und dazu dient dann eine Extension, die hatte ich vorhin noch nicht genannt. Das ist Subject Alternative Name weil, in “Name” steht meistens so eine hierarchische Sache wie zum Beispiel “Organisation: INNOQ” und “Land: Deutschland”. Da gibt es Abkürzungen: OU, Organizational Unit und C für Country. Das ist der sogenannte “Common Name”, der da codiert ist. Das ist der eigentliche Besitzer. Aber damit kann man jetzt ja nicht so viel anfangen bei TLS. Da will man ja wissen: “Ich will jetzt mit ‘innoq.com’ sprechen” und in diesem Subject Alternative Name könnte dann zum Beispiel die Adresse “www.innoq.com” stehen oder auch als Wildcard “*.innoq.com”. Und dann weiß ich: “Aha! Dieses Zertifikat gehört zu dieser Adresse, mit der ich auch reden will.” Das ist eine Anwendungsmöglichkeit für TLS. Dann gibt es wahrscheinlich die Zweite, die jeder so kennt für S/MIME, also für verschlüsselte Mails. Da steht dann die E-Mailadresse drin, mit der das verknüpft ist. Da steht dann, was-weiß-ich, “lucas.dohmeninnoq.com”. oder bei mir “christoph.iserlohninnoq.com” drin. Und dann weiß ich, wenn ich mit jemand anders kommuniziere, dass diese Mail dann auch von demjenigen signiert oder auch verschlüsselt ist. Weil sonst sind E-Mails, die einen Absender fälschen, ja nicht so das Problem. Dass ich mit deiner Adresse eine E-Mail verschicke, ist jetzt nicht so schwer. Aber deine Signatur fälschen ist dann schon schwerer. Der Empfänger muss halt wissen: Von wem ist dieser Public Key? Wenn ich dein Zertifikat nicht habe, dann kann ich für diese Adresse keine E-Mail-Signatur fälschen.

Lucas Dohmen: Aber wie komme ich denn an dein E-Mail-Zertifikat ran?

Christoph Iserlohn: Wenn ich das verschickt habe, ist das mit dabei, bei S/MIME, dann ist das sozusagen mit drangehängt. Und dann kommt wieder diese Vertrauenskette ins Spiel. Das heißt, ich muss demjenigen vertrauen, der dein Zertifikat signiert hat. Irgendeinem Zertifikat, wo drin steht: “Das ist Lucas Dohmen”, müsste ich ja nicht vertrauen und würde ich auch nicht vertrauen. Sondern dann geht es wieder so: Das kommt von einer Certificate Authority und wurde von der signiert. Und der vertraue ich dann wahrscheinlich. Oder mein E-Mail-Programm vertraut der.

Lucas Dohmen: Das heißt, das ist dieselbe Mechanik, das ist auch wieder eine Root CA? Okay. Und das heißt auch, dass eigentlich das, was man als E-Mail-Zertifikate hat, nicht anders ist als das, was man jetzt für ein TLS-Zertifikat verwendet, das ist eigentlich genau das Gleiche.

Christoph Iserlohn: Das ist auch ein X.509-Zertifikat. Die Extension ist dann halt anders. Du hattest das vorhin erwähnt, du hast deins mal geöffnet, und da steht dann als Extended Usage drin, dass die für E-Mail genutzt wird. Und bei den anderen steht dann halt TLS drin.

Lucas Dohmen: Genau. Bei TLS steht dann auch drin: “Für diese Domain” und bei meiner E-Mail steht drin “für diese E-Mailadresse”, oder?

Christoph Iserlohn: Genau, das ist dann der Subject Alternative Name. Und es gibt da noch zwei andere Verwendungszwecke, die wir vielleicht erwähnen sollten, die oft genutzt werden. Und das eine haben wir schon die ganze Zeit implizit genannt. Das ist nämlich ein Zertifikat, mit dem ich ein anderes Zertifikat unterschreiben kann. Das sind die, die von der Certificate Authority dann benutzt werden. Sonst könnte ich ja, wenn ich ein Zertifikat habe, das mir von einer vertrauenswürdigen Stelle ausgestellt wurde, einfach beliebige andere Zertifikate ausstellen und die für irgendeinen Unsinn benutzen, um mich für Google auszugeben, zum Beispiel. Dann mache ich mir ein TLS-Zertifikat für Google. Und das will man verhindern und deshalb steht da drin, dass ich kein CA-Zertifikat habe, mit dem ich das machen kann. Ich kann also keine anderen Zertifikate signieren.

Lucas Dohmen: Okay, das bedeutet aber, dass grundsätzlich das Zertifikat, was diese Root CAs haben, auch wieder ein X.509-Zertifikat ist, nur halt eins, was signieren darf.

Christoph Iserlohn: Eins, was signieren darf, und im Fall des Root-Zertifikats ist es auch selbst-signiert. Also, er hat selbst unterschrieben und hat dann gesagt: “Mein Zertifikat ist von mir.”

Lucas Dohmen: Genau, und dem vertraut ja mein System, und deswegen geht dann die Kette los.

Christoph Iserlohn: Genau. Die muss ich halt kennen, weil da gibt es keine Möglichkeit, sie zu überprüfen, sondern die ist dann sozusagen Out of Band. Die Browserhersteller, da gibts es halt Sachen, warum die Zertifikate von bestimmten Certificate Authorities aufnehmen. Die haben sich dann irgendwie überzeugt, dass die vertrauenswürdig sind. Aber alles, was darunter ist, dem wird vertraut, indem man einfach einmal die Kette hochwandern kann. Also, unter dem Root-Zertifikat, was ja offline ist, werden dann Zertifikate ausgestellt, mit denen die CA dann wieder mir persönlich ein TLS-Zertifikat geben kann, oder ein E-Mail-Zertifikat. Manchmal sind da auch zwei oder sogar drei Ebenen dazwischen, je nachdem. Der eins unter dem Root-Zertifikat, der signiert dann wieder Zertifikate, eins, damit werden E-Mail-Zertifikate ausgestellt, und eins, damit werden TLS-Zertifikate ausgestellt, dann hat man das auch nochmal getrennt. Und dann kommt da drunter meins, dann habe ich insgesamt vier Zertifikate da in der Kette.

Lucas Dohmen: Verstanden. Und du hast noch von einem vierten Usecase gesprochen?

Christoph Iserlohn: Ja. Der vierte, den kennt wahrscheinlich auch jeder, der ein Mobiltelefon mit einer App nutzt oder auch sonst vielleicht einen Mac, den App Store oder auch unter Windows Programme aus dem App Store von Windows lädt. Diese Zertifikate kann man nutzen, um Code zu signieren. Also dass sichergestellt wird, dass das Programm, das ich ausliefere, nicht manipuliert wurde, sondern dass ich sage: “Okay, das, was jetzt an dem Rechner ankommt, ist signiert und das wurde nicht manipuliert.” Dass ich dann keine Malware auf meinen Rechner bekomme. Die Stores können das mit ihren Zertifikaten signieren.

Lucas Dohmen: Und ist es dann im Fall vom Apple App-Store so, dass quasi Apple die Root CA ist? Oder haben die auch wieder ein ganz normales Zertifikat, das von der Root CA unterschrieben wurde?

Christoph Iserlohn: Das weiß ich jetzt gar nicht genau, wie das bei Apple ist. Auf jeden Fall ist es wichtig, dass das Betriebssystem, ob es jetzt iOS ist oder macOS, keine Anwendung startet, die nicht signiert ist von einem Zertifikat, dem sie vertraut und das auch für Code-Signierung ausgelegt ist. Bei Google und Apple, meine ich, haben die eigene Zertifikate, die das machen. Ob die selber ganz oben auch eine Certificate Authority sind, das weiß ich jetzt nicht. Ich glaube, Google ist auch selber eine Certificate Authority. Aber das kann ich dir jetzt nicht mit Sicherheit sagen. Aber wichtig ist, dass den Zertifikaten vertraut wird.

Lucas Dohmen: Und, genau, das ist ja der Schlüssel an allen Stellen.

Christoph Iserlohn: Also, ich weiß, wenn ich Entwickler bin bei Apple, kriege ich dann die Zertifikate auch von Apple, die ich nutze, um selber die Signaturen draufzumachen als Entwickler. Aber ob die ganze Kette ganz nach oben geht, bis Apple, oder ob da ein Dritthersteller ganz oben steht, das kann ich dir nicht sagen.

Lucas Dohmen: Okay, gut, das lassen wir mal als Aufgabe für die Hörerinnen und Hörer. Als weiteren Usecase gibt es ja noch diese Client-Zertifikate. Was hat es damit auf sich?

Christoph Iserlohn: Ja. Die Clinet-Zertifikate können genutzt werden, um sich irgendwo anzumelden. Zum Beispiel bei Webseiten ist es meistens so, dass da zwar TLS gesprochen wird. Aber es wird nur die Identität des Servers überprüft, also dessen Zertifikat. Der Server interessiert sich aber nicht dafür, welche Clients ihn aufrufen. Das kann irgendein Client sein. Jedenfalls wenn wir vom Server im Internet ausgehen.

Lucas Dohmen: Und der kennt auch erstmal die Identität von dem Client nicht, oder?

Christoph Iserlohn: Der kennt die Identität nicht. Aber in TLS ist es zum Beispiel vorgesehen, und das nennt sich dann mTLS, dass der Server sagen kann: “Client, schick mir bitte mal dein Zertifikat.” Zum Beispiel in einer geschlossenen Infrastruktur, sagen wir mal, im Intranet, könnte man das nehmen zum Beispiel statt Name und Passwort, dass der Client sich identifizieren muss. Und das macht er dann typischerweise über ein Zertifikat. Und der Server kennt dann entweder alle Zertifikate, denen er vertrauen kann. Das geht dann nur bei kleineren Mengen. Also, wenn er weiß: Okay, er kann Lucas' und Christophs und dem INNOQ-Zertifikat vertrauen, dann geht das vielleicht. Ansonsten ist es so, dass er nicht das eigentliche Subject, also: “Wem gehört das Zertifikat?” überprüft, sondern: “Wurde das signiert von einer Stelle, der ich vertraue?”, zum Beispiel von einem Zertifikat, das speziell dafür ausgestellt wurde, Client-Zertifikate auszustellen. Und wenn das von dem signiert ist, dann vertraue ich dem. Ein Beispiel, was man vielleicht auch kennt, oder was jeder kennt, ist ELSTER. Da kriegt man ja auch ein Zertifikat vom Finanzamt, damit man seine Steuererklärung schicken kann. Und das ist auch ein Client-Zertifikat, damit kann ich mich irgendwo ausweisen, “das bin ich”. Wo man das noch einsetzen kann als Alternative zu Username und Passwort oder zu einem Public Key, den ich hinterlege, ist bei SSH. SSH kann ich auch so konfigurieren, dass es ein X.509-Client-Zertifikat annimmt anstatt einem Key.

Lucas Dohmen: Okay. Und wäre das auch möglich, wenn ich das jetzt einrichte, dass ich das auf einer Webseite habe, um mich da einzuloggen, dass ich mich mit einem Client-Zertifikat einlogge? Oder geht das gar nicht?

Christoph Iserlohn: Doch, das geht. Das war das, was ich gerade erwähnt habe, also dieses mTLS, das heißt mutual TLS.

Lucas Dohmen: Also, ich meine jetzt: Vom Browser aus, nicht zwischen zwei Servern, sondern wirklich: Mein Browser möchte sich bei der INNOQ-Admin-Seite anmelden. Würde das auch gehen?

Christoph Iserlohn: Das geht auch, ist aber eher selten der Fall. Das ist mehr was für technisch versierte User, weil: Das Zertifikat müsste er dann speziell in dem Keystore, den der Browser benützt, installiert haben, als Client-Zertifikat. Im Firefox gibt es dafür so eine Einstellung. Da kann man seine Zertifikate sehen, welchen Root-Zertifikaten man vertraut. Das sind ganz schön viele im Fall von Firefox oder auch in dem Fall der anderen Browser. Und da gibt es auch Client-Zertifikate. Und wenn ich das da installiere, dann sendet der Browser das mit, wenn der Server das verlangt, und identifiziert sich. Das geht, es kommt aber eher seltener zum Einsatz, weil, wie gesagt, das ist für die technisch weniger versierten User eine Riesenhürde.

Lucas Dohmen: Obwohl es ja technisch eigentlich eine ganz gute, interessante Lösung wäre, für die Kommunikation.

Christoph Iserlohn: Absolut. Das habe ich auch schon in einigen Projekten gesehen. Dass interne Systeme, die zum Beispiel speziell an Entwickler gerichtet waren und sensible Informationen enthalten, dann zertifikatgeschützt werden. Weil: Das geht nicht so schnell verloren, vielleicht, wie ein Passwort.

Lucas Dohmen: Und das würde auch bedeuten, dass der Server dann auch meine Identität kennt. Also, er könnte auch einen Usernamen und so extrahieren, weil er das ja aus dem Zertifikat lesen kann, richtig?

Christoph Iserlohn: Das kann er aus dem Zertifikat lesen und könnte dann entsprechend dir Rechte geben, was du in diesem System dann tun kannst.

Lucas Dohmen: Interessant. Okay, eine Sache, die mir noch einfällt in diesem ganzen Zertifikatbereich, ist: Wie gehe ich denn mit mit alten Zertifikaten um? Muss ich die aufbewahren? Laufen die ab? Wie funktioniert das denn so?

Christoph Iserlohn: Alle Zertifikate haben eine Lebenszeit, wenn wir jetzt so E-Mail-Zertifikate als Beispiel nehmen, dann sind die so zwischen ein bis drei Jahre gültig. Server-Zertifikate waren früher auch so ein bis zwei Jahre gültig. Heute nimmt man jetzt Let’s Encrypt, da sind sie nur sehr kurz gültig, drei Monate. Bei den meisten Usecases kann man die danach wegwerfen. Die werden nicht mehr gebraucht. Aber bei E-Mail ist es etwas anders. Weil: Da steckt ja auch der Schlüssel drin. Meistens ist es der private Schlüssel plus das Zertifikat. Da muss man nochmal unterscheiden. Das Zertifikat selber könnte ich wahrscheinlich wegwerfen, nur nicht den privaten Schlüssel. Aber du hattest ja gerade von diesen PKCS-Sachen gesagt: Da gibt es Storage, da ist der private Schlüssel und das Zertifikat zusammen in einem Storage, deshalb will ich das ja auch sichern. Was ich vorhin gesagt habe, dass das Zertifikat verloren geht, ist eigentlich egal, weil das ist sowieso öffentlich. Aber mein privater Schlüssel, der daran hängt, beides speichern nämlich diese PKCS-Sachen und alle anderen Keystores. Auf jeden Fall ist es so, dass ich bei E-Mail den besser nicht wegschmeiße, wenn ich daran hänge, dass ich meine alten E-Mails auch noch lesen kann. Weil, wenn der Schlüssel weg ist, kann ich die nicht mehr entschlüsseln und dann kann ich sie auch nicht mehr lesen. Es sei denn, ich habe sie vorher entschlüsselt irgendwo auf der Platte gespeichert. Dann geht es vielleicht noch, aber sonst? Ich habe schon öfter davon gehört, dass Leute ihre Schlüssel weggeworfen haben samt Zertifikat und dann auf ihre E-Mails nicht mehr zugreifen konnten, auf die alten.

Lucas Dohmen: Ja, das habe ich auch schon mal gehört. Hüstel. Okay, gut. Das heißt, wir haben jetzt schon eine ganz schön große Übersicht über diese Zertifikate, die sind ja auch sehr vielseitig einsetzbar. Ich glaube, an der Stelle wollen wir so ein bisschen das Thema beenden. Aber schon mal als Ausblick: Was machen wir jetzt mit dem Wissen in den nächsten Folgen? Wo geht es als Nächstes hin?

Christoph Iserlohn: Als Nächstes werden wir wahrscheinlich über TLS sprechen, da, wo Zertifikate großflächig zum Einsatz kommen. Aber TLS hat noch viele andere Aspekte. Da schließen wir dann wieder so ein bisschen den Bogen auch zur symmetrischen Kryptografie. Und TLS wird wahrscheinlich auch ein Feld sein, mit dem viele Hörer tagtäglich irgendwie in Berührung kommen. Jedes Mal, wenn ich das Internet benutze, benutze ich irgendwie TLS. Danach sollten wir mal schauen, dass wir vielleicht auch über so eine CA, wie die aufgebaut ist und wie das funktioniert und wie die sicherstellen, dass man ihnen vertrauen kann und wie die in den Browser kommen und solche Sachen, reden. Und dann nehmen wir uns bestimmt mal Let’s Encrypt als Beispiel, weil, die hat die CA-Szene in den letzten Jahren kräftig aufgewirbelt.

Lucas Dohmen: Ja! Ich meine, die CA-Szene musste auch mal aufgewirbelt werden, wenn man so auf der einen oder anderen CA-Webseite schonmal gewesen ist.

Christoph Iserlohn: Ja.

Lucas Dohmen: Gut, Christoph. Dann danke ich dir für all diese Informationen, und den Hörerinnen und Hörern. Bis zum nächsten Mal. Tschüss.

Christoph Iserlohn: Tschau.