Welche Verschlüsselungs- und Kompatibilitätskriterien sollten vor dem Kauf eines SSL-Zertifikats geprüft werden?

Betrachten Sie das Zertifikat nicht als eine Kleinigkeit, die mit dem Kauf erledigt ist

　　Bei der Bewertung des Kaufs eines SSL-Zertifikats lassen sich Techniker am häufigsten von zwei Dingen in die Irre führen: Sie achten entweder nur auf den Preis oder nur darauf, ob das kleine Schloss angezeigt wird. Beide Kriterien greifen zu kurz. Nach der Inbetriebnahme beeinflussen vor allem die Sicherheit der Verschlüsselungssuites, die Eignung des Protokolls, die ordnungsgemäße Verbindung älterer Endgeräte, die Konfiguration von Servern und Load-Balancern sowie mögliche Kompatibilitätsprobleme der Zertifikatskette die Benutzererfahrung und das Risiko.

　　Wenn sich Ihre Website an internationale Märkte richtet, sind die Herausforderungen noch konkreter. Die Verteilung der Browserversionen unterscheidet sich je nach Region, und auch Geräte in Unternehmensnetzwerken können relativ alt sein. Wenn zusätzlich CDN, WAF, Reverse-Proxy und mehrsprachige Websites gleichzeitig im Einsatz sind, ist die Auswahl des Zertifikats nicht nur eine Sicherheitsfrage, sondern auch eine Frage der Zugriffsstabilität. Die folgende Checkliste eignet sich dazu, vor dem Kauf jeden Punkt einzeln zu prüfen.

Klären Sie zunächst, welche Zertifikatsart Sie kaufen

　　Die Verschlüsselungsfähigkeit wird nicht allein durch die Marke bestimmt; zunächst muss der richtige Zertifikatstyp ausgewählt werden. Üblich sind Zertifikate für einzelne Domains, Wildcard-Zertifikate und Multi-Domain-Zertifikate. Die Entscheidung ist einfach: Prüfen Sie, ob Sie eine Hauptwebsite, Subdomains auf derselben Ebene oder mehrere nicht zusammenhängende Domains schützen möchten.

• Wenn es nur www und die Hauptdomain gibt, reicht ein Zertifikat für eine einzelne Domain normalerweise aus.
• Wenn es viele Subdomains gibt, etwa en.example.com, jp.example.com und shop.example.com, ist ein Wildcard-Zertifikat praktischer.
• Wenn Website, Shop und Kampagnenseite zu unterschiedlichen Domains gehören, erleichtert ein Multi-Domain-Zertifikat die zentrale Verwaltung.

　　Ein häufiges Missverständnis besteht darin, ein Wildcard-Zertifikat als universelle Lösung zu betrachten. Es deckt nur Subdomains auf derselben Ebene ab, nicht tieferliegende Ebenen, und ist nicht für jede Bereitstellungsumgebung geeignet. Teams mit internen Systemen, vielen Edge-Nodes und einer differenzierten Rechteverwaltung möchten möglicherweise nicht einen einzigen großen Schlüssel auf zahlreiche Maschinen verteilen.

Achten Sie beim Public-Key-Algorithmus nicht nur darauf, wie „neu“ er ist, sondern darauf, ob der Server ihn verarbeiten kann

　　Fragen Sie vor dem Kauf eines SSL-Zertifikats zunächst den Anbieter, welche Schlüsselalgorithmen unterstützt werden. In der Regel stehen RSA und ECC zur Auswahl. Technisch gesehen sind die Schlüssel von ECC bei vergleichbarem Sicherheitsniveau kürzer, der Aufwand beim Verbindungsaufbau ist meist geringer, und das Verfahren eignet sich besser für mobile Endgeräte und Szenarien mit hoher Parallelität. RSA bietet dagegen eine breitere Kompatibilität und ist insbesondere in Umgebungen mit älteren Systemen und älterer Middleware stabiler.

　　Bei der Bewertung sollten Sie Ihre Betriebsumgebung berücksichtigen:

• Wenn sich Ihre Zielgruppe überwiegend aus Nutzern neuer Browser und Smartphones zusammensetzt und auch CDN, Nginx und Cloud-Load-Balancer aktuell sind, lohnt es sich, ECC bevorzugt zu prüfen.
• Wenn zu Ihren Zielkunden Einkäufer aus Unternehmen, Geräte in Behörden- und Unternehmensnetzwerken oder ältere Desktop-Umgebungen gehören, verursacht RSA häufig weniger Kompatibilitätsaufwand.
• Bestätigen Sie vor der Ausstellung des Zertifikats, dass Server, CDN und Reverse-Proxy den vorgesehenen Algorithmus und die zugehörige Zertifikatskette unterstützen.

　　Viele Teams wählen nicht das falsche Zertifikat, sondern stellen später fest, dass ein Gerät in der Verbindungskette es nicht unterstützt und die Konfiguration deshalb zurückgesetzt werden muss. Vor dem Kauf die gesamte Verbindungskette zu erfassen, ist deutlich einfacher, als nach der Inbetriebnahme Probleme zu beheben.

