Sicherheitszertifikate – Grundlagen, Einsatzgebiete und Erstellung

Was sind Zertifikate?

Ein digitales Zertifikat ist ein elektronischer Ausweis im Internet. Es bestätigt die Identität eines Gerätes, einer Website oder eines Benutzers und stellt sicher, dass die Kommunikation verschlüsselt und authentisch ist. Dabei kommen Public‑Key‑Infrastrukturen (PKI) zum Einsatz: ein Zertifikat enthält den öffentlichen Schlüssel seines Inhabers, Angaben zum Namen, zur Domain oder IP‑Adresse und zur Gültigkeitsdauer sowie eine digitale Signatur der ausstellenden Zertifizierungsstelle (CA). Mithilfe dieser Signatur kann ein Browser oder ein anderes Gerät die Echtheit des Zertifikats prüfen und so eine sichere Verbindung aufbauen.

Stell Dir ein Zertifikat wie einen digital signierten Personalausweis vor. Du kannst es zwar lesen, aber ohne den entsprechenden Schlüssel niemanden täuschen. Erst die digitale Signatur einer vertrauenswürdigen CA macht das Zertifikat gültig. Moderne Browser und Betriebssysteme halten eine Liste vertrauenswürdiger Stammzertifikate in ihren sogenannten root stores, die streng kontrolliert werden. Zertifikate, die von diesen Wurzeln abgeleitet sind, werden automatisch akzeptiert.

Einsatzgebiete

Zertifikate begegnen uns an vielen Stellen im digitalen Alltag. Sie sorgen dafür, dass wir sensible Daten austauschen können, ohne dass Unbefugte mitlesen. Hier einige wichtige Beispiele:

Websites und HTTPS

Das wohl bekannteste Einsatzgebiet sind SSL/TLS‑Zertifikate für Websites. Wenn Du eine HTTPS‑Seite aufrufst, findet im Hintergrund ein SSL/TLS‑Handshake statt: Dein Browser erzeugt ein Schlüsselpaar, der Server schickt sein Zertifikat, der Browser prüft es anhand der Kette aus Stamm‑ und Zwischenzertifikaten und handelt einen Session‑Schlüssel aus. Nur wenn alle Schritte erfolgreich sind, erscheint das Schloss‑Symbol im Browser und der Datenverkehr ist verschlüsselt.

Telematikinfrastruktur (TI)

Die elektronische Gesundheitskarte und der dazugehörige Telematikinfrastruktur (TI) in Deutschland nutzen ebenfalls Zertifikate. TI‑Konnektoren, Praxisverwaltungssoftware (PVS) sowie Heilberufeausweise (eHBA) und Praxisausweise (SMC‑B) besitzen jeweils eigene Zertifikate mit einer Laufzeit von fünf Jahren. Ab 2026 müssen alle Komponenten ECC‑verschlüsselt werden; ältere RSA‑Konnektoren und gSMC‑K‑Karten müssen deshalb ausgetauscht werden. Wer seine TI‑Komponenten rechtzeitig aktualisiert, vermeidet Ausfälle beim Zugriff auf das Versichertenstammdatenmanagement.

Dateiübertragung: SFTP vs. FTPS

Bei der gesicherten Dateiübertragung kommen zwei Protokolle zum Einsatz: SFTP basiert auf dem SSH‑Protokoll und nutzt typischerweise Schlüsselpaare zur Authentifizierung; die Daten werden nach erfolgreicher Authentisierung über Port 22 in einem einzigen Kanal übertragen. FTPS hingegen erweitert das alte FTP um SSL/TLS und verwendet digitale Zertifikate, um Server und Client gegenseitig zu authentifizieren. Es nutzt separate Steuer‑ und Datenkanäle und verlangt oft, dass zusätzlich zu Benutzername und Passwort ein Zertifikat bereitgestellt wird.

Code‑Signierung

Software‑Entwickler signieren ihre Programme mit speziellen Code‑Signing‑Zertifikaten, um nachzuweisen, dass der veröffentlichte Code von ihnen stammt und seit der Signatur nicht manipuliert wurde. Beim Signieren wird aus dem Code ein kryptographischer Hash gebildet, dieser mit dem privaten Schlüssel des Entwicklers signiert und zusammen mit dem Zertifikat ausgeliefert. Betriebssysteme und Browser prüfen die Signatur und warnen Nutzer, wenn die Signatur ungültig oder das Zertifikat abgelaufen ist. Neben den klassischen Zertifikaten für Einzelpersonen gibt es auch Organisations- und Extended‑Validation‑Code‑Signaturen, die besonders strenge Prüfungen erfordern. Der Vorteil: signierter Code wird von Systemen als vertrauenswürdig erkannt, was weniger Sicherheitswarnungen und mehr Anwendervertrauen bedeutet.

Zertifikatstypen und Unterschiede

Nicht jedes Zertifikat ist gleich. Je nach Einsatzbereich unterscheiden sich Validierungsstufe, Namensraum und Gültigkeit. Hier ein Überblick:

