[{"data":1,"prerenderedAt":1800},["ShallowReactive",2],{"sc:header-data-de":3,"sc:footer-data-de":101,"glossary-posts-de":142,"content-de-list-c077398beed29":1799},{"lang":4,"home":5,"navigation":14,"contact":95},"en",{"name":6,"imgLight":7,"img":8,"languages":9},"home","/products/scepman/scepman-logo-all-white.svg","/products/scepman/scepman-logo-rgb.svg",{"de":10},{"title":11,"url":12,"alt":13},"Home","/de","SCEPman",[15,19,25,31,83,89],{"name":16,"languages":17},"nav-home",{"de":18},{"title":11,"url":12},{"name":20,"languages":21},"pricing",{"de":22},{"title":23,"url":24},"Preise","/de/pricing",{"name":26,"languages":27},"partner",{"de":28},{"title":29,"url":30},"Partner","/de/partner",{"name":32,"languages":33,"children":36},"support-hub",{"de":34},{"title":35},"Support Hub",[37,53,68],{"name":38,"children":39},"support-hub-group-1",[40,47],{"name":41,"target":42,"languages":43},"docs","_blank",{"de":44},{"title":45,"url":46},"Docs","https://docs.scepman.com/",{"name":48,"languages":49},"faq",{"de":50},{"title":51,"url":52},"FAQ","/de/faq",{"name":54,"children":55},"support-hub-group-2",[56,62],{"name":57,"target":42,"languages":58},"support-ticket",{"de":59},{"title":60,"url":61},"Support Ticket","https://support.scepman.com/support/tickets/new?ticket_form=technical_support_request_%28scepman%29",{"name":63,"target":42,"languages":64},"drop-a-question",{"de":65},{"title":66,"url":67},"Drop a Question","https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29",{"name":69,"children":70},"support-hub-group-3",[71,77],{"name":72,"languages":73},"glossary",{"de":74},{"title":75,"url":76},"Glossar","/de/glossary",{"name":78,"languages":79},"blog",{"de":80},{"title":81,"url":82},"Blog","/de/blog",{"name":84,"languages":85},"events",{"de":86},{"title":87,"url":88},"Events","/de/events",{"name":90,"languages":91},"about",{"de":92},{"title":93,"url":94},"Über uns","/de/about-us",{"name":96,"languages":97},"contact",{"de":98},{"title":99,"url":100},"support@scepman.com","mailto:support@scepman.com",{"data":102},{"mail":103,"logos":104,"socials":109,"links":122,"linksDe":132},"sales@SCEPman.com",[105],{"img":106,"alt":107,"url":108},"/products/scepman/scepman-logo-yellow.svg","SCEPman Logo","/",[110,114,118],{"icon":111,"url":112,"title":113},"fa-x-twitter","https://twitter.com/scepman_","X",{"icon":115,"url":116,"title":117},"fa-youtube","https://www.youtube.com/channel/UCKnLYxlQFhzdXkDADV_Unrg","Youtube",{"icon":119,"url":120,"title":121},"fa-linkedin","https://www.linkedin.com/showcase/scepman","LinkedIn",[123,126,129],{"title":124,"url":125,"target":42},"Privacy","https://www.glueckkanja.com/en/privacy",{"title":127,"url":128,"target":42},"Imprint","https://www.glueckkanja.com/en/imprint",{"title":130,"url":131,"target":42},"Contact & Locations","https://www.glueckkanja.com/en/company/contact-and-locations",[133,136,139],{"title":134,"url":135,"target":42},"Datenschutz","https://www.glueckkanja.com/de/privacy",{"title":137,"url":138,"target":42},"Impressum","https://www.glueckkanja.com/de/imprint",{"title":140,"url":141,"target":42},"Kontakt & Standorte","https://www.glueckkanja.com/de/company/contact-and-locations",[143,481,853,1111,1347],{"id":144,"title":145,"author":146,"body":147,"cta":146,"description":438,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":464,"moment":146,"navigation":476,"path":477,"seo":478,"stem":479,"tags":146,"webcast":462,"__hash__":480},"content_de/glossary/cryptography.md","Kryptografie",null,{"type":148,"value":149,"toc":437},"minimal",[150,155,167,174,202,208,230,234,237,240,249,252,260,299,303,306,310,313,317,320,324,327,330,334,338,341,367,371,374,391,395,398,402,405,409,412,417],[151,152,154],"h2",{"id":153},"welche-zwei-arten-schlüsselbasierter-verschlüsselung-gibt-es","Welche zwei Arten schlüsselbasierter Verschlüsselung gibt es?",[156,157,158,159,163,164],"p",{},"Die beiden Hauptarten schlüsselbasierter Verschlüsselung sind die ",[160,161,162],"strong",{},"symmetrische Verschlüsselung"," und die ",[160,165,166],{},"asymmetrische Verschlüsselung.",[168,169,171],"h3",{"id":170},"symmetrische-verschlüsselung",[160,172,173],{},"Symmetrische Verschlüsselung",[175,176,177,184,190,196],"ul",{},[178,179,180,183],"li",{},[160,181,182],{},"Schlüsselverwendung",": Verwendet einen einzigen Schlüssel zum Verschlüsseln und zum Entschlüsseln.",[178,185,186,189],{},[160,187,188],{},"Geschwindigkeit",": In der Regel schneller und effizienter.",[178,191,192,195],{},[160,193,194],{},"Sicherheit",": Die größte Herausforderung ist der sichere Austausch des Schlüssels zwischen den Beteiligten.",[178,197,198,201],{},[160,199,200],{},"Beispiele",": AES (Advanced Encryption Standard), DES (Data Encryption Standard).",[168,203,205],{"id":204},"asymmetrische-verschlüsselung",[160,206,207],{},"Asymmetrische Verschlüsselung",[175,209,210,215,220,225],{},[178,211,212,214],{},[160,213,182],{},": Verwendet ein Schlüsselpaar, einen öffentlichen Schlüssel zum Verschlüsseln und einen privaten Schlüssel zum Entschlüsseln.",[178,216,217,219],{},[160,218,188],{},": Langsamer als die symmetrische Verschlüsselung, weil die Berechnungen aufwendiger sind.",[178,221,222,224],{},[160,223,194],{},": Sicherer für die Schlüsselverteilung, da der private Schlüssel niemals weitergegeben wird.",[178,226,227,229],{},[160,228,200],{},": RSA (Rivest-Shamir-Adleman), ECC (Elliptic Curve Cryptography).",[168,231,233],{"id":232},"welche-art-der-verschlüsselung-gilt-als-sicherer","Welche Art der Verschlüsselung gilt als sicherer?",[156,235,236],{},"Beide Verfahren gelten als sicher in dem Sinne, dass kein heutiger Computer die Chiffre brechen kann, sofern du einen modernen Algorithmus mit ausreichender Schlüssellänge einsetzt.",[156,238,239],{},"Welche Art der Verschlüsselung besser geeignet ist, hängt vom Anwendungsfall ab. Viele Anwendungsfälle erfordern jedoch asymmetrische Verschlüsselung, weil sie ein Schlüsselpaar nutzt: einen öffentlichen Schlüssel zum Verschlüsseln und einen privaten Schlüssel zum Entschlüsseln. Der private Schlüssel bleibt geheim, was die Sicherheit erhöht, da er nie weitergegeben werden muss.",[168,241,243,244],{"id":242},"welche-art-der-verschlüsselung-eignet-sich-besser-für-große-datenmengen","Welche Art der Verschlüsselung eignet sich besser für große Datenmengen? ",[245,246],"a",{"href":247,"id":248},"#which-type-of-encryption-is-better-for-bulk-data","which-type-of-encryption-is-better-for-bulk-data",[156,250,251],{},"Die symmetrische Verschlüsselung, weil sie schneller ist.",[168,253,255,256],{"id":254},"wie-läuft-eine-hybride-verschlüsselung-grundsätzlich-ab","Wie läuft eine hybride Verschlüsselung grundsätzlich ab? ",[245,257],{"href":258,"id":259},"#what-is-the-general-process-for-hybrid-encryption","what-is-the-general-process-for-hybrid-encryption",[261,262,263,269,275,281,287,293],"ol",{},[178,264,265,268],{},[160,266,267],{},"Schlüsselerzeugung",": Der Absender erzeugt einen frischen symmetrischen Schlüssel (auch Sitzungsschlüssel genannt), um die eigentliche Nachricht zu verschlüsseln.",[178,270,271,274],{},[160,272,273],{},"Nachrichtenverschlüsselung",": Der Absender verschlüsselt den Klartext mit dem symmetrischen Schlüssel und erhält einen Geheimtext.",[178,276,277,280],{},[160,278,279],{},"Schlüsselverschlüsselung",": Anschließend verschlüsselt der Absender den symmetrischen Schlüssel mit dem öffentlichen Schlüssel des Empfängers (asymmetrische Verschlüsselung).",[178,282,283,286],{},[160,284,285],{},"Übertragung",": Der Absender schickt sowohl die verschlüsselte Nachricht (den Geheimtext) als auch den verschlüsselten symmetrischen Schlüssel an den Empfänger.",[178,288,289,292],{},[160,290,291],{},"Schlüsselentschlüsselung",": Der Empfänger entschlüsselt den symmetrischen Schlüssel mit seinem privaten Schlüssel.",[178,294,295,298],{},[160,296,297],{},"Nachrichtenentschlüsselung",": Zuletzt entschlüsselt der Empfänger mit dem entschlüsselten symmetrischen Schlüssel den Geheimtext und erhält den ursprünglichen Klartext zurück.",[151,300,302],{"id":301},"hash-algorithmen","Hash-Algorithmen",[156,304,305],{},"Ein Hash-Algorithmus ist eine mathematische Funktion, die Eingabedaten beliebiger Größe in eine Zeichenkette fester Länge umwandelt, typischerweise eine Folge aus Buchstaben und Ziffern. Diese Ausgabe wird als Hashwert oder Digest bezeichnet.",[168,307,309],{"id":308},"was-ist-eine-kollision","Was ist eine Kollision?",[156,311,312],{},"Eine Kollision beim Hashing tritt auf, wenn zwei unterschiedliche Daten mit einem Hash-Algorithmus denselben Hashwert ergeben. Das ist problematisch, weil ein Hash-Algorithmus in erster Linie unterschiedliche Eingabedaten eindeutig abbilden soll.",[168,314,316],{"id":315},"was-ist-ein-mac","Was ist ein MAC?",[156,318,319],{},"Message Authentication Code (MAC): In der Kryptografie ist ein MAC eine kurze Information, mit der sich eine Nachricht authentifizieren und ihre Integrität sicherstellen lässt. Er belegt, dass die Nachricht nicht verändert wurde, und bestätigt die Identität des Absenders.",[168,321,323],{"id":322},"worin-unterscheidet-sich-ein-mac-von-einem-hmac","Worin unterscheidet sich ein MAC von einem HMAC?",[156,325,326],{},"MAC: Ein Oberbegriff für einen Code, der Integrität und Authentizität einer Nachricht prüft und dafür entweder Blockchiffren oder Hashfunktionen verwendet.",[156,328,329],{},"HMAC: Eine spezielle Art von MAC, die eine kryptografische Hashfunktion und einen geheimen Schlüssel verwendet und stärkere Sicherheitseigenschaften bietet.",[151,331,333],{"id":332},"asymmetrische-kryptografie","Asymmetrische Kryptografie",[168,335,337],{"id":336},"wie-läuft-das-signieren-einer-nachricht-grundsätzlich-ab","Wie läuft das Signieren einer Nachricht grundsätzlich ab?",[156,339,340],{},"Das Signieren einer Nachricht ist ein kryptografisches Verfahren, mit dem sich Authentizität und Integrität einer Nachricht prüfen lassen.",[261,342,343,349,355,361],{},[178,344,345,348],{},[160,346,347],{},"Hash erzeugen:"," Der Absender erzeugt mit einer kryptografischen Hashfunktion (etwa SHA-256) einen eindeutigen digitalen Fingerabdruck (Hash) der Nachricht. Dieser Hash bildet den Inhalt der Nachricht eindeutig ab.",[178,350,351,354],{},[160,352,353],{},"Signieren:"," Der Absender verschlüsselt diesen Hash mit seinem privaten Schlüssel und erzeugt damit die digitale Signatur. So kann die Signatur nur von jemandem erzeugt werden, der Zugriff auf den privaten Schlüssel des Absenders hat.",[178,356,357,360],{},[160,358,359],{},"Senden:"," Die digitale Signatur wird an die Nachricht angehängt, beides geht an den Empfänger. Zur Prüfung wird zusätzlich der öffentliche Schlüssel des Absenders bereitgestellt.",[178,362,363,366],{},[160,364,365],{},"Prüfung:"," Der Empfänger entschlüsselt die digitale Signatur mit dem öffentlichen Schlüssel des Absenders und erhält so den ursprünglichen Hash zurück. Anschließend bildet der Empfänger einen neuen Hash über die empfangene Nachricht und vergleicht ihn mit dem entschlüsselten Hash. Stimmen beide überein, ist belegt, dass die Nachricht nicht verändert wurde, und die Identität des Absenders ist bestätigt.",[168,368,370],{"id":369},"welche-drei-funktionen-hat-die-asymmetrische-verschlüsselung","Welche drei Funktionen hat die asymmetrische Verschlüsselung?",[156,372,373],{},"Die asymmetrische Verschlüsselung, auch Public-Key-Kryptografie genannt, erfüllt mehrere wichtige Funktionen bei der Absicherung von Kommunikation und Daten.",[261,375,376,381,386],{},[178,377,378],{},[160,379,380],{},"Verschlüsselung und Entschlüsselung",[178,382,383],{},[160,384,385],{},"Digitale Signaturen",[178,387,388],{},[160,389,390],{},"Schlüsselaustausch",[168,392,394],{"id":393},"rsa","RSA",[156,396,397],{},"RSA, kurz für Rivest-Shamir-Adleman, ist ein weit verbreitetes Public-Key-Kryptosystem für die sichere Datenübertragung. Es ist nach seinen Erfindern Ronald Rivest, Adi Shamir und Leonard Adleman benannt, die es 1977 vorgestellt haben.",[168,399,401],{"id":400},"diffie-hellman","Diffie-Hellman",[156,403,404],{},"Der Diffie-Hellman-Schlüsselaustausch ist ein Verfahren der Kryptografie, mit dem sich kryptografische Schlüssel sicher über einen öffentlichen Kanal austauschen lassen. Whitfield Diffie und Martin Hellman haben es 1976 entwickelt. Der Diffie-Hellman-Schlüsselaustausch soll vor allem zwei Parteien in die Lage versetzen, sicher einen gemeinsamen geheimen Schlüssel zu erzeugen, mit dem die weitere Kommunikation verschlüsselt werden kann.",[168,406,408],{"id":407},"digital-signature-algorithm-dsa","Digital Signature Algorithm (DSA)",[156,410,411],{},"Der Digital Signature Algorithm (DSA) ist ein Public-Key-Algorithmus, mit dem sich digitale Signaturen erzeugen und prüfen lassen. Das National Institute of Standards and Technology (NIST) hat ihn 1991 als Teil des Digital Signature Standard (DSS) vorgeschlagen.",[413,414,416],"h4",{"id":415},"so-funktioniert-er","So funktioniert er",[261,418,419,425,431],{},[178,420,421,424],{},[160,422,423],{},"Schlüsselerzeugung:"," DSA erzeugt ein Schlüsselpaar: einen privaten Schlüssel zum Signieren und einen öffentlichen Schlüssel zur Prüfung.",[178,426,427,430],{},[160,428,429],{},"Signieren",": Der Absender erzeugt mit seinem privaten Schlüssel eine digitale Signatur über eine Nachricht. Diese Signatur ist sowohl für die Nachricht als auch für den privaten Schlüssel eindeutig.",[178,432,433,436],{},[160,434,435],{},"Prüfung",": Der Empfänger prüft mit dem öffentlichen Schlüssel des Absenders die Echtheit der Signatur und damit auch Integrität und Herkunft der Nachricht.",{"title":438,"searchDepth":439,"depth":439,"links":440},"",2,[441,449,454],{"id":153,"depth":439,"text":154,"children":442},[443,445,446,447,448],{"id":170,"depth":444,"text":173},3,{"id":204,"depth":444,"text":207},{"id":232,"depth":444,"text":233},{"id":242,"depth":444,"text":243},{"id":254,"depth":444,"text":255},{"id":301,"depth":439,"text":302,"children":450},[451,452,453],{"id":308,"depth":444,"text":309},{"id":315,"depth":444,"text":316},{"id":322,"depth":444,"text":323},{"id":332,"depth":439,"text":333,"children":455},[456,457,458,459,460],{"id":336,"depth":444,"text":337},{"id":369,"depth":444,"text":370},{"id":393,"depth":444,"text":394},{"id":400,"depth":444,"text":401},{"id":407,"depth":444,"text":408},"md",false,"post",{"lang":465,"titleClass":466,"blogtitlepic":467,"socialimg":468,"customExcerpt":469,"asideNav":470,"maxContent":476},"de","h1-font-size","header-scepman-cryptography.png","/blog/heads/header-scepman-cryptography.png","Die zentrale Herausforderung beim Enrollment von Zertifikaten ist die Frage, wie sich das Gerät oder der Benutzer authentifizieren lässt, das oder der das Zertifikat anfordert. Mit dem Zertifikat bestätigt die Zertifizierungsstelle, dass der Zertifikatsinhaber bestimmte Eigenschaften besitzt und dass sie deren Echtheit geprüft hat",{"menuItems":471},[472,474],{"href":473,"text":302},"#hash-algorithmen",{"href":475,"text":333},"#asymmetrische-kryptografie",true,"/glossary/cryptography",{"title":145,"description":438},"glossary/cryptography","dYJMMG8qiUv8fzXujxWh7b-o-qFrKIjzEVP1M5NQqPc",{"id":482,"title":483,"author":146,"body":484,"cta":146,"description":488,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":837,"moment":146,"navigation":476,"path":849,"seo":850,"stem":851,"tags":146,"webcast":462,"__hash__":852},"content_de/glossary/enrollment-methods.md","Enrollment-Methoden",{"type":148,"value":485,"toc":824},[486,489,492,495,524,614,616,620,630,634,652,655,658,662,665,668,691,695,698,701,714,718,721,724,727,730,733,736,744,747,751,755,758,764,768,777,780,783,786,803,814,817,820],[156,487,488],{},"Eine zentrale Eigenschaft von Enrollment-Protokollen für Zertifikate ist deshalb, wie sie den Antragsteller eines Zertifikats authentifizieren. Je nachdem, wofür das Zertifikat verwendet wird, ist das eine oder das andere Protokoll im Vorteil.",[156,490,491],{},"Eine weitere wichtige Eigenschaft ist die praktische Verbreitung. Die Enrollment-Methode oder das Protokoll muss für den vorgesehenen Anwendungsfall sowohl von der CA als auch auf der Clientseite unterstützt werden.",[156,493,494],{},"Die verbreitetsten Enrollment-Protokolle sind:",[175,496,497,503,506,509,515,518,521],{},[178,498,499],{},[245,500,502],{"href":501},"scep","SCEP",[178,504,505],{},"ACME",[178,507,508],{},"EST",[178,510,511],{},[245,512,514],{"href":513},"microsoft-rpc-dcom","RPC/DCOM von Microsoft",[178,516,517],{},"SOAP von Microsoft",[178,519,520],{},"Manuelles Enrollment über die Webseite der CA",[178,522,523],{},"Andere proprietäre Protokolle",[525,526,527,528],"table",{},"\n    ",[529,530,531,527,553,534,574,527,594],"tbody",{},[532,533,534,535,534,538,534,541,534,544,534,547,534,550,527],"tr",{},"\n        ",[536,537],"th",{},[536,539,540],{},"Proprietäres DCOM und RPC von Microsoft",[536,542,543],{},"WS-Trust Enrollment Extension SOAP Enrollment",[536,545,546],{},"Automatic Certificate Management Environment (ACME)",[536,548,549],{},"Simple Certificate Enrollment Protocol (SCEP)",[536,551,552],{},"Enrollment over Secure Transport (EST)",[532,554,534,555,534,559,534,562,534,565,534,568,534,571,527],{},[556,557,558],"td",{},"Spezifikationen",[556,560,561],{},"Microsoft OpenSpec1",[556,563,564],{},"Microsoft OpenSpec2",[556,566,567],{},"RFC 8555",[556,569,570],{},"Informell, jetzt RFC 8894",[556,572,573],{},"RFC 7030 (+ …)",[532,575,534,576,534,579,534,582,534,585,534,588,534,591,527],{},[556,577,578],{},"Implementierung",[556,580,581],{},"Serverseite: Active Directory CS Clientseite: Windows",[556,583,584],{},"Serverseite: ADCS, weitere?  Clientseite: Windows",[556,586,587],{},"Serverseite: Let’s Encrypt Clientseite: viele",[556,589,590],{},"Viele Server- und Client-Implementierungen",[556,592,593],{},"Geringe Verbreitung",[532,595,534,596,534,599,534,602,534,605,534,608,534,611,527],{},[556,597,598],{},"Authentifizierung",[556,600,601],{},"AD-Authentifizierung",[556,603,604],{},"AD-Authentifizierung\\* (formal muss die Kombination aus Benutzername und Passwort nicht im AD liegen)",[556,606,607],{},"DNS-Authentifizierung",[556,609,610],{},"„SCEP Challenge“",[556,612,613],{},"CBA oder HTTP Basic/Digest Authentication",[151,615,502],{"id":501},[168,617,619],{"id":618},"geschichte-und-spezifikation","Geschichte und Spezifikation",[156,621,622,623,629],{},"Cisco hat das Simple Certificate Enrollment Protocol (SCEP) ursprünglich erfunden. Obwohl es damals keinen Standard gab, fand es in MDM-Systemen weite Verbreitung. Cisco ging sogar weiter und entwarf mit Enrollment over Secure Transport (EST) ein Nachfolgeprotokoll, das SCEP ablösen sollte. EST wurde deshalb in RFC 7030 sehr viel früher zu einem öffentlichen Standard als SCEP, das erst deutlich später in ",[245,624,628],{"href":625,"rel":626},"https://www.rfc-editor.org/rfc/rfc8894.html",[627],"nofollow","RFC 8894"," standardisiert wurde, als es für das Zertifikats-Enrollment in MDM-Systemen längst der De-facto-Standard war.",[168,631,633],{"id":632},"technik","Technik",[156,635,636,637,641,642,646,647,651],{},"SCEP setzt auf HTTP auf. Ein SCEP Request ist ein verschlüsseltes und signiertes ",[245,638,640],{"href":639},"important-data-formats#pkcs7","PKCS#7",", das per GET oder POST an den SCEP-Dienst geschickt wird. Der Dienst antwortet mit einer SCEP Response, wiederum einem verschlüsselten und signierten PKCS#7. Die Anfrage enthält eine Zertifikatsanforderung im Format ",[245,643,645],{"href":644},"important-data-formats#pkcs10","PKCS#10",", die Antwort enthält das ausgestellte ",[245,648,650],{"href":649},"important-data-formats#x509","X.509-Zertifikat",".",[168,653,598],{"id":654},"authentifizierung",[156,656,657],{},"Die PKCS#10-Anforderung enthält eine „SCEP Challenge“, die die Signieranfrage über ein Out-of-Band-Verfahren authentifiziert und autorisiert, abhängig vom jeweiligen SCEP-Dienst. In der Praxis sind heute drei Arten von SCEP Challenges im Einsatz:",[413,659,661],{"id":660},"statische-scep-challenge","Statische SCEP Challenge",[156,663,664],{},"Die einfachste Möglichkeit ist eine statische Passphrase. Stimmt die SCEP Challenge im PKCS#10 mit einem im SCEP-Dienst hinterlegten, vordefinierten Wert überein, wird das Zertifikat ausgestellt, andernfalls wird die Anfrage abgelehnt. Das Problem dieser Methode: Es lässt sich so gut wie nicht prüfen, ob die angeforderten Eigenschaften des Zertifikats zum Antragsteller passen. Für dieses Problem gibt es sogar eine CVE.",[156,666,667],{},"Diese Methoden lassen sich weiter unterscheiden:",[261,669,670,678,685],{},[178,671,672,673,677],{},"Bei einem ",[674,675,676],"em",{},"direkten"," SCEP-Enrollment kommuniziert die Instanz, für die das Zertifikat ausgestellt werden soll, unmittelbar mit dem SCEP-Dienst. Beispiel: Ein MDM-System weist ein Android-Telefon an, ein SCEP-Enrollment mit der SCEP Challenge „SecurePassword“ durchzuführen. Das Android-Telefon erzeugt einen CSR, hoffentlich mit den richtigen Werten, und trägt „SecurePassword“ als SCEP Challenge ein. Anschließend schickt es den CSR an den SCEP-Dienst und erhält im Gegenzug das ausgestellte Zertifikat.",[178,679,680,681,684],{},"Ein ",[674,682,683],{},"transparenter SCEP-Proxy"," verhält sich wie ein HTTP-Reverse-Proxy. Weil SCEP verschlüsselt und signiert ist, kann er weder in die SCEP-Anfragen und -Antworten hineinsehen noch sie verändern. Er kann aber anhand von Netzwerkgrenzen steuern, wer wann Zertifikate beziehen darf.",[178,686,680,687,690],{},[674,688,689],{},"SCEP-Proxy als Protokolladapter"," ist ein System, das stellvertretend für ein anderes System Zertifikate über SCEP anfordert. So könnte etwa ein MDM-System wie JAMF im Namen eines iPhones ein Zertifikat bei einem SCEP-Dienst anfordern. Sobald es Zertifikat und privaten Schlüssel hat, kann es das Zertifikat über ein anderes Protokoll ausrollen. Auf diese Weise hat nur das MDM-System Zugriff auf die SCEP Challenge und kann zusätzlich den Inhalt des Zertifikats steuern.",[413,692,694],{"id":693},"dynamische-scep-challenge","Dynamische SCEP Challenge",[156,696,697],{},"In diesem Fall ist jede SCEP Challenge nur für eine einzige Zertifikatsanforderung gültig. Dadurch kann der SCEP-Dienst die SCEP-Anfrage zuordnen und prüfen, ob die angeforderten Eigenschaften des Zertifikats zu den für diese Anfrage zulässigen passen.",[156,699,700],{},"In der Praxis gibt es grundsätzlich zwei Wege, wie sich ein MDM-System und eine SCEP-CA auf eine SCEP Challenge für eine Anfrage verständigen:",[261,702,703,711],{},[178,704,705,706],{},"Das MDM-System fordert beim SCEP-Dienst einen Einmalcode für einen SCEP Request an, wenn es einen benötigt.\n",[261,707,708],{},[178,709,710],{},"Ein Beispiel ist Microsoft NDES. NDES hat eine eigene Admin-Seite, die per AD-Anmeldedaten authentifiziert wird. Bei jedem Aufruf der Admin-Seite erzeugt und zeigt NDES einen neuen Einmalcode, der für genau eine SCEP-Anfrage verwendet werden kann. In dieser Konfiguration prüft NDES allerdings keinerlei Eigenschaften des Zertifikats, da der Einmalcode generisch ist.",[178,712,713],{},"Das MDM-System erzeugt einen Einmalcode, wenn es ein verwaltetes System anweist, ein Zertifikat über SCEP anzufordern. Trifft der SCEP Request beim SCEP-Dienst ein, muss der Dienst den Einmalcode beim MDM-System abrufen, üblicherweise über einen Webhook, und prüfen, ob er zur SCEP Challenge in der Anfrage passt. Für dieses Protokoll gibt es keinen Standard, MDM-System und SCEP-Dienst müssen sich also auf ein Format einigen, und ob Eigenschaften der Anfrage geprüft werden, hängt von der Implementierung ab.",[413,715,717],{"id":716},"signierte-metadaten","Signierte Metadaten",[156,719,720],{},"Für die SCEP Challenge gibt es praktisch keine Längenbeschränkung. Sie muss also keine für Menschen lesbare „Passphrase“ sein, sondern kann auch ein BLOB sein.",[156,722,723],{},"Intune verwendet als SCEP Challenge ein signiertes und verschlüsseltes XML. Es erzeugt dieses XML serverseitig und schickt es an ein Clientgerät, wenn es ein Zertifikat beziehen will und den SCEP Request erstellt.",[156,725,726],{},"Der SCEP-Dienst muss die vollständige PKCS#10-Anforderung an einen Intune SCEP Challenge Service senden. Der SCEP Challenge Service besitzt den privaten Schlüssel, um das XML zu entschlüsseln, und den öffentlichen Schlüssel, um zu prüfen, dass es von einem echten Intune-Dienst erzeugt wurde.",[156,728,729],{},"Das XML enthält Metadaten zur Anfrage, etwa wie der Subject aussehen soll. Diese leiten sich zum einen aus dem SCEP-Konfigurationsprofil ab und zum anderen aus den konkreten Objektdaten des Benutzers oder Geräts, für den oder das das Zertifikat ausgestellt werden soll.",[156,731,732],{},"Beispiel: Im SCEP-Konfigurationsprofil kann CN={{DeviceId}} als Subject konfiguriert sein. Fordert das Gerät mit der ID xyz ein Zertifikat an, steht im XML, dass der Subject CN=xyz lauten soll. Der SCEP Challenge Service vergleicht dann die Angaben aus dem XML mit dem Subject in der PKCS#10-Anforderung. Unterscheiden sich die Subjects, schlägt die Prüfung fehl. Stimmen sie und die übrigen Eigenschaften überein, ist die Prüfung erfolgreich.",[156,734,735],{},"Der SCEP-Dienst stellt das Zertifikat nur aus, wenn die Prüfung erfolgreich ist.",[156,737,738,739,651],{},"Microsoft erklärt diese Prüfung in ",[245,740,743],{"href":741,"rel":742},"https://learn.microsoft.com/en-us/mem/intune/protect/certificate-authority-add-scep-overview#overview",[627],"einem Artikel",[156,745,746],{},"Microsoft NDES unterstützt das über ein zusätzliches NDES Policy Module, andere SCEP-CAs unterstützen es nativ oder eben nicht.",[151,748,750],{"id":749},"microsoft-rpcdcom","Microsoft RPC/DCOM",[168,752,754],{"id":753},"geschichte","Geschichte",[156,756,757],{},"Die Microsoft Active Directory Certificate Services (ADCS), manchmal auch nur „Microsoft CA“ genannt, sind die in Windows Server eingebaute Software für eine Zertifizierungsstelle. Die Software entstand ursprünglich am Ende des letzten Jahrtausends und wurde in den folgenden zehn bis fünfzehn Jahren noch um einiges ergänzt.",[156,759,760,761,763],{},"Eine Alternative ist SOAP von Microsoft oder ",[245,762,502],{"href":501},", die Microsoft Web Enrollment beziehungsweise NDES nennt.",[168,765,767],{"id":766},"spezifikation-und-verbreitung","Spezifikation und Verbreitung",[156,769,770,771,776],{},"Uns ist kein anderes CA-System bekannt, das dieses Protokoll implementiert, auch wenn Microsoft inzwischen ",[245,772,775],{"href":773,"rel":774},"https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-cersod/dd034cb3-99fc-4c10-92c8-1fbeb4788183",[627],"die Spezifikation in Microsoft OpenSpec"," veröffentlicht hat. Auf der Clientseite unterstützt Windows das Protokoll von Haus aus, andere Plattformen werden nicht unterstützt.",[168,778,633],{"id":779},"technik-1",[156,781,782],{},"Die wichtigste Enrollment-Methode ist ein proprietäres Protokoll auf Basis von RPC oder DCOM.",[156,784,785],{},"Auch das Autoenrollment nutzt dieses Protokoll. Damit Autoenrollment funktioniert, brauchst du",[175,787,788,791,794,797,800],{},[178,789,790],{},"ein in die Domäne eingebundenes Gerät.",[178,792,793],{},"Eine Gruppenrichtlinie, die Autoenrollment aktiviert,",[178,795,796],{},"eine Enterprise CA (im Unterschied zu einer Stand-alone-CA),",[178,798,799],{},"die ein Certificate Template ausstellt, für das",[178,801,802],{},"der Benutzer oder das Gerät die Berechtigungen für Enrollment und Autoenrollment besitzt.",[156,804,805,806,810,811,651],{},"Standardmäßig wird alle 8 Stunden auf Autoenrollments geprüft, erzwingen lässt sich das aber mit ",[807,808,809],"code",{},"certutil -pulse"," oder oft besser mit ",[807,812,813],{},"gpupdate -force",[168,815,598],{"id":816},"authentifizierung-1",[156,818,819],{},"Dieses Protokoll nutzt die in Active Directory eingebauten Authentifizierungsprotokolle, Benutzer und Computer authentifizieren sich also mit ihren AD-Anmeldedaten.",[821,822,823],"style",{},"\n    table {border: 2px solid white}\n    th, td {border: solid black; padding-left: 1em; padding-right: 1em; font-size: smaller}\n",{"title":438,"searchDepth":439,"depth":439,"links":825},[826,831],{"id":501,"depth":439,"text":502,"children":827},[828,829,830],{"id":618,"depth":444,"text":619},{"id":632,"depth":444,"text":633},{"id":654,"depth":444,"text":598},{"id":749,"depth":439,"text":750,"children":832},[833,834,835,836],{"id":753,"depth":444,"text":754},{"id":766,"depth":444,"text":767},{"id":779,"depth":444,"text":633},{"id":816,"depth":444,"text":598},{"lang":465,"seoTitle":838,"titleClass":466,"socialimg":839,"blogtitlepic":840,"customExcerpt":841,"keywords":842,"asideNav":843,"maxContent":476},"Enrollment-Methoden für Zertifikate - SCEP, ACME, EST & Microsoft RPC","/blog/heads/header-scepman-enrollment-methods.png","header-scepman-enrollment-methods.png","Erfahre, wie das Enrollment von Zertifikaten mit SCEP, ACME, EST, Microsoft RPC und manuellen Verfahren funktioniert. Vergleiche die Enrollment-Protokolle einer PKI für die sichere Ausstellung von Zertifikaten.","Enrollment-Methoden für Zertifikate, SCEP, ACME, EST, Microsoft RPC, Enrollment-Protokoll für Zertifikate, Zertifikats-Enrollment in der PKI, Enrollment over Secure Transport, Simple Certificate Enrollment Protocol, Automatic Certificate Management Environment, Microsoft Zertifikats-Enrollment",{"menuItems":844},[845,847],{"href":846,"text":502},"#scep",{"href":848,"text":750},"#microsoft-rpcdcom","/glossary/enrollment-methods",{"title":483,"description":488},"glossary/enrollment-methods","qzFaGMyCuxfp8CZN4sxhHqOMMPjPmewusnlo3qkSs9Q",{"id":854,"title":855,"author":146,"body":856,"cta":146,"description":438,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":1089,"moment":146,"navigation":476,"path":1107,"seo":1108,"stem":1109,"tags":146,"webcast":462,"__hash__":1110},"content_de/glossary/important-data-formats.md","Wichtige Datenformate",{"type":148,"value":857,"toc":1072},[858,862,881,888,891,895,899,902,905,908,912,915,919,922,925,933,936,940,947,950,953,956,967,971,984,988,991,994,997,1000,1008,1012,1015,1018,1021,1032,1036,1039,1043,1052,1055,1063,1066],[151,859,861],{"id":860},"x509","X.509",[156,863,864,865,868,869,874,875,880],{},"X.509 ist ",[674,866,867],{},"der"," Standard für digitale Zertifikate. Früher gab es einige Konkurrenten wie ",[245,870,873],{"href":871,"rel":872},"https://www.rfc-editor.org/rfc/rfc4880",[627],"OpenPGP",", sie werden heute aber deutlich seltener eingesetzt. Doch halt ... X.509 ist eigentlich gar nicht der richtige Standard. X.509 ist genau genommen ein ITU-T-Standard, während die Definitionen, auf die es wirklich ankommt, Teil von ",[245,876,879],{"href":877,"rel":878},"https://www.rfc-editor.org/rfc/rfc5280",[627],"RFC 5280"," sind, also eines Standards der IETF und nicht der ITU-T. Der RFC definiert auf Basis von X.509 das „PKI Profile for the Internet“, und das ist das einzige Profil, das in der Praxis wirklich zählt.",[156,882,883,884,887],{},"Ein digitales Zertifikat nutzt asymmetrische Kryptografie und vor allem digitale Signaturen. Der häufigste Anwendungsfall für digitale Zertifikate ist heute die Serverauthentifizierung. Jeder hat sie schon einmal benutzt, vermutlich meist ohne zu wissen, dass es sich um ein X.509-Zertifikat handelte: Jedes Mal, wenn du eine HTTP",[160,885,886],{},"S","-Website aufrufst, baut der Browser eine TLS-Verbindung zum Webserver auf. Der Webserver weist sich mit einem X.509-Zertifikat aus. Wenn Menschen zum Beispiel die Website ihrer Bank aufrufen, um Geld von ihrem Konto zu überweisen, wollen sie sicher sein, dass sie tatsächlich mit ihrer Bank kommunizieren. Angreifer könnten versuchen, die Website der Bank nachzuahmen, das Passwort und die TAN der Benutzer mitzulesen und das Geld anschließend auf ein eigenes Konto zu überweisen. HTTPS hilft, das zu verhindern, denn die Angreifer haben das X.509-Zertifikat des Webservers der Bank nicht. Wenn der Browser anzeigt, dass du eine bestimmte Domain über eine HTTPS-Verbindung aufrufst, stellt das Zertifikat sicher, dass du wirklich mit einem Webserver des Domaininhabers verbunden bist.",[156,889,890],{},"Wie schafft das Zertifikat das? Das Zertifikat enthält einige Metadaten, den öffentlichen Schlüssel eines kryptografischen Schlüsselpaars und eine Signatur einer Zertifizierungsstelle. Gehen wir die drei Teile durch:",[168,892,894],{"id":893},"inhalt-eines-x509-zertifikats","Inhalt eines X.509-Zertifikats",[413,896,898],{"id":897},"metadaten","Metadaten",[156,900,901],{},"Die Metadaten des X.509-Zertifikats legen unter anderem fest, in welchem Zeitraum es gültig ist, wofür das Zertifikat verwendet werden darf und an wen es ausgestellt wurde. Bei einem TLS-Serverzertifikat enthalten sie insbesondere die Domain des Webservers. Der Browser vergleicht die aufgerufene Domain mit der im Zertifikat. Stimmen sie nicht überein, bricht der Browser ab und zeigt eine Warnung. Ist das Zertifikat abgelaufen, zeigt er ebenfalls eine Warnung.",[156,903,904],{},"Kurioserweise zeigten Browser oft keine Warnung, wenn du eine HTTP-Seite ohne TLS aufgerufen hast, obwohl das noch unsicherer ist. Rufst du einen Webserver mit einem ungültigen X.509-Zertifikat auf, kann es sich schlicht um eine Fehlkonfiguration handeln, und du bist womöglich trotzdem davor geschützt, dass Angreifer deine Verbindung mitlesen, während eine HTTP-Verbindung überhaupt keinen Schutz bietet.",[156,906,907],{},"Es gibt hier allerdings Fortschritte, zum Beispiel Certificate Pinning. Das ist aber ein fortgeschrittenes Thema, sehen wir uns also die beiden anderen Bestandteile eines X.509-Zertifikats an.",[413,909,911],{"id":910},"öffentlicher-schlüssel","Öffentlicher Schlüssel",[156,913,914],{},"Das Zertifikat enthält den öffentlichen Teil eines asymmetrischen Schlüsselpaars. Die Kryptografie erlaubt es dem Webserver (oder allgemein dem Zertifikatsinhaber, wenn es ein anderer Anwendungsfall ist), nachzuweisen, dass er auch den privaten Teil des Schlüsselpaars besitzt, ohne ihn dem verbindenden Client oder sonst jemandem preiszugeben. Der Client kann also sicher sein, dass der Webserver tatsächlich der Inhaber des Zertifikats ist und nicht bloß jemand, der es kopiert hat. Das Zertifikat selbst zu kopieren, ist nämlich ziemlich einfach, denn der Webserver schickt jedem, der eine Verbindung aufbauen will, eine Kopie davon. Den privaten Schlüssel zu stehlen, ist dagegen schwierig oder unmöglich, denn er verlässt den Webserver nie. Es gibt verschiedene Methoden, den Diebstahl des privaten Schlüssels zusätzlich zu erschweren, etwa HSMs und TPMs.",[413,916,918],{"id":917},"signatur-durch-eine-zertifizierungsstelle","Signatur durch eine Zertifizierungsstelle",[156,920,921],{},"Anhand der Metadaten kann der Client prüfen, ob das Zertifikat für den konkreten Anwendungsfall geeignet ist. Der öffentliche Schlüssel zeigt, dass die Gegenstelle tatsächlich Inhaber des Zertifikats ist. Ein Angreifer könnte aber einfach ein neues Schlüsselpaar und ein neues Zertifikat erzeugen, die diese beiden Kriterien ebenfalls erfüllen. Woher weiß ein Client also, dass das Zertifikat vertrauenswürdig ist?",[156,923,924],{},"Das Zertifikat enthält eine kryptografische Signatur eines anderen Schlüsselpaars, das zum Zertifikat einer Zertifizierungsstelle (Certification Authority, CA) gehört. Das CA-Zertifikat lässt sich auf dieselbe Weise prüfen und ist ebenfalls von einem Zertifikat signiert. Der Client kann dieser „Vertrauenskette“ vom sogenannten Blattzertifikat bis zum Zertifikat der Root CA folgen, das er daran erkennt, dass es selbstsigniert ist, seine Signatur also aus dem eigenen Schlüsselpaar stammt. Üblicherweise sind das nur ein oder zwei Schritte, es sind also nur ein oder zwei CA-Zertifikate beteiligt.",[156,926,927,928,932],{},"CAs müssen sorgfältig prüfen, ob die Metadaten korrekt sind, wenn sie ",[245,929,931],{"href":930},"enrollment-methods/","ein Zertifikat ausstellen",". Willst du zum Beispiel ein TLS-Serverzertifikat für deine eigene Domain, musst du der CA nachweisen, dass du wirklich der Inhaber bist. Je nachdem, wie gründlich diese Prüfung ausfällt, bekommst du ein einfaches Zertifikat oder ein Zertifikat mit Extended Validation (EV).",[156,934,935],{},"Jeder Browser und jedes Betriebssystem bringt eine Liste vordefinierter vertrauenswürdiger Root CAs mit. Benutzer und Administratoren können weitere vertrauenswürdige Root CAs hinzufügen. Manchen Root CAs wird nur für bestimmte Zwecke vertraut, anderen umfassender. Der Client prüft, ob die Vertrauenskette bei einer vertrauenswürdigen Root CA endet. Ist das der Fall, sind alle Zertifikate der Vertrauenskette noch gültig und sagen die Metadaten, dass sie ihrem Zweck entsprechend verwendet werden, dann gilt das Blattzertifikat des Webservers als vertrauenswürdig und die Verbindung wird aufgebaut.",[168,937,939],{"id":938},"gültigkeit-von-x509-zertifikaten","Gültigkeit von X.509-Zertifikaten",[156,941,942,943,651],{},"Bei X.509-Zertifikaten dreht sich alles um Vertrauen, das erst hergestellt werden muss. Wie beschrieben ist ein Kriterium für dieses Vertrauen, dass sich ein Zertifikat bis zu einer vertrauenswürdigen Root CA zurückverfolgen lässt. Ein weiteres ist, dass es sich innerhalb seines Gültigkeitszeitraums befindet. Meist heißt das, dass es nicht abgelaufen ist, aber, üblicherweise wegen technischer Fehler, kann ein Zertifikat auch noch nicht gültig sein. Es gibt aber noch ein Kriterium: Die ausstellende CA darf das Zertifikat nicht gesperrt haben. Weil das ein Thema für sich ist, haben wir dazu einen ",[245,944,946],{"href":945},"other-stuff/certificate-lifecycle-management","eigenen Artikel",[151,948,640],{"id":949},"pkcs7",[156,951,952],{},"PKCS#7 ist das Schweizer Taschenmesser unter den kryptografischen Datenformaten und kann praktisch alles enthalten: verschlüsselte Nachrichten, signierte Nachrichten, signierte und verschlüsselte Nachrichten, Zertifikate und private Schlüssel",[156,954,955],{},"Das ist zugleich der größte Nachteil dieses Formats. Bekommt eine Anwendung oder ein Benutzer ein PKCS#7, ist daraus allein nicht ersichtlich, was damit zu tun ist. Hier einige wichtige Anwendungsfälle:",[175,957,958,961,964],{},[178,959,960],{},"S/MIME-Nachrichten sind im Kern E-Mails mit PKCS#7 als Body oder Anhang.",[178,962,963],{},"SCEP-Anfragen und -Antworten sind beide tatsächlich signierte PKCS#7-Nachrichten.",[178,965,966],{},"EST-Antworten sind CMS-Nachrichten.",[168,968,970],{"id":969},"kodierung","Kodierung",[156,972,973,974,978,979,983],{},"Gängige Dateiendungen sind .p7b (",[245,975,977],{"href":976},"asn.1-and-pem#der-encoding","DER-kodiert","), .p7s (eine signierte Nachricht oder eine Nachrichtensignatur) und .p7m (eine signierte und/oder verschlüsselte Nachricht). Die ",[245,980,982],{"href":981},"asn.1-and-pem#pem-encoding","PEM-Kodierung"," mit dem Label „PKCS7“ ist ebenfalls definiert, wird aber selten verwendet.",[168,985,987],{"id":986},"tools","Tools",[156,989,990],{},"Unter Windows kannst du PKCS#7-Nachrichten mit einem Doppelklick öffnen, die Crypto Shell Extensions zeigen sie dir dann an. Allerdings lassen sich daraus in der Regel nur Zertifikate und ihre privaten Schlüssel extrahieren, nicht aber die Nachrichteninhalte.",[156,992,993],{},"Mit Tools wie OpenSSL kannst du diese Dateien in andere Formate umwandeln.",[151,995,645],{"id":996},"pkcs10",[156,998,999],{},"Eine Zertifikatsanforderung (Certificate Signing Request, CSR) nach PKCS#10 ist eine Datei mit der Beschreibung eines Zertifikats, das du von einer Zertifizierungsstelle (Certification Authority, CA) beziehen möchtest. Sie ist ähnlich aufgebaut wie ein X.509-Zertifikat, es fehlt jedoch die Signatur einer CA. Stattdessen enthält sie die Signatur des Antragstellers. Es ist trotzdem ein anderes Format, eine Zertifikatsanforderung ist also nicht dasselbe wie ein selbstsigniertes Zertifikat.",[156,1001,1002,1003,651],{},"Sie kann binär DER-kodiert oder PEM-kodiert sein, ",[245,1004,1007],{"href":1005,"rel":1006},"https://datatracker.ietf.org/doc/html/rfc7468#section-7",[627],"dann mit dem Label „CERTIFICATE REQUEST“",[151,1009,1011],{"id":1010},"pkcs12","PKCS#12",[156,1013,1014],{},"PKCS#12 ist vor allem in Windows-Umgebungen auch als PFX bekannt. Gängige Dateiendungen sind daher .pfx und .p12. Es enthält X.509-Zertifikate und fast immer die zugehörigen privaten Schlüssel, technisch erzwungen ist das allerdings nicht.",[156,1016,1017],{},"Daten in einer PKCS#12-Datei sind üblicherweise mit Passwörtern verschlüsselt. Oft ist nur der private Schlüssel verschlüsselt, du könntest die Zertifikate also ohne Kenntnis der Passwörter extrahieren, sofern deine Anwendung das zulässt (die meisten tun das nicht). In Windows-Umgebungen ist PKCS#12 der gängigste Weg, ein Zertifikat und seinen privaten Schlüssel in einer Datei abzulegen. In Linux-Umgebungen sind PEM-kodierte PKCS#8-Dateien verbreiteter.",[156,1019,1020],{},"Weil der Standard viele Möglichkeiten vorsieht, Zertifikate und private Schlüssel in verschachtelten „Safebags“ abzulegen, haben PKCS#12-Dateien einige Kompatibilitätsprobleme, zum Beispiel:",[175,1022,1023,1026,1029],{},[178,1024,1025],{},"Windows ist dafür berüchtigt, private Schlüssel aus einem PKCS#12 allen aus der Datei extrahierten Zertifikaten zuzuordnen und nicht nur dem, zu dem sie gehören. Enthält das PKCS#12 eine Zertifikatskette, zeigt Windows womöglich an, dass es den privaten Schlüssel zum CA-Zertifikat besitzt.",[178,1027,1028],{},"Unter macOS kannst du PKCS#12-Dateien nicht importieren, wenn die kryptografischen Algorithmen zu neu sind.",[178,1030,1031],{},"Unter Umständen musst du die Zertifikate in einer PKCS#12-Datei verschlüsseln, damit empfangende Anwendungen sie extrahieren können. Manche unterstützen jedoch nur sehr alte und schwache Algorithmen, was normalerweise kein Problem ist, da die Informationen ohnehin öffentlich sind. OpenSSL 3.x unterstützt diese alten und angreifbaren Algorithmen aber nicht und weigert sich, das PKCS#12 zu öffnen.",[151,1033,1035],{"id":1034},"asn1-und-pem","ASN.1 und PEM",[156,1037,1038],{},"Die Abstract Syntax Notation One (ASN.1) ist eine Sprache zur Beschreibung von Datenstrukturen. Es gibt einige vordefinierte Basisdatentypen wie Integer oder Sequenzen, aus denen der Autor eines Protokolls oder Dateiformats dann eigene Datentypen definieren kann.",[168,1040,1042],{"id":1041},"der-kodierung","DER-Kodierung",[156,1044,1045,1046,1051],{},"Der ",[245,1047,1050],{"href":1048,"rel":1049},"https://www.itu.int/rec/T-REC-X.680/",[627],"ITU-T-Standard X.680"," definiert verschiedene Kodierungen für Daten, die als ASN.1 spezifiziert sind. Für X.509-bezogene Daten ist DER die wichtigste Kodierung, denn es gibt jeweils nur einen Weg, einen Typ zu kodieren. Ein Hash über die binäre DER-Darstellung des Typs hat damit immer denselben Wert, was zum Beispiel beim Signieren ASN.1-kodierter Daten wichtig ist.",[168,1053,982],{"id":1054},"pem-kodierung",[156,1056,1057,1058,1062],{},"Für viele, aber nicht alle X.509-bezogenen Dateitypen kannst du die Datei entweder binär in DER-Kodierung speichern oder zusätzlich eine ",[245,1059,982],{"href":1060,"rel":1061},"https://datatracker.ietf.org/doc/html/rfc7468",[627]," über die DER-Kodierung legen. PEM verwendet ausschließlich ASCII-Zeichen und lässt sich deshalb leicht über die Zwischenablage kopieren und einfügen oder, als das vor einigen Jahrzehnten noch relevant war, per E-Mail verschicken.",[168,1064,987],{"id":1065},"tools-1",[156,1067,1068,1069,651],{},"Hast du eine ASN.1-kodierte Datei und weißt entweder nicht, um welchen Typ es sich handelt, oder hast keine Anwendung für diesen konkreten Typ, kannst du die rohe ASN.1-Struktur trotzdem dekodieren und dir ansehen, was darin steht. Unter Windows kann das eingebaute Werkzeug certutil das mit dem Befehl ",[807,1070,1071],{},"certutil -decode",{"title":438,"searchDepth":439,"depth":439,"links":1073},[1074,1078,1082,1083,1084],{"id":860,"depth":439,"text":861,"children":1075},[1076,1077],{"id":893,"depth":444,"text":894},{"id":938,"depth":444,"text":939},{"id":949,"depth":439,"text":640,"children":1079},[1080,1081],{"id":969,"depth":444,"text":970},{"id":986,"depth":444,"text":987},{"id":996,"depth":439,"text":645},{"id":1010,"depth":439,"text":1011},{"id":1034,"depth":439,"text":1035,"children":1085},[1086,1087,1088],{"id":1041,"depth":444,"text":1042},{"id":1054,"depth":444,"text":982},{"id":1065,"depth":444,"text":987},{"lang":465,"seoTitle":1090,"titleClass":466,"blogtitlepic":1091,"socialimg":1092,"customExcerpt":1093,"keywords":1094,"asideNav":1095,"maxContent":476},"Wichtige Datenformate - X.509, PKCS, ASN.1 und PEM erklärt","header-scepman-important-data-formats.png","/blog/heads/header-scepman-important-data-formats.png","Lerne die wichtigsten Formate der Kryptografie und von Zertifikaten kennen: X.509, PKCS 7, PKCS 10, PKCS 12, ASN.1 und PEM.","wichtige Datenformate, X.509-Zertifikat, PKCS-Formate, PKCS 7, PKCS 10, PKCS 12, ASN.1, PEM-Format, digitale Zertifikate, Public Key Infrastructure, PKI-Formate",{"menuItems":1096},[1097,1099,1101,1103,1105],{"href":1098,"text":861},"#x509",{"href":1100,"text":640},"#pkcs7",{"href":1102,"text":645},"#pkcs10",{"href":1104,"text":1011},"#pkcs12",{"href":1106,"text":1035},"#asn1-und-pem","/glossary/important-data-formats",{"title":855,"description":438},"glossary/important-data-formats","LV4zD9CzrdD-P5cbga39rOJHfXKHpfnZtPCT9XyySRs",{"id":1112,"title":1113,"author":146,"body":1114,"cta":146,"description":438,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":1337,"moment":146,"navigation":476,"path":1343,"seo":1344,"stem":1345,"tags":146,"webcast":462,"__hash__":1346},"content_de/glossary/public-key-infrastructure.md","Public Key Infrastructure",{"type":148,"value":1115,"toc":1326},[1116,1120,1128,1131,1163,1167,1170,1174,1177,1207,1210,1214,1217,1237,1240,1244,1251,1265,1270,1284,1288,1293,1306,1311,1323],[151,1117,1119],{"id":1118},"vertrauen-herstellen","Vertrauen herstellen",[168,1121,1123,1124,1127],{"id":1122},"wie-zeigt-ein-client-sein-vertrauen-in-eine-bestimmte-root-ca-an","Wie ",[160,1125,1126],{},"zeigt"," ein Client sein Vertrauen in eine bestimmte Root CA an?",[156,1129,1130],{},"Ein Client zeigt sein Vertrauen in eine bestimmte Root-Zertifizierungsstelle (Certificate Authority, CA) über einen Prozess an, an dem die Vertrauenskette der Zertifikate beteiligt ist. So funktioniert es:",[175,1132,1133,1139,1145,1151,1157],{},[178,1134,1135,1138],{},[160,1136,1137],{},"Vorinstallierte Stammzertifikate:"," Die meisten Betriebssysteme und Webbrowser bringen eine Reihe vorinstallierter Stammzertifikate vertrauenswürdiger CAs mit. Diese Stammzertifikate liegen in einem vertrauenswürdigen Zertifikatsspeicher.",[178,1140,1141,1144],{},[160,1142,1143],{},"Prüfung des Zertifikats:"," Verbindet sich ein Client mit einem Server, etwa beim Aufruf einer Website, legt der Server sein TLS-Zertifikat vor. Dieses Zertifikat ist typischerweise von einer Intermediate CA signiert, die ihrerseits von einer Root CA signiert ist.",[178,1146,1147,1150],{},[160,1148,1149],{},"Prüfung der Vertrauenskette:"," Der Client prüft die Vertrauenskette, indem er kontrolliert, ob das vorgelegte Zertifikat von einer vertrauenswürdigen Root CA signiert ist. Außerdem prüft er, ob den Intermediate CAs in der Kette vertraut wird.",[178,1152,1153,1156],{},[160,1154,1155],{},"Digitale Signaturen:"," Jedes Zertifikat in der Kette ist von der darüberliegenden CA digital signiert. Der Client prüft diese Signaturen mit dem öffentlichen Schlüssel der CA und stellt so sicher, dass die Zertifikate nicht manipuliert wurden.",[178,1158,1159,1162],{},[160,1160,1161],{},"Vertrauensentscheidung:"," Ist die gesamte Vertrauenskette gültig und führt sie zurück zu einer vertrauenswürdigen Root CA, vertraut der Client dem Zertifikat des Servers. Die sichere Kommunikation kann dann fortgesetzt werden.",[168,1164,1166],{"id":1165},"welchen-vorteil-bieten-intermediate-cas-gegenüber-einer-einzelnen-root-ca","Welchen Vorteil bieten Intermediate CAs gegenüber einer einzelnen Root CA?",[156,1168,1169],{},"Für Infrastruktur-PKIs kann eine einzelne Root durchaus von Vorteil sein.",[168,1171,1173],{"id":1172},"wie-bekommt-eine-intermediate-ca-ihr-zertifikat","Wie bekommt eine Intermediate CA ihr Zertifikat?",[156,1175,1176],{},"Eine Intermediate-Zertifizierungsstelle (Certificate Authority, CA) erhält ihr Zertifikat über ein Verfahren, das Cross-Signing durch eine Root CA genannt wird. So funktioniert es:",[261,1178,1179,1185,1191,1196,1201],{},[178,1180,1181,1184],{},[160,1182,1183],{},"Zertifikatsanforderung (Certificate Signing Request, CSR):"," Die Organisation, die eine Intermediate CA aufbauen will, erzeugt einen CSR. Dieser CSR enthält den öffentlichen Schlüssel und die Identitätsangaben der Intermediate CA.",[178,1186,1187,1190],{},[160,1188,1189],{},"Einreichung bei der Root CA:"," Der CSR wird bei einer vertrauenswürdigen Root CA eingereicht.",[178,1192,1193,1195],{},[160,1194,365],{}," Die Root CA prüft Identität und Legitimität der Organisation, die das Intermediate-Zertifikat beantragt.",[178,1197,1198,1200],{},[160,1199,353],{}," Nach erfolgreicher Prüfung signiert die Root CA den CSR mit ihrem privaten Schlüssel und erzeugt so das Intermediate-Zertifikat. Dieses signierte Zertifikat verbindet die Intermediate CA mit der Root CA und stellt damit eine Vertrauenskette her.",[178,1202,1203,1206],{},[160,1204,1205],{},"Ausstellung:"," Die Root CA stellt der beantragenden Organisation das signierte Intermediate-Zertifikat aus, die damit anschließend Endzertifikate signieren kann, etwa TLS-Zertifikate für Websites.",[156,1208,1209],{},"Dieses Verfahren stellt sicher, dass der Intermediate CA aufgrund ihrer Verbindung zur Root CA vertraut wird, der Browser und Betriebssysteme bereits vertrauen.",[168,1211,1213],{"id":1212},"was-ist-eine-zertifikatskette-wie-funktioniert-sie","Was ist eine Zertifikatskette? Wie funktioniert sie?",[156,1215,1216],{},"Eine Zertifikatskette, auch Vertrauenskette genannt, ist eine Abfolge von Zertifikaten, die Authentizität und Vertrauenswürdigkeit eines digitalen Zertifikats sicherstellt. So funktioniert sie:",[175,1218,1219,1225,1231],{},[178,1220,1221,1224],{},[160,1222,1223],{},"Prüfvorgang:"," Verbindet sich ein Client wie ein Webbrowser mit einem Server, legt der Server sein Endzertifikat vor. Der Client prüft dann die Zertifikatskette und stellt sicher, dass jedes Zertifikat vom jeweils nächsten Zertifikat der Kette signiert ist, bis hinauf zum Stammzertifikat.",[178,1226,1227,1230],{},[160,1228,1229],{},"Vertrauenskette:"," Jedes Zertifikat der Kette wird mit dem öffentlichen Schlüssel des darüberliegenden Zertifikats geprüft. Das geht so weiter bis zum Stammzertifikat, dem der Client bereits vertraut.",[178,1232,1233,1236],{},[160,1234,1235],{},"Vertrauen herstellen:"," Ist die gesamte Kette gültig und führt sie zurück zu einem vertrauenswürdigen Stammzertifikat, vertraut der Client dem Endzertifikat und die sichere Kommunikation kann fortgesetzt werden.",[156,1238,1239],{},"Dieses System stellt sicher, dass das Endzertifikat legitim ist und von einer vertrauenswürdigen Stelle ausgestellt wurde. So bleiben Integrität und Sicherheit der digitalen Kommunikation gewahrt.",[168,1241,1243],{"id":1242},"welches-problem-soll-die-erweiterung-basic-constraints-lösen","Welches Problem soll die Erweiterung Basic Constraints lösen?",[156,1245,1246,1247,1250],{},"Die Erweiterung ",[160,1248,1249],{},"Basic Constraints"," in einem digitalen Zertifikat löst das Problem, verschiedene Arten von Zertifikaten und ihre Rollen innerhalb einer Public Key Infrastructure (PKI) voneinander zu unterscheiden. So funktioniert es:",[175,1252,1253,1259],{},[178,1254,1255,1258],{},[160,1256,1257],{},"Kennzeichnung als Zertifizierungsstelle (CA):"," Sie legt fest, ob ein Zertifikat ein CA-Zertifikat oder ein Endzertifikat ist. Diese Unterscheidung ist entscheidend, denn CA-Zertifikate können weitere Zertifikate ausstellen, Endzertifikate dagegen nicht.",[178,1260,1261,1264],{},[160,1262,1263],{},"Beschränkung der Pfadlänge:"," Sie kann die Anzahl der Intermediate CAs begrenzen, die in der Zertifikatskette unterhalb dieser CA liegen dürfen. Das verhindert übermäßig lange Zertifikatsketten, die ineffizient und potenziell unsicher sind.",[156,1266,1267],{},[160,1268,1269],{},"Gelöste Probleme:",[175,1271,1272,1278],{},[178,1273,1274,1277],{},[160,1275,1276],{},"Unberechtigte Ausstellung von Zertifikaten verhindern:"," Indem klar gekennzeichnet ist, welche Zertifikate als CA auftreten dürfen, wird verhindert, dass Endzertifikate weitere Zertifikate ausstellen. Das wahrt die Integrität der PKI.",[178,1279,1280,1283],{},[160,1281,1282],{},"Länge der Zertifikatskette begrenzen:"," Die Begrenzung der Pfadlänge sorgt dafür, dass die Zertifikatskette überschaubar und sicher bleibt, und beugt möglichen Schwachstellen durch lange Ketten vor",[168,1285,1287],{"id":1286},"mit-welchen-mechanismen-löst-sie-diese-probleme"," Mit welchen Mechanismen löst sie diese Probleme?",[156,1289,1246,1290,1292],{},[160,1291,1249],{}," in einem digitalen Zertifikat nutzt die folgenden Mechanismen, um CA-Zertifikate von Endzertifikaten zu unterscheiden und die Länge der Zertifikatskette zu begrenzen:",[175,1294,1295,1301],{},[178,1296,1297,1300],{},[160,1298,1299],{},"CA-Flag:"," Dieses Flag gibt an, ob das Zertifikat ein Zertifikat einer Zertifizierungsstelle (Certificate Authority, CA) oder ein Endzertifikat ist. Steht das Flag auf TRUE, kann das Zertifikat andere Zertifikate signieren, es ist also ein CA-Zertifikat. Steht es auf FALSE, ist es ein Endzertifikat und kann keine weiteren Zertifikate ausstellen.",[178,1302,1303,1305],{},[160,1304,1263],{}," Sie gibt an, wie viele nicht selbst ausgestellte Intermediate-Zertifikate diesem Zertifikat in einem gültigen Zertifizierungspfad höchstens folgen dürfen. Mit dieser Beschränkung begrenzt die Erweiterung die Länge der Zertifikatskette und sorgt dafür, dass sie überschaubar und sicher bleibt.",[156,1307,1308],{},[160,1309,1310],{},"So arbeiten diese Mechanismen:",[175,1312,1313,1318],{},[178,1314,1315,1317],{},[160,1316,1299],{}," Bei der Ausstellung eines Zertifikats wird das CA-Flag entsprechend dem vorgesehenen Verwendungszweck gesetzt. Bei der Prüfung eines Zertifikats kontrollieren Clients dieses Flag, um zu entscheiden, ob dem Zertifikat die Ausstellung weiterer Zertifikate zugetraut werden darf.",[178,1319,1320,1322],{},[160,1321,1263],{}," Dieser Wert wird während der Prüfung kontrolliert, um sicherzustellen, dass die Zertifikatskette die angegebene Länge nicht überschreitet. Ist die Kette zu lang, gilt das Zertifikat als ungültig.",[156,1324,1325],{},"Diese Mechanismen tragen dazu bei, Integrität und Sicherheit der Public Key Infrastructure (PKI) zu wahren, indem nur berechtigte Zertifikate weitere Zertifikate ausstellen dürfen und übermäßig lange Zertifikatsketten verhindert werden.",{"title":438,"searchDepth":439,"depth":439,"links":1327},[1328],{"id":1118,"depth":439,"text":1119,"children":1329},[1330,1332,1333,1334,1335,1336],{"id":1122,"depth":444,"text":1331},"Wie zeigt ein Client sein Vertrauen in eine bestimmte Root CA an?",{"id":1165,"depth":444,"text":1166},{"id":1172,"depth":444,"text":1173},{"id":1212,"depth":444,"text":1213},{"id":1242,"depth":444,"text":1243},{"id":1286,"depth":444,"text":1287},{"lang":465,"seoTitle":1338,"titleClass":466,"socialimg":1339,"blogtitlepic":1340,"customExcerpt":1341,"keywords":1342,"maxContent":476},"Vertrauen in einer Public Key Infrastructure herstellen: Vertrauensmodell für PKI-Zertifikate","/blog/heads/header-scepman-public-key-infrastructure.png","header-scepman-public-key-infrastructure.png","Vertrauen in einer PKI herstellen, mit Zertifikatsketten, Root und Intermediate CAs und sicherer Prüfung von Zertifikaten.","Vertrauen in der PKI herstellen, Vertrauen in einer Public Key Infrastructure, Vertrauenskette von Zertifikaten, Vertrauen in die Root CA, Vertrauen in die Intermediate CA, PKI-Vertrauensmodell, Prüfung von Zertifikaten, vertrauenswürdige Stammzertifikate, sichere Verifizierung von Zertifikaten, Prüfung der Vertrauenskette","/glossary/public-key-infrastructure",{"title":1113,"description":438},"glossary/public-key-infrastructure","El0OpEjBD0dpWkoo2Ax-HUszxNm984qKlUf7oEnEN_4",{"id":1348,"title":1349,"author":146,"body":1350,"cta":146,"description":438,"eventid":146,"extension":461,"hideInRecent":462,"layout":463,"meta":1789,"moment":146,"navigation":476,"path":1795,"seo":1796,"stem":1797,"tags":146,"webcast":462,"__hash__":1798},"content_de/glossary/use-cases-for-certificates.md","Anwendungsfälle für Zertifikate",{"type":148,"value":1351,"toc":1774},[1352,1356,1360,1374,1378,1410,1414,1445,1449,1455,1461,1465,1518,1522,1526,1540,1544,1556,1560,1563,1577,1581,1587,1598,1603,1614,1620,1631,1635,1655,1659,1662,1666,1686,1690,1707,1712,1732,1736,1739,1771],[151,1353,1355],{"id":1354},"transport-layer-security-tls","Transport Layer Security (TLS)",[168,1357,1359],{"id":1358},"welche-zwei-fragen-muss-ein-client-stellen-wenn-er-ein-zertifikat-von-einem-server-erhält","Welche zwei Fragen muss ein Client stellen, wenn er ein Zertifikat von einem Server erhält?",[261,1361,1362,1368],{},[178,1363,1364,1367],{},[160,1365,1366],{},"Ist das Zertifikat gültig und vertrauenswürdig?"," Der Client muss prüfen, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde und ob es weder abgelaufen noch gesperrt ist. Dazu gehört, den Gültigkeitszeitraum des Zertifikats zu prüfen und sicherzustellen, dass es von einer CA signiert ist, der der Client vertraut.",[178,1369,1370,1373],{},[160,1371,1372],{},"Passt das Zertifikat zur Identität des Servers?"," Der Client muss sicherstellen, dass die Angaben im Zertifikat, etwa der Common Name (CN) oder der Subject Alternative Name (SAN), zum Domainnamen des Servers passen. So bestätigt sich, dass das Zertifikat tatsächlich für den Server gedacht ist, zu dem der Client eine Verbindung aufbauen will.",[168,1375,1377],{"id":1376},"wie-prüft-der-client-ob-einem-zertifikat-vertraut-werden-kann","Wie prüft der Client, ob einem Zertifikat vertraut werden kann?",[261,1379,1380,1386,1392,1398,1404],{},[178,1381,1382,1385],{},[160,1383,1384],{},"Vertrauenskette des Zertifikats prüfen:"," Der Client prüft die Zertifikatskette, zu der das Zertifikat des Servers, etwaige Intermediate-Zertifikate und das Stammzertifikat gehören. Jedes Zertifikat der Kette muss von der jeweils nächsthöheren Instanz signiert sein und letztlich zu einem vertrauenswürdigen Stammzertifikat führen.",[178,1387,1388,1391],{},[160,1389,1390],{},"Gültigkeitszeitraum des Zertifikats prüfen:"," Der Client prüft den Gültigkeitszeitraum des Zertifikats, um sicherzustellen, dass es weder abgelaufen noch noch nicht gültig ist. Dazu gehört die Prüfung der Daten „Not Before“ und „Not After“ im Zertifikat.",[178,1393,1394,1397],{},[160,1395,1396],{},"Zertifikat der Identität des Servers zuordnen:"," Der Client stellt sicher, dass der Common Name (CN) oder der Subject Alternative Name (SAN) des Zertifikats zum Domainnamen des Servers passt. Damit ist bestätigt, dass das Zertifikat für den Server gedacht ist, mit dem sich der Client verbindet.",[178,1399,1400,1403],{},[160,1401,1402],{},"Auf Sperrung prüfen:"," Der Client prüft, ob das Zertifikat gesperrt wurde, indem er die Certificate Revocation List (CRL) abfragt oder das Online Certificate Status Protocol (OCSP) nutzt. Einem gesperrten Zertifikat wird nicht mehr vertraut.",[178,1405,1406,1409],{},[160,1407,1408],{},"Digitale Signatur prüfen:"," Der Client prüft die digitale Signatur des Zertifikats, um sicherzustellen, dass es nicht manipuliert wurde. Dazu wird die kryptografische Signatur gegen den öffentlichen Schlüssel der ausstellenden CA geprüft.",[168,1411,1413],{"id":1412},"wie-prüft-der-client-ob-der-server-wirklich-der-inhaber-eines-zertifikats-ist","Wie prüft der Client, ob der Server wirklich der Inhaber eines Zertifikats ist?",[261,1415,1416,1422,1428,1434,1440],{},[178,1417,1418,1421],{},[160,1419,1420],{},"Prüfung der Zertifikatskette:"," Der Client prüft die Zertifikatskette und stellt sicher, dass jedes Zertifikat der Kette von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) signiert ist. Diese Kette beginnt beim Zertifikat des Servers und endet bei einem vertrauenswürdigen Stammzertifikat.",[178,1423,1424,1427],{},[160,1425,1426],{},"Abgleich des Domainnamens:"," Der Client prüft, ob der Common Name (CN) oder der Subject Alternative Name (SAN) des Zertifikats zum Domainnamen des Servers passt. Damit ist sichergestellt, dass das Zertifikat für den Server gedacht ist, mit dem sich der Client verbindet.",[178,1429,1430,1433],{},[160,1431,1432],{},"Prüfung der digitalen Signatur:"," Der Client prüft die digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der ausstellenden CA. Damit ist sichergestellt, dass das Zertifikat nicht manipuliert wurde und tatsächlich von einer vertrauenswürdigen CA ausgestellt ist.",[178,1435,1436,1439],{},[160,1437,1438],{},"Gültigkeitszeitraum des Zertifikats:"," Der Client prüft den Gültigkeitszeitraum des Zertifikats, um sicherzustellen, dass es aktuell gültig und nicht abgelaufen ist.",[178,1441,1442,1403],{},[160,1443,1444],{},"Prüfung des Sperrstatus:",[168,1446,1448],{"id":1447},"warum-ist-die-inhaberschaft-wichtig-wenn-du-bereits-geprüft-hast-dass-dem-zertifikat-vertraut-wird","Warum ist die Inhaberschaft wichtig, wenn du bereits geprüft hast, dass dem Zertifikat vertraut wird?",[156,1450,1451,1454],{},[160,1452,1453],{},"Gültigkeit und Vertrauenswürdigkeit des Zertifikats:"," Dieser Schritt stellt sicher, dass das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) ausgestellt wurde, innerhalb seines Gültigkeitszeitraums liegt und nicht gesperrt wurde. Er bestätigt, dass das Zertifikat legitim ist und nicht manipuliert wurde.",[156,1456,1457,1460],{},[160,1458,1459],{},"Prüfung der Serveridentität:"," Selbst wenn ein Zertifikat gültig und vertrauenswürdig ist, muss zusätzlich bestätigt werden, dass es zu dem Server gehört, mit dem du dich verbindest. Dazu wird geprüft, ob der Common Name (CN) oder der Subject Alternative Name (SAN) des Zertifikats zum Domainnamen des Servers passt. Dieser Schritt stellt sicher, dass das Zertifikat für genau diesen Server gedacht ist, und verhindert Man-in-the-Middle-Angriffe, bei denen ein Angreifer ein gültiges Zertifikat für eine andere Domain vorlegt.",[168,1462,1464],{"id":1463},"mit-welchen-zwei-methoden-beantwortet-der-client-diese-frage-welche-zwei-ergebnisse-gibt-es-bei-beiden-methoden","Mit welchen zwei Methoden beantwortet der Client diese Frage? Welche zwei Ergebnisse gibt es bei beiden Methoden?",[261,1466,1467,1494],{},[178,1468,1469,1472,1473,1476,1479,1480],{},[160,1470,1471],{},"Prüfung über das Domain Name System (DNS):"," Der Client prüft, ob der Common Name (CN) oder der Subject Alternative Name (SAN) des Zertifikats zum Domainnamen des Servers passt. ",[1474,1475],"br",{},[160,1477,1478],{},"Ergebnis",":",[175,1481,1482,1488],{},[178,1483,1484,1487],{},[160,1485,1486],{},"Übereinstimmung",": Stimmen die Namen überein, kann der Client die Verbindung fortsetzen, sicher in dem Wissen, dass das Zertifikat für diesen Server gedacht ist. ",[178,1489,1490,1493],{},[160,1491,1492],{},"Abweichung",": Stimmen die Namen nicht überein, beendet der Client die Verbindung in aller Regel oder zeigt eine Warnung, die auf ein mögliches Sicherheitsrisiko hinweist.",[178,1495,1496,1499,1500,1502,1479,1504],{},[160,1497,1498],{},"Prüfung über die Public Key Infrastructure (PKI):"," Der Client prüft die digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der ausstellenden Zertifizierungsstelle (Certificate Authority, CA). ",[1474,1501],{},[160,1503,1478],{},[175,1505,1506,1512],{},[178,1507,1508,1511],{},[160,1509,1510],{},"Gültige Signatur",": Ist die Signatur gültig, ist damit bestätigt, dass das Zertifikat nicht manipuliert wurde und von einer vertrauenswürdigen CA ausgestellt ist.",[178,1513,1514,1517],{},[160,1515,1516],{},"Ungültige Signatur:"," Ist die Signatur ungültig, beendet der Client die Verbindung oder zeigt eine Warnung, die darauf hinweist, dass das Zertifikat kompromittiert oder gefälscht sein könnte.",[168,1519,1521],{"id":1520},"wovon-hängt-ab-welche-methode-verwendet-wird","Wovon hängt ab, welche Methode verwendet wird?",[156,1523,1524],{},[160,1525,1471],{},[175,1527,1528,1534],{},[178,1529,1530,1533],{},[160,1531,1532],{},"Verwendung",": Diese Methode kommt immer als Teil des TLS-Handshakes zum Einsatz. Der Client gleicht den Common Name (CN) oder den Subject Alternative Name (SAN) des Zertifikats mit dem Domainnamen des Servers ab und stellt so sicher, dass sie übereinstimmen.",[178,1535,1536,1539],{},[160,1537,1538],{},"Ausschlaggebende Faktoren:"," Das ist fester Bestandteil des TLS-Protokolls und wird vom Client beim Aufbau einer sicheren Verbindung automatisch durchgeführt.",[156,1541,1542],{},[160,1543,1498],{},[175,1545,1546,1551],{},[178,1547,1548,1550],{},[160,1549,1532],{},": Auch diese Methode kommt beim TLS-Handshake immer zum Einsatz. Der Client prüft die digitale Signatur des Zertifikats mit dem öffentlichen Schlüssel der ausstellenden Zertifizierungsstelle (Certificate Authority, CA).",[178,1552,1553,1555],{},[160,1554,1538],{}," Auch das ist fester Bestandteil des TLS-Protokolls. Der Client führt diese Prüfung automatisch durch, um sicherzustellen, dass das Zertifikat gültig ist und nicht manipuliert wurde.",[151,1557,1559],{"id":1558},"welche-zertifikate-sollte-der-server-an-den-client-schicken","Welche Zertifikate sollte der Server an den Client schicken?",[156,1561,1562],{},"Beim TLS-Handshake sollte der Server dem Client die folgenden Zertifikate schicken:",[175,1564,1565,1571],{},[178,1566,1567,1570],{},[160,1568,1569],{},"Endzertifikat:"," Das ist das eigene Zertifikat des Servers, mit dem er seine Identität gegenüber dem Client nachweist.",[178,1572,1573,1576],{},[160,1574,1575],{},"Intermediate-Zertifikate:"," Diese Zertifikate verbinden das Endzertifikat mit dem vertrauenswürdigen Stammzertifikat. Sie helfen dabei, eine Vertrauenskette vom Zertifikat des Servers zurück zu einem vertrauenswürdigen Stammzertifikat herzustellen.",[151,1578,1580],{"id":1579},"was-sind-domain-validation-und-extended-validation-zertifikate","Was sind Domain-Validation- und Extended-Validation-Zertifikate?",[156,1582,1583,1586],{},[160,1584,1585],{},"Domain-Validation-Zertifikate (DV)"," sind eine Art von TLS-Zertifikat, bei der die Zertifizierungsstelle (Certificate Authority, CA) prüft, ob der Antragsteller die Kontrolle über die Domain hat. Üblicherweise geschieht das so:",[175,1588,1589,1592,1595],{},[178,1590,1591],{},"Antwort auf eine E-Mail an den administrativen Kontakt der Domain.",[178,1593,1594],{},"Anlegen eines DNS-TXT-Eintrags.",[178,1596,1597],{},"Hochladen einer Datei auf den Webserver.",[156,1599,1600],{},[160,1601,1602],{},"Wesentliche Eigenschaften:",[175,1604,1605,1608,1611],{},[178,1606,1607],{},"Schnelle Ausstellung: Sie lassen sich schnell ausstellen, oft innerhalb weniger Minuten, weil nur eine minimale Prüfung nötig ist.",[178,1609,1610],{},"Grundlegende Sicherheit: Sie bieten Verschlüsselung und die grundlegende Gewissheit, dass die Domain von der Stelle kontrolliert wird, die das Zertifikat beantragt hat.",[178,1612,1613],{},"Günstig: Oft preiswerter oder sogar kostenlos, damit auch für kleine Websites und private Projekte zugänglich.",[156,1615,1616,1619],{},[160,1617,1618],{},"Extended-Validation-Zertifikate (EV)"," sind eine höherwertige Art von TLS-Zertifikat, die ein strengeres Prüfverfahren voraussetzt. Die CA prüft die rechtliche, physische und operative Existenz der Stelle, die das Zertifikat beantragt. Dazu gehört:",[175,1621,1622,1625,1628],{},[178,1623,1624],{},"Rechtliche Identität und Status der Stelle bestätigen.",[178,1626,1627],{},"Physische und operative Präsenz der Stelle prüfen.",[178,1629,1630],{},"Sicherstellen, dass die Stelle die exklusiven Rechte an der Domain hat.",[156,1632,1633],{},[160,1634,1602],{},[175,1636,1637,1643,1649],{},[178,1638,1639,1642],{},[160,1640,1641],{},"Hohe Verlässlichkeit:"," Bietet Nutzern das höchste Maß an Vertrauen und Verlässlichkeit, weil eine gründliche Prüfung dahintersteht.",[178,1644,1645,1648],{},[160,1646,1647],{},"Sichtbare Kennzeichen:"," In manchen Browsern haben EV-Zertifikate früher den Namen der Organisation in der Adressleiste angezeigt, heute ist das allerdings seltener.",[178,1650,1651,1654],{},[160,1652,1653],{},"Mehr Vertrauen:"," Ideal für Websites, die mit sensiblen Informationen umgehen, etwa Finanzinstitute und E-Commerce-Sites.",[168,1656,1658],{"id":1657},"welche-sind-sicherer"," Welche sind sicherer?",[156,1660,1661],{},"Extended-Validation-Zertifikate (EV) gelten wegen ihres strengen Prüfverfahrens im Allgemeinen als sicherer als Domain-Validation-Zertifikate (DV). Hier der Vergleich:",[156,1663,1664],{},[160,1665,1585],{},[175,1667,1668,1674,1680],{},[178,1669,1670,1673],{},[160,1671,1672],{},"Prüftiefe:"," Prüft nur die Kontrolle über die Domain.",[178,1675,1676,1679],{},[160,1677,1678],{},"Sicherheit:"," Bietet grundlegende Verschlüsselung und Verlässlichkeit.",[178,1681,1682,1685],{},[160,1683,1684],{},"Anwendungsfall:"," Geeignet für private Websites, Blogs und kleine Unternehmen.",[156,1687,1688],{},[160,1689,1618],{},[175,1691,1692,1697,1702],{},[178,1693,1694,1696],{},[160,1695,1672],{}," Prüft die rechtliche, physische und operative Existenz der Stelle.",[178,1698,1699,1701],{},[160,1700,1678],{}," Bietet wegen der gründlichen Prüfung ein höheres Maß an Vertrauen und Verlässlichkeit.",[178,1703,1704,1706],{},[160,1705,1684],{}," Ideal für Finanzinstitute, E-Commerce-Sites und alle Websites, die mit sensiblen Informationen umgehen.",[156,1708,1709],{},[160,1710,1711],{},"Warum EV-Zertifikate sicherer sind:",[175,1713,1714,1720,1726],{},[178,1715,1716,1719],{},[160,1717,1718],{},"Gründliche Prüfung:"," EV-Zertifikate erfordern eine umfangreiche Prüfung, was es böswilligen Akteuren erschwert, an sie zu kommen.",[178,1721,1722,1725],{},[160,1723,1724],{},"Vertrauensanzeigen:"," Heute zwar seltener, aber EV-Zertifikate haben früher den Namen der Organisation in der Adressleiste des Browsers angezeigt und Nutzern so eine sichtbare Bestätigung geliefert.",[178,1727,1728,1731],{},[160,1729,1730],{},"Höhere Verlässlichkeit:"," Das ausführliche Prüfverfahren stellt sicher, dass die Stelle hinter dem Zertifikat legitim ist, und verringert so das Risiko von Phishing und anderen Angriffen.",[151,1733,1735],{"id":1734},"wie-läuft-die-sperrung-mit-ocsp-stapling-ab","Wie läuft die Sperrung mit OCSP Stapling ab",[156,1737,1738],{},"OCSP Stapling verbessert das übliche OCSP-Verfahren, indem es die Latenz senkt und den Datenschutz erhöht. So funktioniert es:",[261,1740,1741,1747,1753,1759,1765],{},[178,1742,1743,1746],{},[160,1744,1745],{},"Server fordert OCSP-Antwort an:"," Der Webserver fragt in regelmäßigen Abständen den Sperrstatus seines Zertifikats beim OCSP-Responder ab, einem Server, den die Zertifizierungsstelle (CA) betreibt. Diese Anfrage läuft im Hintergrund und nicht bei jeder Clientverbindung.",[178,1748,1749,1752],{},[160,1750,1751],{},"OCSP-Responder liefert Antwort:"," Der OCSP-Responder schickt eine signierte und mit Zeitstempel versehene OCSP-Antwort zurück, die den Status des Zertifikats angibt, etwa „good“, „revoked“ oder „unknown“. Der Server legt diese Antwort im Cache ab.",[178,1754,1755,1758],{},[160,1756,1757],{},"TLS-Handshake mit angehefteter Antwort:"," Baut ein Client, etwa ein Webbrowser, eine Verbindung zum Server auf, legt der Server die zwischengespeicherte OCSP-Antwort dem TLS-Handshake bei. Das wird als „Stapling“ der Antwort an den Handshake bezeichnet.",[178,1760,1761,1764],{},[160,1762,1763],{},"Client prüft die OCSP-Antwort:"," Der Client prüft die angeheftete OCSP-Antwort. Da sie von der CA signiert ist, kann der Client ihrer Gültigkeit vertrauen. Weist die Antwort das Zertifikat als gesperrt aus, baut der Client keine sichere Verbindung auf.",[178,1766,1767,1770],{},[160,1768,1769],{},"Regelmäßige Aktualisierung:"," Der Server aktualisiert seine zwischengespeicherte OCSP-Antwort weiterhin in regelmäßigen Abständen, damit er beim TLS-Handshake immer einen aktuellen Status liefern kann.",[156,1772,1773],{},"Dieses Verfahren verringert die Notwendigkeit, dass Clients eigene OCSP-Anfragen stellen, und verbessert damit Performance und Datenschutz.",{"title":438,"searchDepth":439,"depth":439,"links":1775},[1776,1784,1785,1788],{"id":1354,"depth":439,"text":1355,"children":1777},[1778,1779,1780,1781,1782,1783],{"id":1358,"depth":444,"text":1359},{"id":1376,"depth":444,"text":1377},{"id":1412,"depth":444,"text":1413},{"id":1447,"depth":444,"text":1448},{"id":1463,"depth":444,"text":1464},{"id":1520,"depth":444,"text":1521},{"id":1558,"depth":439,"text":1559},{"id":1579,"depth":439,"text":1580,"children":1786},[1787],{"id":1657,"depth":444,"text":1658},{"id":1734,"depth":439,"text":1735},{"lang":465,"seoTitle":1790,"titleClass":466,"socialimg":1791,"blogtitlepic":1792,"customExcerpt":1793,"keywords":1794,"maxContent":476},"Transport Layer Security (TLS): Anwendungsfälle für Zertifikate und ihre Prüfung","/blog/heads/header-scepman-use-cases-certificates.png","header-scepman-use-cases-certificates.png","Schütze deine Website und deine Nutzer mit TLS-Zertifikaten: Sie weisen Server aus, schaffen über Zertifikatsketten Vertrauen und sorgen für sichere, verschlüsselte Verbindungen.","TLS-Zertifikate, Transport Layer Security, Anwendungsfälle für Zertifikate, Prüfung von TLS-Zertifikaten, Vertrauenskette von Zertifikaten, DV-Zertifikate, EV-Zertifikate, Serverauthentifizierung, sichere Verbindungen, OCSP Stapling","/glossary/use-cases-for-certificates",{"title":1349,"description":438},"glossary/use-cases-for-certificates","UH8TQbn2wVnjxc62nxoDfcQljcsSPi_R04086uKmhpE",{"list":142,"authors":146},1790098989821]