Vorbereitung auf eine «Post-Quantum»-Welt?

Am 3. März 2023 hat Google einen Vorschlag zur Reduzierung der maximalen Gültigkeit von TLS- Server-Zertifikaten veröffentlicht. Es wird noch eine Weile dauern, bis sich diese Änderung durchsetzt, aber dass dieser Schritt sinnvoll und gut für die Sicherheit im Web ist, steht sicherlich ausser Frage.

Weitere Punkte und deren Gründe sind auch noch interessant:

• • Gültigkeit der untergeordneten Zertifizierungsstellen auf drei Jahre:
    • Vermeidung von Key Pinning
    • Förderung der Automatisierung und damit der Zuverlässigkeit der operativen Aufgaben
  • Das Online Certificate Status Protocol (OCSP) soll optional werden,
    • da OCSP-Anbieter wohl aus der Browser History Informationen abgegriffen haben
    • und um Kosten zu vermeiden.
  • Vereinfachung
  • Dedizierte Public-Key-Infrastruktur (PKI), um die Anforderungen besser abzustimmen und umzusetzen.

Wenn das so eingefordert wird, dann wird man alle Zertifikatsaustellverfahren und vor allem das Erneuern der Zertifikate automatisieren müssen. Man setzt hier von Google stark auf das Automatic Certificate Management Environment (ACME, RFC 8555) und man könnte böserweise behaupten, dass man hier «Let’s encrypt» pushen will, aber es gibt Alternativen. Mit ARI ACME Renewal Information (Draft RFC) verspricht man sich eine bessere Steuerung der Belastungen und auch eine nahtlose Umstellung auf Post-Quantum-Cryptography- (PQC-) Algorithmen, aber die Trust Center müssen nachrüsten und sind auch dabei.

• • www.digicert.com/solutions/security-solutions-for-automation
  • www.swisssign.com/en/managed-pki/managed-pki-service/

• • Erhöhung der Rechenschaftspflicht der Integrität des Ökosystems der Trust Center
  • Im Zusammenhang mit der verkürzten Gültigkeit der TLS-Zertifikate wird auch vorgeschlagen, die Domain-Validierung-Zeitraum zu reduzieren.

Man möchte unabhängige Kriterien schaffen, um Bewertung der Zertifikatsaussteller unabhängig vom Umfang der auszustellenden Zertifikate und der geografischen Lage zu beurteilen.

Das machte natürlich auch die Runde bei den öffentlichen Zertifizierungsstellen und die verschiedenen Anbieter haben dazu Stellung bezogen:

• • www.digicert.com/blog/chromes-proposed-90-day-certificate-validity-period
  • www.digicert.com/blog/googles-moving-forward-together-proposals-for-root-ca-policy
  • sectigo.com/resource-library/google-announces-intentions-to-limit-tls-certificates-to-90-days-why-automated-clm-is-crucial

Wir können davon ausgehen, dass sich diese Richtlinie früher oder später durchsetzen wird und eine Automatisierung des Zertifikatmanagements für öffentlich vertrauenswürdige Zertifikate unumgänglich ist.

Als Vorbereitung können wir mal Systeme erfassen, die TLS-Zertifikate verwenden und die Möglichkeiten, wie sich dort der Prozess der Zertifikatserneuerung automatisieren lässt. Oder man bezieht die Zertifikate für ein System des Unternehmens und schaut die Verteilung und Nutzung dann intern an, vor allem für Systeme, die keine Automatisierung unterstützen.

Auf der anderen Seite stehen die Anbieter für diese TLS-Zertifikate, die sicherlich Mechanismen zur Automatisierung anbieten werden. Um diese Prozesse wirklich in den Griff zu bekommen, müssen sich beide Seiten verstehen. Ein Zertifikatmanagement lässt sich besser mit entsprechenden Lösungen orchestrieren.

Diese Systeme verstehen auf der einen Seite viele verschiedene Mechanismen zur Ausstellung von Zertifikaten für die Requester, unsere Server, Appliances und Cloud-Instanzen und auf der anderen Seite die verschiedenen Trust Center, von denen wir Zertifikate beziehen. Hier können wir den Workflow definieren und beide Seiten zusammenbringen, inklusive entsprechender Notifications, Alertings, Logs-Status, Ticketingsysteme, ldap-Anbindungen, IdP … usw.

Mechanismen zur Zertifikatsausstellung und -erneuerung sind dann zum Beispiel:

• • «based on profile»-Formular
  • Certificate-Service-Request-basiert (CSR)
  • Agent-based
  • Certificate Management Protocol (CMP)
  • Certificate Management over CMS (CMC)
  • Simple Certificate Enrollment Protocol (SCEP)
  • Enrollment over Secure Transport (EST)
  • Automated Certificate Management Environment (ACME)
  • MS-DCOM

Es gibt keine Aussagen zu den internen Zertifizierungsinstanzen (private trusted CAs), aber dort ist eine Automatisierung schon lange gut vorangeschritten, man muss diese Mechanismen auch nutzen. Dennoch bleiben dann Aufgaben wie Monitoring, Alerting, die via Scripting entwickelt werden müssen.

Um all diese verschiedenen Aspekte zusammenzubringen, braucht es einen Vermittler zwischen den Zertifikatsrequestern und den Certificate Authorities, die basierend auf Richtlinen und Vorlagen die Anfragen koordinieren. Abgerundet wird das mit den notwendigen starken Authentisierungen, Rollenkonzept, Monitoring und Alerting. Mit essendi xc ist nun auch ein Anbieter in der Schweiz verfügbar, mit dem wir all diese Fragen angehen können.

Eine aktive Zertifikatsverwaltung bedingt ein System, das beide Seiten zusammenbringt und alle eingesetzten Zertifikate des Unternehmens im Griff hat, flexibel für alle Systeme die Zertifikate beziehen soll und dabei die Anfragen an die externen und internen Zertifizierungsinstanzen weiterleiten kann. Dabei gilt es zu steuern, wer die Berechtigung hat, welches Zertifikat auf welchen Systemen aktualisiert wird, entsprechende Personen zu informieren und die Authentisierung und die Kommunikation sicher abzubilden.