Domain‑, Organisations‑ und Extended‑Validation

SSL/TLS‑Zertifikate lassen sich nach der Tiefe der Überprüfung unterscheiden:

Wildcard‑ und Multi‑Domain‑Zertifikate

Neben der Validierungsstufe ist auch der Geltungsbereich wichtig. Ein Single‑Domain‑Zertifikat gilt für genau eine Domain (z. B. www.example.com). Ein Wildcard‑Zertifikat deckt alle Subdomains einer Domain ab (*.example.com), und Multi‑Domain‑Zertifikate (SAN/UCC) erlauben die Absicherung mehrerer Domains und Subdomains in einem Zertifikat. Diese Optionen sind praktisch für größere Web‑Präsenzen oder SaaS‑Anbieter, da nur ein Zertifikat verwaltet werden muss.

Stamm‑ und Zwischenzertifikate

Um das Risiko zu minimieren, verwenden Zertifizierungsstellen eine Kette aus Root‑ und Intermediate‑Zertifikaten. Stammzertifikate (Root Certificates) liegen im Root‑Store des Betriebssystems oder Browsers und besitzen höchste Vertrauensstufe. CAs nutzen diese Wurzeln jedoch selten direkt, weil ihr Verlust gravierende Folgen hätte. Stattdessen signieren sie damit Zwischenzertifikate, die wiederum Server‑Zertifikate ausstellen. Dieser Aufbau, die sogenannte Certificate Chain, ermöglicht es Browsern, ein Server‑Zertifikat bis zur vertrauenswürdigen Wurzel zurückzuverfolgen. Fehlt ein Zwischenzertifikat, kann der Browser die Kette nicht aufbauen und lehnt die Verbindung ab.

Server‑, Client‑ und Geräte‑Zertifikate

Während SSL/TLS‑Zertifikate meist Server authentifizieren, gibt es auch Client‑Zertifikate für Benutzer oder Geräte. Sie erlauben beispielsweise den sicheren Zugang zu Unternehmens‑VPNs oder Zero‑Trust‑Umgebungen. In der Telematikinfrastruktur werden SMC‑B‑ und eHBA‑Karten als hardwarebasierte Zertifikate verwendet. Geräte‑Zertifikate finden sich in IoT‑Umgebungen oder TI‑Konnektoren, um sicherzustellen, dass nur autorisierte Geräte miteinander kommunizieren.

Wie werden Zertifikate erstellt?

Ob Website, Konnektor oder Code‑Signatur – jedes Zertifikat entsteht in einem definierten Prozess. Die folgenden Schritte sind typisch für die Ausstellung eines SSL/TLS‑Zertifikats durch eine CA; bei Code‑Signing‑ oder Client‑Zertifikaten ist der Ablauf analog.

Schlüsselpaar und Certificate Signing Request (CSR)

Zunächst generiert der Antragsteller ein Schlüsselpaar aus privatem und öffentlichem Schlüssel. Mit Tools wie openssl lässt sich beispielsweise ein RSA‑ oder ECC‑Schlüssel erzeugen. Anschließend erstellt er einen Certificate Signing Request (CSR), der den öffentlichen Schlüssel und Identitätsinformationen wie Domain, Organisation und Standort enthält. Dieser CSR wird an die Zertifizierungsstelle geschickt.

Validierung durch die CA

Die CA prüft je nach Zertifikatstyp die Domain und – bei OV/EV – die Unternehmensdaten. Im Fall von Let’s Encrypt geschieht das automatisiert über das ACME‑Protokoll: Der Client beweist per HTTP‑ oder DNS‑Challenge, dass er die Domain kontrolliert, erst danach stellt die CA das Zertifikat aus. Bei EV‑Zertifikaten werden zusätzlich Handelsregistereinträge, Ausweiskopien und die Identität des Zeichnungsberechtigten geprüft.

Signierung und Auslieferung

Erst wenn die Validierung abgeschlossen ist, signiert die CA den CSR mit dem privaten Schlüssel ihres Zwischenzertifikats. Die Signatur garantiert, dass der öffentliche Schlüssel und die angegebenen Daten zusammengehören und nicht manipuliert wurden. Anschließend wird das fertige Zertifikat zusammen mit dem benötigten Intermediate‑Zertifikat ausgeliefert. Auf dem Server installiert werden müssen also stets: das eigene Zertifikat, das Intermediate und optional die gesamte Kette.

Self‑Signed‑Zertifikate

Für Tests oder interne Systeme lassen sich auch Self‑Signed‑Zertifikate erzeugen. Hier unterschreibt der Besitzer das Zertifikat selbst – es gibt also keine Kette und keine unabhängige Prüfung. Der Vorteil: schnell und kostengünstig. Der große Nachteil: Browser und Geräte vertrauen solchen Zertifikaten nicht automatisch, weshalb Warnungen angezeigt werden und das Risiko von Man‑in‑the‑Middle‑Angriffen steigt. Wer ein Self‑Signed‑Zertifikat produktiv nutzen will, muss es manuell in den eigenen Trust‑Store importieren oder alle beteiligten Clients konfigurieren.

