SSL-Zertifikattypen: Die passende Wahl treffen

Veröffentlicht am 30. September 2026

Das richtige SSL-Zertifikat erfüllt gleichzeitig zwei Aufgaben: Es verschlüsselt den Datenverkehr zwischen einem Besucher und Ihrem Server und weist die Identität aus, der Ihre Besucher vertrauen müssen. SSL-Zertifikattypen unterscheiden sich hauptsächlich darin, wie diese Identität validiert wird und wie viele Hostnamen sie abdecken. Für die meisten Websites geht es bei der richtigen Wahl weniger um Kryptografie als darum, Zertifikatumfang und Validierung an die tatsächliche Funktionsweise des Dienstes anzupassen.

Eine kleine Informationswebsite, eine Checkout-Seite, eine mandantenfähige SaaS-Plattform und eine Agentur, die 40 Kundendomains verwaltet, können allesamt dieselben TLS-Verschlüsselungsstandards verwenden. Sie sollten jedoch nicht automatisch dasselbe Zertifikat verwenden. Der Betrieb verläuft ruhiger, wenn der Zertifikatplan zum Infrastrukturplan passt.

SSL-Zertifikattypen nach Validierungsstufe

Die Validierungsstufe bestimmt, was die Zertifizierungsstelle vor der Ausstellung des Zertifikats prüft. Jedes gültige Zertifikat verschlüsselt die Verbindung. Der Unterschied liegt im Umfang der dahinterstehenden Identitätsprüfung und in manchen Fällen in den Informationen, die in den Zertifikatdetails angezeigt werden.

Domain-validierte Zertifikate

Ein Domain-validiertes Zertifikat, kurz DV-Zertifikat, bestätigt die Kontrolle über einen Domainnamen. Die Zertifizierungsstelle fordert Sie normalerweise auf, einen DNS-Eintrag zu setzen, eine Validierungsdatei hochzuladen oder eine an eine autorisierte Adresse gesendete E-Mail zu bestätigen. Sobald diese Prüfung bestanden ist, kann die Ausstellung sehr schnell erfolgen.

DV ist die praktische Wahl für Blogs, Landingpages, Entwicklungsumgebungen, APIs, über eine Domain erreichbare interne Tools und viele herkömmliche Unternehmenswebsites. Es bietet Besuchern das HTTPS-Schlosssymbol und verschlüsselt Anmeldedaten, Formulare, Sitzungen und anderen Datenverkehr während der Übertragung.

Der Kompromiss ist einfach: DV überprüft nicht das hinter der Website stehende rechtliche Unternehmen. Ein Besucher kann sehen, dass seine Verbindung verschlüsselt ist und die Website die Domain kontrolliert, erhält von der Zertifizierungsstelle jedoch keine gesondert verifizierte Organisationsidentität. Für viele Unternehmen ist das vollkommen angemessen.

Organisationsvalidierte Zertifikate

Organisationsvalidierte Zertifikate, kurz OV-Zertifikate, erfordern, dass die Zertifizierungsstelle sowohl die Domainkontrolle als auch die Organisation prüft, die das Zertifikat beantragt. Dazu gehören normalerweise die Prüfung von Unternehmensregisterdaten und Adressangaben sowie einer bestätigten Kontaktmethode.

OV-Zertifikate eignen sich für etablierte Unternehmen, B2B-Portale, Agenturwebsites, Beschaffungsplattformen und Kundenbereiche, in denen die Organisationsidentität von Bedeutung ist. Die verifizierten Organisationsinformationen sind in den Zertifikatdetails verfügbar und können Gespräche zur Sorgfaltsprüfung mit Unternehmenskunden oder Sicherheitsteams unterstützen.

Die Verschlüsselung ist nicht allein deshalb stärker als bei DV, weil das Zertifikat OV verwendet. Der moderne TLS-Schutz hängt von der Serverkonfiguration, den unterstützten Protokollversionen, den Verschlüsselungssammlungen und dem Zertifikatsschlüsseltyp ab. OV ergänzt einen umfassenderen Prozess zur Identitätssicherung, nicht auf magische Weise zusätzliche Verschlüsselung. Trotzdem nützlich, nur eben keine Zauberei.

Erweitert validierte Zertifikate

