SSL Zertifikate und ihre Unterschiede

1. SSL – Secure Sockets Layer

Das SSL-Protokoll (oder eigentlich TLS-Protokoll) stellt zwei Endpunkten einen Kanal zum sicheren Datenaustausch bereit. Hauptsächlich wird SSL für die Absicherung zwischen Webbrowser und Webserver eingesetzt – also immer dann, wenn sensible Informationen über das unsichere Internet ausgetauscht werden sollen. Dabei arbeitet es im Grunde genommen transparent. Vom Benutzer wird im Normalfall keine Interaktion erwartet. Der Anwender erkennt SSL an folgenden Merkmalen:

• An das bekannte HTTP in der Adresszeile wird ein »S« angefügt – also HTTPS
• Abhängig vom verwendeten Browser wird irgendwo in der Adresszeile ein Sicherheitsschloss dargestellt

Im vorliegenden Beitrag möchte ich allerdings nicht auf das SSL-Protokoll als solches eingehen, sondern auf die unterschiedlichen Varianten der SSL-Zertifikate. Wer mehr Details über TLS bzw. SSL erfahren möchte, kann dies bei Wikpedia tun.

2. Zertifikat ist nicht gleich Zertifikat

Mittlerweile existieren verschiedene Varianten von SSL-Zertifikaten. Generell lässt sich sagen: Es gibt für jeden Bedarf das richtige Zertifikat – und das hat seinen Preis.

Bevor ich auf die unterschiedlichen Varianten eingehe möchte ich zunächst kurz auflisten, wonach sich SSL Zertifikate grob unterscheiden:

• Stärke der RSA-Schlüssel (Standard sind 2048 Bit / besser 4096 Bit)
• Domain- oder Identitätsvalidiert
• Browserkompatibilität bzw. Akzeptanz
• Zertifikatsart
  • Single
  • Wildcard (Hauptdomain + Subdomains)
  • Multidomain

3. Drei SSL-Varianten oder doch mehr?

Generell halte ich eine Einteilung in drei unterschiedliche Varianten für sinnvoll. Unterschieden wird zwischen Domain Validation, Organisation Validation und Extended Validation.

3.1 Domain Validation

Am höchsten verbreitet ist die Domain Validation. Dabei wird die Domain in einem E-Mail Prozess verifiziert. Ein E-Mail Robot schickt an eine WHOIS Adresse oder eine alternative administrative Adresse eine Nachricht, um die Bestellung eines SSL-Zertifikats zu bestätigen. Die Zertifizierungsstelle prüft also lediglich, ob der eigentliche Auftraggeber auch Inhaber der Domain ist. Nach einer Bestätigung ist das Zertifikat innerhalb von wenigen Minuten ausgestellt.

Ein Klick auf das SSL-Schloss in der Browserzeile zeigt bei Domain Validation anschließend den Domainnamen an.

Eignet sich für:

• kleine Webseiten
• Foren, Blogs oder Intranet
• Mailserver

3.2 Organisation Validation

Bei Organisation Validation SSL Zertifikaten wird zusätzlich zum Domaincheck eine Identitätsprüfung vorgenommen. Ein Unternehmen muss entsprechende Dokumente nachweisen, die ihn als Inhaber der Domain bestätigen. Abhängig vom Anbieter unterscheidet sich die Identitätsprüfung. Im Normalfall wird ein Handelsregisterauszug angefordert, die Bankdaten abgeglichen und noch telefonisch Kontakt aufgenommen. Ein Teil der gesammelten Informationen wird anschließend mit dem WHOIS Eintrag vergleichen.

Zusätzlich zum Domainnamen wird bei diesem Zertifikatstyp unter Zertifikatsinhaber der Unternehmensname und Ort angezeigt.

Eignet sich für:

• Webshops
• Unternehmensseiten
• Webmail

3.2 Extended Validation

Extended Validation Zertifikate unterscheiden sich hauptsächlich durch eine grüne Adresszeile im Browser von den beiden anderen Varianten. Sozusagen ein »optisches Feedback«, ob es sich um eine vertrauenswürdige Verbindung handelt. Beim Validierungsverfahren nimmt die Zertifizierungsstelle einen Domaincheck und Identitätsprüfung vor. Des Weiteren wird geprüft, ob der Antragsteller beim Unternehmen angestellt ist und über die Befugnis verfügt, ein Extended SSL-Zertifikat zu erwerben.