Zertifikat‑Management und Sicherheit

Die Arbeit mit Zertifikaten endet nicht mit der Ausstellung. Folgende Aspekte sind essenziell für den sicheren Betrieb:

Gültigkeitsdauer und Verlängerung

Server‑Zertifikate haben meist eine begrenzte Laufzeit von 12 bis 24 Monaten; in der TI beträgt die Gültigkeit fünf Jahre. Vor Ablauf müssen sie erneuert werden, sonst verweigern Browser und Dienste die Verbindung. Moderne ACME‑Clients automatisieren diesen Prozess und erneuern Zertifikate rechtzeitig. Für TI‑Komponenten sollten Ärztinnen und Ärzte ihre PVS‑Software im Blick behalten, sie weist auf ablaufende Konnektor‑Zertifikate hin. Konnektoren ohne ECC‑Fähigkeit müssen bis Ende 2025 ersetzt werden.

Widerruf: OCSP und CRL

Wenn ein privater Schlüssel kompromittiert oder eine Domain nicht mehr gültig ist, muss das Zertifikat vor Ablauf widerrufen werden. Zwei Standardverfahren stellen den Sperrstatus bereit: Certificate Revocation List (CRL) und Online Certificate Status Protocol (OCSP). Eine CRL ist eine regelmäßig aktualisierte Liste widerrufener Zertifikate, die von der CA veröffentlicht wird; Browser müssen sie herunterladen und prüfen. OCSP hingegen erlaubt eine Echtzeit‑Abfrage beim OCSP‑Responder der CA, der den Status (gut/revoked/unknown) zurückgibt. Viele moderne CAs stellen „OCSP Stapling“ bereit, bei dem der Server einen vom OCSP‑Responder signierten Status mitliefert, um die Performance zu erhöhen. Beide Mechanismen sind wichtig, da Angreifer sonst ein kompromittiertes Zertifikat bis zum Ablauf nutzen könnten.

RSA vs. ECC

Lange Zeit war RSA die vorherrschende Verschlüsselung für Zertifikate. Durch die wachsende Leistungsfähigkeit von Computern setzen immer mehr CAs auf Elliptic‑Curve‑Cryptography (ECC), die bei kürzerer Schlüssellänge dieselbe Sicherheit bietet. In der Telematikinfrastruktur müssen ab 2026 alle Komponenten ECC‑fähig sein. In anderen Bereichen stehen RSA und ECC derzeit parallel zur Verfügung. Wichtig ist, dass Server und Clients denselben Algorithmus unterstützen.

Tipps und Best Practices

• Automatisiere die Erneuerung: Nutze ACME‑Clients wie Certbot oder deine PVS‑Software, um Zertifikate rechtzeitig zu erneuern. Vergessene Verlängerungen führen zu Ausfällen und Fehlermeldungen.
• Verwalte private Schlüssel sicher: Bewahre private Schlüssel ausschließlich auf vertrauenswürdigen Systemen auf. Für besonders sensible Schlüssel sind Hardware‑Security‑Module (HSM) empfehlenswert.
• Nutze starke Algorithmen: Wähle moderne Algorithmen wie ECC oder zumindest RSA mit 2048 Bit. Prüfe regelmäßig, ob deine Systeme älteren Standards wie SHA‑1 verwenden und aktualisiere sie.
• Überwache den Sperrstatus: Stelle sicher, dass deine Server OCSP‑Stapling aktiviert haben und dass Browser den Status schnell abrufen können. Für interne Zertifikate kann eine eigene CRL wichtig sein.
• Plane den Wechsel zu ECC: Gerade im Gesundheitswesen ist der Umstieg Pflicht. Prüfe frühzeitig, ob Konnektoren, PVS, eHBA‑ und SMC‑B‑Karten ECC unterstützen und plane den Austausch rechtzeitig.
• Verwende Self‑Signed‑Zertifikate nur intern: Für öffentliche Websites und Dienste solltest Du immer ein Zertifikat einer vertrauenswürdigen CA verwenden, um Fehlermeldungen und Sicherheitsrisiken zu vermeiden.

Fazit

Digitale Zertifikate sorgen dafür, dass unsere Daten geschützt, unsere Identitäten bestätigt und unsere Anwendungen vertrauenswürdig sind. Von der einfachen Blog‑Seite bis zur elektronischen Patientenakte – überall spielen sie eine zentrale Rolle. Je besser Du die Funktionsweise und die unterschiedlichen Typen verstehst, desto souveräner kannst Du mit Zertifikaten arbeiten und Sicherheitsrisiken vermeiden. Ob Du nun Deine Website mit HTTPS schützt, Dateien per FTPS überträgst oder TI‑Konnektoren betreibst: Es lohnt sich, die eigenen Zertifikate im Blick zu behalten und sich rechtzeitig auf neue Standards wie ECC einzustellen.