Erweitert validierte Zertifikate, kurz EV-Zertifikate, durchlaufen den detailliertesten Validierungsprozess. Die Zertifizierungsstelle prüft die rechtliche Existenz, den Geschäftsbetrieb und die physische Adresse der Organisation sowie den autorisierten Antragsteller anhand festgelegter Regeln.

EV kann für regulierte Organisationen, Finanzdienstleister, hochwertige E-Commerce-Marken und Unternehmen mit formalen Beschaffungs- oder Compliance-Anforderungen sinnvoll sein. Es kann auch von einem Partner verlangt werden, der eine eigene Sicherheitscheckliste für Anbieter hat.

Für eine typische Website eines kleinen Unternehmens ist EV nicht automatisch die beste Investition. Moderne Browser zeigen die auffällige grüne Darstellung in der Adressleiste, durch die sich EV früher für alltägliche Nutzer hervorhob, nicht mehr an. Wählen Sie es, wenn sein Validierungsprozess einen konkreten Vertrauens-, Vertrags- oder Richtlinienbedarf erfüllt – nicht, weil Sie eine dramatische Steigerung der visuellen Conversion erwarten.

SSL-Zertifikattypen nach Domainumfang

Nach der Validierung ist der Umfang die nächste Entscheidung. Hier gehen Zertifikatkäufe am häufigsten schief. Ein Zertifikat kann gültig und korrekt installiert sein und dennoch für einen Hostnamen fehlschlagen, für dessen Schutz es nie ausgestellt wurde.

Single-Domain-Zertifikate

Ein Single-Domain-Zertifikat schützt einen vollqualifizierten Domainnamen, beispielsweise `www.example.com` oder `app.example.com`. Je nach Zertifikatkonfiguration benötigen die Root-Domain und die Version `www` möglicherweise eine separate Abdeckung. Gehen Sie nie davon aus, dass beide enthalten sind, ohne die Subject Alternative Names des Zertifikats zu prüfen, die häufig als SANs bezeichnet werden.

Single-Domain-Zertifikate sind für einen einzelnen Dienst übersichtlich und einfach zu verwalten. Sie eignen sich gut, wenn eine Anwendung über einen dedizierten Hostnamen und einen unabhängigen Erneuerungszyklus verfügt.

Wildcard-Zertifikate

Ein Wildcard-Zertifikat schützt eine Domain und ihre Subdomains der ersten Ebene, beispielsweise `shop.example.com`, `api.example.com` und `status.example.com`, unter Verwendung eines Namens wie `*.example.com`. Es eignet sich für Plattformen, auf denen regelmäßig Subdomains hinzugefügt werden, darunter Agenturbereitstellungen, Kundenportale und wachsende SaaS-Umgebungen.

Eine Grenze sorgt immer wieder für Überraschungen: `*.example.com` schützt `example.com` nicht, sofern die Root-Domain nicht separat enthalten ist, und deckt `east.api.example.com` nicht ab. Wildcards decken nur eine Subdomain-Ebene ab. Wenn man dies während eines Launches entdeckt, ist das keine besonders schöne DNS-Situation – kartieren Sie Hostnamen daher vor der Bestellung.

Wildcard-Zertifikate erfordern häufig eine DNS-basierte Validierung, da der Besitz eines Wildcard-Domainschlüssels durch eine DNS-Challenge nachgewiesen werden muss. Das ist normalerweise unkompliziert, wenn der DNS-Zugriff gut organisiert ist, sollte jedoch vor der Auswahl eines automatisierten Erneuerungs-Workflows berücksichtigt werden.

Multi-Domain- oder SAN-Zertifikate

Ein Multi-Domain-Zertifikat, auch SAN-Zertifikat genannt, schützt mehrere bestimmte Hostnamen mit einem einzigen Zertifikat. So kann ein Zertifikat beispielsweise `example.com`, `www.example.com`, `app.example.net` und `customer.example.org` abdecken.

Das ist nützlich für Unternehmen mit mehreren Marken, Agenturen, die verwandte Kundendienste hosten, oder Teams, die ein kontrolliertes Zertifikat für eine festgelegte Gruppe von Endpunkten benötigen. Dadurch kann die Zahl der Zertifikate reduziert werden, es entsteht jedoch auch eine gemeinsame Abhängigkeit. Wenn Sie dieses Zertifikat ersetzen oder widerrufen, kann jeder abgedeckte Hostname betroffen sein.

