CA-Auswahl

Da haben Sie sich nun also entschieden, ein oder mehrere Zertifikate zu kaufen und nun gilt es, eine passende CA zu finden. Und das Problem dürfte ziemlich genau dem eines Häuslebauers entsprechen, der einen Bauträger oder Architekt sucht. Es geht um viel Geld und für einen Laien ist die Branche recht undurchsichtig und ein Preiswettbewerb ist zumindest bei den Architekten nicht offensichtlich.

Bei Zertifizierungsstellen gibt es heute primäre einen Wettbewerb über den Preis, der sich derart zeigt, dass Sie für ein Single-Name Zertifikat zwischen 0 Euro und 500 Euro bezahlen können. Da muss die Frage erlaubt sein, was man dafür erhält bzw. wo der Mehrwert liegt. Denn SSL-Verschlüsseln können Sie mit jedem Zertifikat.

Diese Seite kann und will keine "Empfehlung" für eine bestimmte CA aussprechen, sondern nur die Zusammenhänge und Hintergründe etwas beleuchten und ihnen Eine Checkliste zur eigenen Bewertung anbieten.

Achtung: Google Chrome entzieht Symantec (und Töchter Thawte, VeriSign, Equifax, GeoTrust oder RapidSSL das vertrauen. Symantec verkauft PKI-Geschäft an DigiCert.
Chrome’s Plan to Distrust Symantec Certificates (https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html)

Es ist schon unangenehm, wenn Sie als gegen Geld das "falsche" Zertifikat gekauft haben. Die wenigsten CAs erlauben nämlich das "Zurückgeben". Schließlich hat die CA ihre Dienstleistung vollumfänglich erbracht. Sie hat ihre Identität geprüft, den CRS verarbeitet, das Zertifikat signiert und ausgestellt. Ein bestelltes Essen im Restaurant können Sie ja auch nur zurück gehen lassen, wenn der Lieferant (hier das Restaurant) was falsch gemacht hat.

Die Wahl der RootCA

Es gibt eine ganze Menge von Webseiten, über die Zertifikate bezogen werden können. Bei dem Betreibern der Webseiten mit Shopsystem handelt es sich aber nur zum Teil um die Inhaber der Zertifizierungsstellen selbst (z.B. Thawte, Globalsign, Godaddy), sondern auch Reseller und SubCAs tummeln sich im Markt. Neben den Kosten und dem richtigen Zertifikatstyp ist es wichtig, wer letztlich Stemmzertifizierungsstelle an der Spitze der Kette ist. Denn ein Zertifikat wird nur dann als vertrauenswürdig angesehen, wenn die Root auf dem jeweiligen Endgerät auch installiert ist.

Früher gab es deutlich weniger CAs, welche in den verschiedenen Betriebssystemen vorinstalliert waren. Und da nicht alle CAs auf jeden Betriebssystem vorhanden waren, gab es schon unterschiede über die Nutzbarkeit eines gekauften Zertifikats. Das ist heute nicht mehr so kritisch, da es viele CAs gibt und die meisten schon 99% und mehr Abdeckung bei den Endgeräten erreichen.

Windows 2008 hat selbst nur noch wenige echte "StammCAs" im Installationsmedium aber kennt ein Verfahren, um dynamisch weitere Roots von Microsoft zu beziehen. Parallel gibt es natürlich auch noch für Windows neue "RootUpdates" in Form von Windows Update Paketen. Andere Betriebssysteme (Unix, Mac, Windows Mobile etc.) oder Clients (z.B. Firefox), die nicht auf die Stammzertifikate von Windows aufsetzen, haben eigene Listen von "Trusted Roots", die zu prüfen sind.

Insofern muss ihr Ziel sein, Zertifikate einer Root zu bekommen, die möglichst breit unterstützt wird. Mittlerweile haben aber fast alle CAs, die einige Jahre im Markt sind, eine gute Verbreitung. Knifflig sind daher sehr alte Endgeräte und Clients, die noch eingesetzt werden, z.B. Windows Mobile 5, die nur einer beschränkten Anzahl an RootCAs vertrauen oder es nicht möglich ist, eigene Stammzertifizierungsstellen zu addieren. Nicht gerade einfacher wird dies dadurch, dass StammCAs auch verschwinden oder verkauft werden. Anhand einer Beispiele (Stand April 2011) möchte ich das aufzeigen:

  • Thawte
    Gegründet von Mark Shuttleworth in Süd Afrika als erste CA außerhalb der USA aber wurde schon 2000 von Verisign gekauft
    Quelle: http://www.thawte.com/about/index.html
  • TC Trustcenter
    Wurde Anfang 2010 von PGP übernommen und im Juni 2010 hat Symantec, eines der größten Softwareunternehmen der Welt, TC TrustCenter als Teil der PGP Akquisition übernommen.
    Quelle: http://www.trustcenter.de/about/index.htm
    Achtung: viele RootCAs sind am 1.1.2011 ausgelaufen und die neuen Roots von TrustCenter sind "erst" von 2006 und damit auf Windows Mobiles 6.5 nicht vorhanden.
  • RapidSSL (Siehe Warnung am Anfang des Artikels)
    "RapidSSL 2010. RapidSSL.com is owned and operated by GeoTrust, Inc. GeoTrust is a proven leader in the low-cost SSL market"
    Quelle: hhttp://www.rapidssl.com/about/index.html
  • AlphaSSL
    "We are not any old reseller. AlphaSSL is powered by GlobalSign, the International Certification Authority with its own highly trusted root CA certificates"
    Quelle: http://www.alphassl.com/about.html
  • PositiveSSL
    Hier wird gar nicht mehr verborgen, dass dies eine Marke der Comodo ist. Interessant ist hier nur, dass https://www.positivessl.com von Comodo erstellt wurde aber die von PositiveSSL verkauften Zertifikate als StammCA die Usertrust.com haben.
  • DigiCert
    Einfaches Tool um eine Exchange 2010 CSR-Kommandozeile zu erstellen.
    https://www.digicert.com/easy-csr/exchange2010.htm

Wenn dann noch die gleiche CA unter verschiedenen "Markennamen" auftritt (z.B. Commodo = InstantSSL = PositiveSSL), dann trägt dies nicht zur Klarheit bei. Letztlich kann hier der Rat nur heißen: Nutzen Sie die Option eines kostenfreien Zertifikats von 30-90 Tage, welches mittlerweile jede CA anbietet um den Bearbeitungs- und Bestellprozess können zu lernen und die erhaltenen Zertifikate einer Eignungsprüfung zu unterziehen.

Prüfen Sie auf jeden Fall, welche RootCAs auf den von ihnen vorgesehenen Endgeräten vorhanden sind, Nicht alle StammCAs sind auf allen Endgeräten (insbesondere Mobilgeräte) vorhanden.

  • Certificate-Spider
    https://www.css-security.com/certificate-spider/
    Scannt das Internet auf Port 443 ab um das Zertifikat zu lesen und auszuwerten (Welche CA, welches Hash-Verfahren etc.). Abfallprodukt ist quasi ein Kuchendiagramm der ausstellenden CAs

IntermediateCA und "No frills"-Töchter

In den seltensten Fällen werden Sie aber heute noch ein Zertifikat erhalten, welches direkt von einer RootCA ausgestellt ist. Fast alle CAs betreiben Zwischenzertifizierungsstellen, die die Zertifikate ausstellen und ihrerseits von der Root abgeleitet sind. Das hat den Vorteil, dass die CRL eben von dieser Zwischen-CA bezogen wird und bei einer Kompromittierung nur diese "Intermediate" verbrannt ist. Damit kann die Root noch besser geschützt werden. Insofern ist dies keine Schlechterstellung. Sie müssen bei der Installation des Zertifikat auf ihrem System natürlich noch sicherstellen, dass das Zertifikat der Zwischen-CAs ebenfalls mit auf ihrem Server mit installiert wird. Dieser muss nämlich nicht nur sein Zertifikat sondern auch die Kette bis zur Root an den Client senden.

Dabei muss die Intermediate nicht von der gleichen Firma betrieben werden, wie die RootCA. Natürlich ist es üblich, dass eine Root auch eine eigene Zwischenzertifizierungsstelle hat. Es gibt aber auch die Variante, dass eine andere Firma eine Zertifizierungsstellen einer bekannten RootCA ist, und eigene Zertifikate ausstellt. Oft sind diese Zertifikate sogar deutlich billiger wie z.B.: bei Alphassl.com, deren Root nicht nur von GlobalSign kommt, sondern wohl eine Tochter ist. Supportanfragen an AlphaSSL werden nämlich von GlobalSign beantwortet. Allerdings ist das Leistungsspektrum hier (stand Apr 2011) auf einfache und Wildcard-Zertifikate beschränkt. Das volle Spektrum mit SAN-Zertifikaten oder E-Mail und Codesigning-Zertifikate gibt es nur bei der Mutter. Das ist aber bei Comodo und PositiveSSL.

Reseller und "Vertrauen"

Einige Anbieter von Zertifikaten sind Wiederverkäufer, wie z.B. www.psw.net. Ein Wiederverkäufer nimmt der CA oft die lokale Rechnungsstellung und Überprüfung des Antragstellers ab und bietet ihnen lokalen Support in der Landessprache und eine landestypische Rechnungsstellung an . Eine legitime Möglichkeit für eine CA auch andere Länder zu bedienen ohne selbst in große Vorleistungen zu gehen.
Andererseits bekommt der Reseller für seine Arbeit natürlich einen "Rabatt", den er teilweise auch seine Kunden weiterreichen kann. Weiterhin hat ein Reseller über seinen Zugang zu CA oft Möglichkeiten, die Sie als direkter Kunde der CA nicht haben, d.h. ein Tausch des Zertifikats o.ä.
Insofern sind Reseller nicht immer die "zweite Wahl". DA die Reseller selbst die Prüfung übernehmen kann das natürlich auch nach hinten los gehen, wie im März 2011 geschehen. Angeblich hat ein einzelner Iranischer Computerfreak eine Webseite eines italienischen Reseller gehackt und mit den hinterlegten Anmeldedaten bei Comodo sich Zertifikate für verschiedene bekannte Webseiten ausgestellt.

Zertifikat und Vertrauen

Ein Zertifikat soll die Identität einer Webseite sicherstellen. Wenn ich auf die Homebanking-Seite meines Geldinstituts gehe, erwarte ich nicht nur eine Verschlüsselung der Daten sondern auch die Sicherheit, dass ich diese an den "richtigen" Server gekommen zu sein. Daher müssen die CAs ihre Identität überprüfen. Das kostet Geld und daher gibt es verschiedene "Abstufungen", die Sie als Kunde nur bedingt erkennen können. Sicher können Sie die "Extended Validation"-Zertifikate, bei denen ihre Browser, so der das kann, die Adressleiste "grün" macht.

Dann sollten Sie recht sicher sein, dass Sie auch auf dem Server sind. Aber es gibt auch "billigere" Zertifikate, die mit einer geringeren Haftung verbunden sind aber vom Anwender oder "stillen Zugriffen ohne GUI" wie dies z.B. bei Terminaldiensten oder Lync der Fall ist, nicht unterschieden werden. Einige CAs nehmen sich etwas Zeit und prüfen die Identität anhand einer Telefonauskunft, einem Handelsregisterauszug oder indem Sie gebeten werden, eine HTML-Seite auf der Firmenwebserver oder einen A-Record im DNS der Zone zu addieren. Wer das kann, hat sicher genug Rechte auch mehr unfug zu treiben. Andere senden als "Validierung" eine Mail mit einem personalisierten Validierungscode an eine vordefinierte Adresse (administrator@, Hostmaster@, Admin-C, Tech-C o.ä. ) , um sicherzustellen, dass der Antragstelle auch "admin" oder "Hostmaster" der Webseite bzw. Domain ist. Wenn Domain Inhaber und Webadmin die gleiche Person ist, dann kann das sehr schnell gehen, wie ich an einem 30-Tage-Testzertifikat mit PositiveSSL (Comodo) sehen konnte:

Es hat länger gedauert, den CSR zu erstellen und das Webformular auszufüllen, als das Zertifikat letztlich zu erhalten. für Firmenseiten o.ä. ist das sicher auch ausreichend aber für eine E-Commerce-Webseite möchte ich schon den grünen Balken im Browser sehen. Nicht jede CA stellt übrigens EV-Zertifikate aus.

Ein Thema, was gerne überlesen wird, ist die Haftungsfrage. Da eine CA ja ein Zertifikat signiert, ist meist damit auch eine "Versicherung" verbunden. Angenommen Sie betreiben einen Webshop mit einem Zertifikate und haben den Verdacht, dass ihnen das Zertifikat "geklaut" worden ist oder dass jemand anderes ein Zertifikat auf einen gleichlautenden Namen in betrügerischer Absicht erhalten hat. Dann kann die CA solche Zertifikate natürlich zurückrufen. Das geht nicht "sofort", da die CA zwar sehr schnell eine neue Revocationlist erstellen und publizieren kann, aber nicht alle Clients diese erreichen und dann auch prüfen und selbst dann kann noch ein Cache die Aktualität verzögern. Die CAs stehen für bestimmte Fehler bis zu festgelegten Obergrenzen gerade. Aber welche Grenzen und Fälle dies sind, müssen Sie selbst erfragen oder durch einen Rechtsbeistand prüfen lassen.

Zertifikatstyp

Für verschiedene Zwecke benötigen Sie verschiedene Zertifikate und nicht jede CA stellt jedes Zertifikat aus. So gibt es immer noch CAs, die z.B.: keine SAN-Zertifikate ausstellen können oder vielleicht auch nicht wollen, um der Mutter die Preise nicht zu verderben. Ein einfaches Webserver-Zertifikat mit einem Namen kann aber nahezu jede CA innerhalb von Minuten bis Stunden auszustellen. Selbst Wildcard-Zertifikate sind einfach zu erhalten. Kniffliger wird es bei SAN-Zertifikaten, Zertifikaten für E-Mail-Signierung und Verschlüsselung oder Rechnungssignatur

Allerdings hilft ihnen keinen CA bei der Bestimmung ihrer Zertifikatsanforderungen, d.h. ob ein Wildcard wirklich funktioniert und welche Namen in einem SAN-Zertifikat enthalten sein müssen

Verwaltungsseite

Alle CAs drücken die Kosten, indem Sie ihnen als Kunden eine Webseite geben, mit der Sie ihre Zertifikatsanfrage möglichst komplett selbst einstellen. Personal kostet Geld und Sie haben den Eindruck, die CA wäre 24h dienstbereit. Steht aber eine Validierung per Telefon o.ä. an, dann stellen Sie fest, dass einige CAs doch nur an "normalen" Arbeitstagen arbeiten oder in einer anderen Zeitzone sitzen. Das sind dann Argumente, die für eine geografisch nähere CA oder einen Reseller im gleichen Land sprechen.

Das gleiche Thema kommt beim Bezahlen und der Rechnung auf. Wer in Deutschland lebt und arbeitet, tut sich leichter mit einer Rechnung mit deutscher Umsatzsteuer und Euro. Vielleicht ist es leichter, wenn nicht per Kreditkarte sondern per Rechnung und Überweisung bezahlt wird.

All das sind weniger technische und mehr organisatorische Faktoren, die bei der Wahl der ausstellenden Stelle von belang sind.

Gültigkeitsdauer, Schlüssellänge, Einsatzbereich

Nicht unwichtig aber ehr unkritisch sind die sonstigen Faktoren eines Zertifikats.

  • Gültigkeitsdauer
    Die Mindestlaufzeit, von Testzertifikaten abgesehen, beträgt heute 1 Jahr. Jede CA bietet ihnen natürlich auch eine längere Gültigkeitsdauer an, die entsprechende mehr kostet.
  • Schlüssellänge
    Es ist klar, dass 1024bit zu kurz sind, da diese kurzen Schlüssel in naher Zukunft durch die Nutzung der GPUs auf Grafikkarten wohl geknackt werden können. Die meisten Zertifizierungsstellen lehnen daher solche Anfragen ab und erwarten mindestens 2048bit Schlüssellänge. Extrakosten entstehen dadurch nicht.
  • MultiServer
    Die meisten CAs beschränken den Einsatz der Zertifikate nicht mehr auf genau einen Server. Wer also z.B. mehrere Server unter einem Namen betreibt (Hochverfügbarkeit, Lastverteilung) sollte dies aber sicherstellen. Auch wenn es technisch eine CA nur schwer überprüfen oder unterbinden kann, sollten Sie diesen Sachverhalt klären.
  • Private Namen und IP-Adresse
    Wer z.B. mangels Reverse-Proxy das Zertifikat auf einem Server installiert, welcher von extern mit einem offiziellen Namen und von intern mit einem "privaten Namen" erreichbar sein soll, muss mit SAN-Zertifikaten arbeiten. Nicht alle CAs erlauben hier intern "nicht offizielle" Namen oder gar IP-Adressen, da Sie diese nicht wirklich prüfen können. Besonders ungeschickt ist es, intern einen Namen zu verwenden, der offizielle anderweitig verwendet wird. So gehört die Toplevel-Domain "int" den "Internationalen Organisationen" wie NATO, UN etc. Es ist ungeschickt, wenn ihre interne AD-Domain also mit ".int" endet.

Resümee

Zertifikate bekommen sie an vielen Stellen zu sehr unterschiedlichen Preisen. Wer nur mal schnell ein "Single Server" oder ein "Wildcard"-Zertifikat braucht und keinen Beschränkungen bezüglich der Rechnungsstellung unterliegt, kann eigentlich sich umschauen, welche CA gerade welchen Preis dazu aufruft. Vielleicht reicht sogar ein kostenfreies Zertifikat von StartSSL.com, auch wenn man dann jedes Jahr neu ein Zertifikat beantragen muss.

Wer exotische Endgeräte unterstützen muss, sollte vorab die dort vorhandenen Stammzertifizierungsstellen in Erfahrung bringen. Auch die Ausstellung von SAN-Zertifikaten schränkt die Auswahl der CAs ein, so dass nur noch wenige "Billigheimer" übrig bleiben.

Ich kann ihnen nur dazu raten, die angebotenen Testzertifikate zu nutzen, um zum einen den Prozess der Anforderung und Installation können zu lernen als auch die Funktion zu überprüfen.

Weitere Links