Bei diesen Zertifikaten wird versucht eine höchstmögliche Browser Akzeptanz zu erzielen. Neben der grünen Adresszeile wird unter Zertifikatsinhaber ebenfalls der Domainname, Unternehmensname und Ort angezeigt.

4. Ablauf des Schlüsselaustauschs

Beim Aufruf von https geschützten Seiten erfolgt ein Schlüsselaustausch und die Authentifizierung bspw. über das asymmetrische Verschlüsselungsverfahren RSA. Vereinfacht dargestellt läuft bei einem Verbindungsaufbau folgende Kommunikation zwischen Browser und der Gegenstelle (Server) ab:

1. Der Anwender kontaktiert über seinen Browser die Webseite »https://sichere-verbindung.de«
2. Auf die Anfrage schickt der Server ein Zertifikat (inklusive öffentlichen Schlüssel) an den Browser zurück, das im Idealfall von einer »vertrauenswürdigen« Zertifizierungsstelle unterschrieben wurde.
3. Anschließend kontaktiert der Browser die Zertifizierungsstelle und lässt sich die Echtheit des Zertifikats bestätigen bzw. er kann dann davon ausgehen, tatsächlich mit der Gegenstelle »https://sichere-verbindung.de« zu kommunizieren.
4. Mit Hilfe des öffentlichen Schlüssels handelt der Browser dann einen geheimen Sitzungsschlüssel mit dem Server aus. Nur der Server kann diese Nachrichten (pre-master-secret) wieder entschlüsseln, da er über den passenden privaten Schlüssel verfügt. Aus dieser pre-master-secret wird dann ein einmaliger Sitzungsschlüssel abgeleitet.
5. Dieser Sitzungsschlüssel wird anschließend vom Server bestätigt und zur Absicherung der eigentlichen Kommunikation bzw. Datenübertragung genutzt. Als symmetrisches Verfahren kommt bspw. AES in Frage.

Bei SSL-verschlüsselten Kommunikationsbeziehungen kommen also gleich zwei Verschlüsselungsvarianten zum Einsatz: Zunächst eine asymmetrische Verschlüsselung und danach eine symmetrische Verschlüsselung.

5. Die Qual der Anbieterwahl

Zertifizierungsstellen (certificate authority, CA) gibt es wie Sand am Meer. Diese CAs verteilen sich auf verschiedene Länder und oftmals ist nicht nachvollziehbar, welches Unternehmen oder Regierung eigentlich dahinter steckt. Transparenz und Vertrauen bietet die heute vorherrschende »Aussteller-Lotterie« eher nicht.

Eine Alternative sind selbst ausgestellte SSL-Zertifikate, die allerdings dann nicht von einer CA unterschrieben werden, sondern vom Ersteller selbst. Hierbei ist dann Folgendes zu beachten:

• Browser reagieren auf selbst ausgestellte SSL-Zertifikate mit einer Warnmeldung, da sie über keine Unterschrift einer bekannten CA verfügen. Jeder Browser wird mit einer Liste von CA-Zertifikaten ausgeliefert – die Liste von Firefox lässt sich online einsehen.
• Ganz umsonst sind diese Browser Warnmeldungen jedoch nicht, sondern sollen eigentlich sicherstellen, dass niemand die verschlüsselte Verbindung abhören bzw. umleiten kann. Ein Zertifikatsfehler bzw. die Warnmeldung erscheint auch dann, wenn ein Angreifer einen Man-in-the-middle-Angriff durchführt. Dadurch wäre er in der Lage die Anmeldedaten im Klartext mitzuschneiden.

Gerade im Geschäftsumfeld eignen sich selbst ausgestellte SSL-Zertifikate eher weniger. Nutzer würden beim Aufruf einer solchen Seiten von den meisten Browsern einen Zertifikatsfehler angezeigt bekommen. Auf den Anwender wirkt dies wenig vertrauenserweckend, auch wenn nicht zwangsläufig ein Sicherheitsproblem vorliegt. So bleibt den meisten IT-Verantwortlichen die Beantragung eines Zertifikats über eine »vertrauenswürdige« CA nicht erspart. In Deutschland betreibt die Bundesdruckerei mit D-Trust die einzige wirklich in deutscher Hand befindliche Root-CA. Daneben existieren noch weitere deutsche SSL-CAs, diese arbeiten allerdings meistens mit Zwischenzertifikaten, die von US-amerikanschen CAs abstammen. Spätestens seit der NSA-Affäre ist das Vertrauen praktisch vollständig zerstört. Gerade bei der Übertragung sensibler Daten, würde ich diese »Vertrauenskette« vermeiden.