In großen Umgebungen können separate Zertifikate nach Anwendung, Geschäftsbereich oder für die jeweils zuständige Person zur Erneuerung betrieblich sicherer sein. Weniger Zertifikate bedeuten nicht immer weniger Arbeit, wenn eine Änderung große Auswirkungen hat.

So wählen Sie das richtige Zertifikat

Beginnen Sie mit den Hostnamen, nicht mit dem Produktnamen. Listen Sie jede öffentliche Domain, den Namen `www`, jeden API-Endpunkt, jedes Administrationsportal, jeden E-Mail-bezogenen Endpunkt und jede geplante Subdomain auf, die TLS benötigt. Entscheiden Sie anschließend, ob diese Namen feststehen, unvorhersehbar wachsen oder von unterschiedlichen Teams verwaltet werden.

Ein Single-Domain-DV-Zertifikat reicht normalerweise für eine einzelne Website oder einen einzelnen Anwendungsendpunkt aus. Ein Wildcard-DV-Zertifikat ist häufig die sinnvolle Lösung für eine wachsende Gruppe von Subdomains der ersten Ebene. Ein SAN-Zertifikat eignet sich gut für eine feste Sammlung von Namen über mehrere Domains hinweg. OV- oder EV-Validierung gehört dann in die Entscheidung, wenn Kunden, Richtlinien, Branchenpraxis oder Vertragsbedingungen eine Identitätsprüfung verlangen.

Berücksichtigen Sie auch die Umgebung hinter dem Zertifikat. Wenn der Datenverkehr an einem Load Balancer, Reverse Proxy, CDN oder verwalteten Webserver endet, muss das Zertifikat an diesem TLS-Endpunkt installiert und erneuert werden. Die Installation auf einem Backend-Server hilft nicht, wenn Besucher zuerst eine Proxyverbindung mit einem abgelaufenen Zertifikat herstellen.

Erneuerung, Automatisierung und Betriebsrisiko

Ein abgelaufenes Zertifikat kann Anmeldungen, Checkout-Abläufe, API-Aufrufe und das Browservertrauen mit sehr wenig Vorwarnung für Kunden unterbrechen. Die Zertifikatserneuerung sollte als betriebliche Aufgabe behandelt werden, nicht als Kalendereintrag, den jemand an einem arbeitsreichen Freitag hoffentlich bemerkt.

Verwenden Sie eine automatisierte Erneuerung, sofern Ihr Zertifikattyp und Ihre Validierungsmethode dies ermöglichen. Die DNS-Validierung ist besonders für Wildcard-Zertifikate nützlich, doch die Automatisierung benötigt sicheren Zugriff auf DNS-Einträge. Beschränken Sie diese Zugangsdaten sorgfältig und dokumentieren Sie, wer dafür verantwortlich ist. Bei dateibasierter Validierung müssen Sie sicherstellen, dass Weiterleitungen, Caching-Regeln, Web Application Firewalls und Deployment-Pipelines den Validierungspfad nicht blockieren.

Prüfen Sie nach der Installation oder Erneuerung mehr als nur das Schlosssymbol. Prüfen Sie die Zertifikatskette, die abgedeckten Namen, das Ablaufdatum, das Weiterleitungsverhalten und den TLS-Endpunkt, der den öffentlichen Datenverkehr tatsächlich bedient. Das Monitoring sollte deutlich vor dem Ablauf alarmieren und den von Kunden verwendeten Hostnamen testen, nicht nur eine interne Serveradresse.

Für Teams, die diese betriebliche Last nicht allein tragen möchten, kann Managed-Hosting-Support bei der Zertifikatsinstallation, bei Erneuerungsprüfungen, der DNS-Validierung und dem Service-Monitoring helfen. Bei kodu.cloud besteht das praktische Ziel nicht darin, Zertifikate spannend zu machen. Es geht darum, verschlüsselte Dienste verfügbar zu halten, während Sie sich um die Arbeit kümmern, die die Rechnungen bezahlt.

Wählen Sie den kleinsten Zertifikatumfang, der Ihre tatsächlichen Dienste zuverlässig abdeckt, automatisieren Sie die möglichen Erneuerungen und sorgen Sie für genügend Transparenz, damit ein Mensch die Ausnahmen erkennt. Sicherheit funktioniert am besten, wenn sie auf die bestmögliche Weise langweilig ist.

Andres Saar Kundendiensttechniker