Passen Sie die Protokollversion an die jeweiligen Geschäftsnutzer an, statt eine Einheitslösung zu verwenden

　　Bei der Unterstützung von Protokollen geht es heute im Kern um die TLS-Version. Bei der praktischen Bewertung muss klar sein, dass das Zertifikat selbst nicht der einzige Faktor ist, der die Protokollversion bestimmt. Tatsächlich wird die effektive Funktion durch das Zusammenspiel von Zertifikat, Server und Client bestimmt. Mit anderen Worten: Der Kauf eines Zertifikats bedeutet nicht automatisch, dass eine bestimmte TLS-Funktion verfügbar ist.

　　Konzentrieren Sie sich bei der Prüfung auf zwei Punkte: Erstens, ob Ihr Server neuere TLS-Versionen unterstützt, und zweitens, ob ältere Clients aus geschäftlichen Gründen berücksichtigt werden müssen. Wenn Sie internationale B2B-Anfragekunden, Händlerportale oder Zugriffsseiten für ältere Geräte bedienen, sollten Sie nicht einfach nach dem Prinzip „je neuer, desto besser“ vorgehen. Wenn bestehende Kunden nicht zugreifen können, wirkt sich das direkt auf die Conversion aus.

Prüfen Sie die Browserkompatibilität und verlassen Sie sich nicht nur auf die Aussage „von allen gängigen Browsern unterstützt“

　　Anbieter erklären häufig, dass ihre Lösung mit den gängigen Browsern kompatibel ist. Das ist zwar nicht grundsätzlich falsch, hilft bei einer technischen Bewertung jedoch kaum weiter. Tatsächlich müssen Sie prüfen, ob Root- und Intermediate-Zertifikate von den wichtigsten Browsern und Betriebssystemen vertrauenswürdig eingestuft werden, ob die Zertifikatskette vollständig ist und ob es bekannte historische Kompatibilitätsprobleme gibt.

　　Gerade bei Websites für mehrere Regionen wie Nordamerika, Europa sowie Japan und Südkorea beschränken sich die Zugriffswege nicht auf Chrome. Die Vertrauenskette von Safari, das Verhalten älterer Android-Versionen, eingebettete WebViews und unternehmensinterne Browser können dazu führen, dass aus theoretischer Kompatibilität in der Praxis eine Fehlermeldung wird. Lassen Sie sich vor dem Kauf am besten eine eindeutige Kompatibilitätsliste des Anbieters geben und führen Sie anschließend stichprobenartige Tests mit den Zielgeräten durch.

　　Ein weiteres simples, aber häufiges Problem ist eine unvollständige Zertifikatskette. Neuere Browserversionen ergänzen die Kette möglicherweise automatisch, während dies in manchen älteren Umgebungen nicht geschieht. Dadurch sieht für die technischen Kollegen am eigenen Computer alles normal aus, während Kunden die Website nicht öffnen können.

Zertifikatskette, OCSP und Sperrmechanismen nicht erst nach dem Go-live berücksichtigen

　　Viele Kaufgespräche beschränken sich auf die Länge der Verschlüsselung und den Bekanntheitsgrad der Marke. Die Details, die die Stabilität tatsächlich beeinflussen, werden dagegen oft nicht hinterfragt. Dazu gehört beispielsweise, wie Intermediate-Zertifikate bereitgestellt werden, ob OCSP-Antworten ordnungsgemäß funktionieren und ob die Sperrprüfung in der vorgesehenen Netzwerkumgebung den Verbindungsaufbau verlangsamt.

　　Sie müssen nicht jedes Protokolldetail vollständig analysieren. Bei der Auswahl sollten Sie jedoch drei Dinge bestätigen: ob das vom Anbieter bereitgestellte Bereitstellungspaket vollständig ist, ob Ihre vorhandenen Server die gesamte Zertifikatskette korrekt einbinden können und ob sich Anomalien der Zertifikatskette sowie Ablaufgefahren nach dem Go-live überwachen lassen. Bei Websites mit mehreren Nodes ist das weitaus wichtiger als die Frage, welcher Anbieter etwas günstiger ist.

Die Serverkompatibilität bestimmt häufig die späteren Betriebskosten

　　Listen Sie vor dem Kauf des SSL-Zertifikats alle Bereitstellungsziele auf: Nginx, Apache, IIS, Tomcat, Cloud-Load-Balancer, CDN, Kubernetes Ingress, E-Mail-Gateway und API-Gateway. Müssen sie alle durch diesen Kauf abgedeckt werden? Viele Teams gehen davon aus, dass ein „Website-Zertifikat“ nur den Webserver betrifft. Später stellen sie fest, dass statische Ressourcen über das CDN ausgeliefert werden, Schnittstellen über das Gateway laufen und das Backend eine andere Domain verwendet. Am Ende werden für dasselbe Projekt mehrere Zertifikate benötigt.

　　Eine wirklich praktische Lösung ist nicht unbedingt die mit den auffälligsten Parametern, sondern diejenige, die sich reibungslos in Ihre bestehende Architektur einfügt. Bei der Bewertung sollten Sie direkt vier Fragen stellen:

1. Unterstützt das Zertifikatsformat den Import in Ihre bestehende Umgebung?
2. Ist eine automatische Verlängerung möglich, insbesondere bei mehreren Nodes?
3. Wer ist für die Generierung, Speicherung und Verteilung der Schlüssel verantwortlich, und ist der Prozess auditierbar?
4. Kann das Zertifikat mit geringem Risiko ausgetauscht werden, ohne die Website für die Umstellung anhalten zu müssen?

　　Je früher diese Fragen gestellt werden, desto weniger Aufwand entsteht später. Das gilt besonders für Teams, die internationale Marketing-Websites, eigenständige Websites und mehrsprachige Unternehmenswebsites betreiben, denn sobald die Nodes verteilt sind, steigt der Verwaltungsaufwand für den manuellen Zertifikatsaustausch schnell an.

Übersehen Sie nicht die Gültigkeitsdauer und die Art der Verlängerung

　　Bei der technischen Bewertung entsteht häufig der Eindruck, dass die Angelegenheit mit dem abgeschlossenen Kauf erledigt ist. Tatsächlich treten die größten Risiken eines Zertifikats häufig bei der Verlängerung auf. Prüfen Sie daher nicht nur, wie lange das Zertifikat gültig ist, sondern auch, wie die Domainvalidierung bei der Verlängerung erfolgt, ob eine Automatisierung unterstützt wird, wann nach der Aktualisierung des Zertifikats die Caches der nachgelagerten Systeme wirksam werden und ob es Warnmechanismen vor dem Ablauf gibt.

　　Wenn die Unternehmenswebsite SEO-Traffic, Werbe-Landingpages und die Umwandlung von Anfragen übernimmt, kann ein einmal abgelaufenes Zertifikat zu Problemen beim Crawling durch Suchmaschinen, einer Beeinträchtigung der Anzeigenprüfung und fehlgeschlagenen Formularübermittlungen führen. Im Vergleich zu solchen Schäden ist das beim Kauf eingesparte Budget in der Regel den Aufwand nicht wert.

Bei Zugriffen aus mehreren Regionen Performance und Kompatibilität gemeinsam bewerten

　　Bei vielen internationalen Websites besteht das Problem nicht darin, ob eine Verschlüsselung möglich ist, sondern darin, ob der erste Seitenaufruf langsam ist oder der Verbindungsaufbau in bestimmten Ländern zu einer Zeitüberschreitung führt. In diesem Fall sollte die Zertifikatsauswahl gemeinsam mit der CDN-Strategie und der Bereitstellung der Edge-Nodes betrachtet werden. ECC kann weniger Overhead verursachen, setzt aber voraus, dass die Zielclients es unterstützen. RSA ist stabiler, kann jedoch bei hoher Parallelität und schwachen Netzwerkverbindungen einen höheren Aufwand beim Verbindungsaufbau verursachen. Es gibt keine allgemeingültige Antwort; die Entscheidung muss anhand der Geräteverteilung Ihrer Zielgruppe getroffen werden.

　　Manchmal enthalten technische Beschaffungsunterlagen auch Referenzmaterialien, die nicht zum Thema gehören, etwa Inhalte wie Untersuchung zu Maßnahmen zur Verbesserung der Ausführungsquote von Finanzhaushalten öffentlicher Institutionen. Bei der Bewertung von SSL-Zertifikaten sollten Sie Ihre Aufmerksamkeit wieder auf die Zertifikatskette, das Protokoll, den Bereitstellungsweg und die zugreifenden Endgeräte richten und vermeiden, dass irrelevante Materialien Ihre Entscheidungszeit beanspruchen.

Treffen Sie die Entscheidung abschließend in dieser Reihenfolge, um die höchste Effizienz zu erreichen

　　Wenn Sie den Kauf eines SSL-Zertifikats jetzt vorantreiben möchten, gehen Sie am besten in dieser Reihenfolge vor: Erfassen Sie zunächst den Umfang der Domains und Subdomains. Bestätigen Sie anschließend, welche Algorithmen und TLS-Funktionen von Servern, CDN und Gateways unterstützt werden. Treffen Sie danach anhand der Endgeräte in den Zielmärkten eine Entscheidung zwischen RSA und ECC. Prüfen Sie anschließend die Kompatibilität der Vertrauenskette von Browsern und Betriebssystemen und bewerten Sie zuletzt die Automatisierung der Verlängerung sowie die Betriebsprozesse.

　　Eine wirklich ausgereifte Auswahl besteht nicht darin, das „stärkste“ Zertifikat zu wählen, sondern eine Lösung, die in Ihrer Geschäftsumgebung möglichst wenige Probleme verursacht und langfristig am einfachsten zu warten ist. Für technische Bewertungsverantwortliche lautet der Maßstab in einem Satz: Am Tag des Go-live einsatzbereit zu sein, bedeutet noch nicht, dass die Aufgabe abgeschlossen ist. Erst stabile weltweite Zugriffe und eine unkomplizierte spätere Verlängerung zeigen, dass die richtige Wahl getroffen wurde.