6. Fazit

Domain validierte SSL-Zertifikate sind am meisten verbreitet. Sie sind innerhalb weniger Minuten ausgestellt und erfordern gegenüber den anderen beiden Varianten kaum Aufwand. Wer solch ein Zertifikat erwirbt, der möchte primär die Fehlermeldung vermeiden, die bei selbst ausgestellten Zertifikaten erscheint. Die wenigsten Besucher validieren den Zertifikatsinhalt…

Abhängig vom Verwendungszweck sind (zb. Webshop) Organisation validierte SSL-Zertifikate möglicherweise zu bevorzugen. Diese werden noch von der Extended Variante ergänzt. Bei einer grünen Adresszeile wird der Anwender bestärkt sich auf der gewünschten Webseite zu befinden, um seine Web-Transaktionen »sicher« ausführen zu können.

Bildquellen:

Haus: PublicDomainPictures, Creative Commons CC0

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Ähnliche Beiträge

7. Dezember 2013

Projekt arkOS: Installation SSL-Zertifikat

Einrichtung einer SSL-verschlüsselten Kommunikation für arkOS.

12. September 2013

NSA abhörsichere SSL-Verschlüsselung für Apache und nginx

Mit den richtigen SSL-Cipher-Suites für Apache und nginx hat die NSA derzeit keine Chance verschlüsselte Kommunikation zu dekodieren.

17. Januar 2013

Root Zertifikat importieren unter Android

Root Zertifikate unter Android zu importieren ist kein Hexenwerk. Entscheidend ist das richtige Format.

28. Februar 2018

Postfix: TLS-Konfiguration mit ECDSA- / RSA-Zertifikaten

Vorstellung einer sauberen, abwärtskompatiblen aber dennoch modernen TLS-Konfiguration für Postfix mit ECDSA- / RSA-Zertifikaten.

18. Januar 2022

Nextcloud auf dem Raspberry Pi – NextCloudPi Teil1

Die Vorteile der Cloud genießen, ohne persönliche Daten in fremde Hände zu legen: Nextcloud auf dem Raspberry Pi macht es möglich.

Weitere Themen

AndroidAuditAutonomieBackupBezahlenBrowserCloudDatenschutzDatensendeverhaltenDigitalpolitikDSGVOE-MailFirewallHackingHärteniOSKuketz-BlogLinuxmacOSMessengerOpenWrtPasswortPentestRaspberryPiRechtSicherheitslückeSicherheitsmaßnahmeTorTrackingTTDSGÜberwachungVerschlüsselungWindowsWordPressXMPP

---

Diskussion

4 Ergänzungen zu “SSL Zertifikate und ihre Unterschiede”

1. Syntafin sagt:

   18. April 2014 um 13:14 Uhr

   Hallo,

   das erklärt aber nun nicht, welches Zertifikat in welchem Fall sinnvoll ist.
   Zum Beispiel, welches Zertifikat sollte man wählen wenn man seine Haupt-Domain und den Mailserver (verschiedene @domain) absichern will?

   MfG Syntafin

   • Mike Kuketz sagt:

     20. April 2014 um 09:10 Uhr

     Korrekt. War aber auch nicht der Fokus des Beitrags. Bei der Auswahl kommt es drauf an, ob es sich um Privatgebrauch oder ein Unternehmen handelt.
     Im Privatumfeld genügt ein selbst ausgestelltes SSL-Zertifikat. Womöglich auch über eine eigene CA.

     • Syntafin sagt:

       22. April 2014 um 20:09 Uhr

       Problem bei mir ist, das scheinbar große Mail-Anbieter selbstsignierte Zertifikate nicht vertrauen und daher die Emails automatisch als Spam abspeisen, wodurch die Emails immer im Spam-Ordner landen :/.

       Daher überlege ich derzeit ob ich mir ein richtiges Zertifikat zulege, weiß nur nicht welches :).

2. Hansjörg Leichsenring sagt:

   27. April 2016 um 07:09 Uhr

   wie sind denn die Zertifikate von let’s encrypt einzuordnen?

   VG

   Hansjörg

Wenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.