Certificate Management and Automation

Die Gültigkeit der Zertifikate von öffentlichen TrustCentern (CAs) wird in den nächsten Jahren auf 47 Tage reduziert. Dazu hatte schon Lenti einen Artikel geschrieben.

Hier eine Übersicht zu den Anpassungen bis 2029:

Die DNS-Validierung muss von der CA alle 10 Tage erneut überprüft werden, der DNS-Eintrag selbst kann jedoch statisch bestehen bleiben. Siehe https://www.swisssign.com/en/blog/ca-browser-forum/dns-txt-record-dcv-method-sc088.html

Für OV- und EV-Zertifikate werden die Identitätsinformationen nur noch für 398 Tage validiert werden.
Mehr Infos dazu finden Sie hier.

Wir lösen hiermit das Versprechen aus diesem Artikel vom Dezember letzten Jahres ein und wollen hier DigiCert Trust Lifecycle Manager – TLM genauer betrachten. Ein weiterer Aspekt der verkürzten Laufzeiten ist die erhöhte Flexibilität beim Wechsel von einem TrustCenter zu einem anderen sowie beim Umstieg auf neue Algorithmen. Der Q-Day steht schliesslich quasi schon vor der Tür.

Auch das hatte ich bereits in meinem PQC-Artikel angesprochen und neueste Entwicklungen bei Google rücken das Thema PQC – Post Quantum Cryptography, was eigentlich QuantenComputer Resistant Cryptography heissen sollte, nach vorn auf 2029.

Laut dem Swiss Financial Innovation Desk (FIND) ist “The risk of quantum computing attacks is real and increasing, with potential breakthroughs predicted as early as 2028” möglicherweise sogar noch früher! Betrachtet man dies im Kontext von „Harvest Now – Decrypt Later“ (HNDL) oder digitalen Signaturen, wird deutlich, dass wir bereits heute handeln müssen, damit die durch Zertifikate geschützten Daten auch in mehreren Jahren noch sicher bleiben.

i. Inventarisierung
Wenn man weiss, was man hat, kann man das auch ändern.

ii. Step-by-step Umsetzung
Nach Möglichkeit und Priorität an die neue Kryptographie wagen.

iii. Umfassende Umstellung
Umstellung der gesamten Kryptographie rechtzeitig vor dem Q-Day.

Damit wir in Zukunft nicht jeden Monat manuell Zertifikate erneuern müssen, werden wir wohl um eine Automatisierung nicht drum herumkommen.

Der einfachste Fall wäre, wenn wir ein Deployment-Verfahren hätten, um die Zertifikate auszustellen und zu erneuern.
Auch wenn es verschiedenste Protokolle dafür gibt, hat sich ACME in den letzten Jahren als Quasi-Standard entwickelt, den viele TrustCenter unterstützen. Auf der anderen Seite unterstützen nicht alle Server, Appliances, Loadbalancer und Applikationen heute ACME. Eine Übersicht (Monitoring, Alerting), Workflows, Discovery sowie all die üblichen und notwendigen Integrationen für ein Enterprise-like Management sind mit einem einzelnen Protokoll noch nicht abgedeckt. Auch das Zurückziehen von Zertifikaten sowie die heute notwendige Integration mit dem DNS wären wohl sehr willkommen.

Ein übliches Certificate Enrolment umfasst also nicht das pure Ausstellen oder Erneuern der Zertifikate, sondern auch das Binden an den Dienst, den WebService  oder die Installation des Zertifikats in der Applikation. Das kann auch bedeuten, dass das Zertifikat auf dem Host A erneuert wird und von dort aus per ssh oder Rest-API auf dem Host B installiert wird, wenn der Host B nicht selbst entsprechende Verfahren für die Zertifikate unterstützt.

Wie bringen wir nun die beiden Seiten zusammen?

Wie üblich setzen wir eine «Spinne» in unsere IT-Landschaft, um die verschiedenen Komponenten zu verbinden. Eine gute Wahl ist nach unserem langen Evaluationsprozess DigiCert TLM. Insbesondere das TLM – Trust LifeCycle Management verbindet die Antragsteller mit den CAs und bietet die notwendigen Funktionen für die Integration und Effektivität.

Wie angedeutet, haben wir verschiedene Systeme, die mit Zertifikaten versorgt werden müssen. Der einfache Fall ist, dass der Certificate-Requester ein Enrolment-Protocol unterstützt und damit das Zertifikat auch vom System genutzt wird. Das kann auch direkt mit der bevorzugten CA erfolgen.

Oft ist es aber nicht so einfach, vor allem, wenn kein Enrolment-Protokoll unterstützt wird oder das Zertifikat noch an die entsprechenden Dienste gebunden werden muss.

Unter Umständen muss ein pfx (PKCS#12-container) in die Applikation importiert werden. Also brauchen wir ein Enrolment der Zertifikate sowie einen Post-Enrolment-Schritt (Binding), um die Zertifikate nutzbar zu machen.

Mit verschiedenen Ansätzen bietet das TLM entsprechende Unterstützung und Flexibilität durch:

• Connectoren für spezifische Produkte
• den TLM-Agenten als erweiterten ACME-Client mit Unterstützung von Post-Configurations
• Enrolment-Protokolle (SCEP, EST, CMPv2, ACME)
• REST-APIs
• Sensoren für das Discovery der Zertifikatsnutzung
• den DigiCert Trust Assistant für macOS

Die andere Seite sind die Zertifikatsprofile und von welchen TrustCentern (Certificate Authorities) diese ausgestellt werden müssen.

Die ganze Konfiguration muss über die Zeit überwachbar und flexibel anpassbar sein, so dass man zum Beispiel von einer CA zu einer anderen wechseln kann. Das ist bei einem Anbieterwechsel recht nett, aber in Zukunft bei einem Wechsel der Algorithmen noch viel wichtiger. Discovery, Notification, Alerting und Reporting runden dann so ein Management ab.

Für die internen Zertifikate ist die Situation etwas anders. Die Laufzeiten der Zertifikate sind nicht so unter Druck, aber das Ersetzen der Zertifikate mit den künftigen Quanten-Computer resistenten Algorithmen sehr wohl.

Hier sind die Themen eher beim Management und bei Discovery:

• Wo sind welche Zertifikate im Einsatz und mit welchen Parametern?
• Wie wurden diese ausgerollt und können diese ersetzt werden?
• Wer ist zu informieren?

Die oft verwendeten Microsoft CAs sind da nicht gut aufgestellt. Das Microsoft AutoEnrollment ist gut implementiert, aber Zertifikatsmanagement ist, vorsichtig gesagt, rudimentär.

Auch wenn die Microsoft .Net API mit den Quanten-Computer resistenten Algorithmen letztes Jahr verabschiedet wurde (man kann das mit certutil -v -csptlist „aluege“), ist die Unterstützung für PQC-Zertifikate bei der Microsoft ADCS Certificate Authority wie ML-DAS und ML-KEM noch nicht implementiert. Am Client konnte man das zumindest in den Windows-Insider Releases schon testen.

Auch hier kann TLM mit der Einbindung der vorhandenen MS CA oder auch einer private trusted DigiCert CA zur entscheidenden Komponente für ein umfassendes Zertifikatsmanagement im Unternehmen werden.

Eine CA mit PQC-Algorithmen ist ebenfalls bereits verfügbar, wodurch die Vorbereitung auf neue Zertifikate mit ML-DSA oder ML-KEM bereits angegangen werden kann.

Für dieses umfassende Management ist auch die Integration und Nutzung bestehender Komponenten sinnvoll. Dazu gehören unter anderem Discovery-Lösungen wie Qualys oder Tenable, sowie ServiceNow, E-Mail-Systeme und DNS.

Die Sichtbarkeit, Nachvollziehbarkeit sowie das Erkennen verwendeter Algorithmen und möglicher Fehlkonfigurationen ist die Basis für schnelle Anpassungen an aktualisierte Anforderungen. So spart man am Ende des Tages Zeit, Nerven und stärkt die Crypto-Agilität.

Für das Zertifikatsmanagement und die generelle Zertifikatssicherheit sind DNS-Einträge heute notwendig.

Zur Sicherstellung, von welcher CA die eigenen Zertifikate stamme und zur Vermeidung von Man-in-the-Middle-Angriffen sollten die CAs auch im DNS hinterlegt sein. Beim Wechsel einer CA ist dies entsprechend anzupassen.

Dazu gibt es verschiedene Artikel auf unserem Blog.

Es gibt verschiedene Verfahren und auch hier kann die Integration eine Vereinfachung des Managements und Konsistenz gewährleisten.

Domain-validated certificate – Wikipedia

• Response to email sent to the email contact in the domain’s whois details
• Response to email sent to a well-known administrative contact in the domain, e.g. (admin@, postmaster@, etc.)
• Publishing a DNS TXT record
• Publishing a nonce provided by an automated certificate issuing system

Bei der Verwendung des ACME-Protokolls ist die Aktualisierung der Einträge vom ACME-Client via API sicherlich in Kürze ein Must-Have.

Automatic Certificate Management Environment – RFC8555

1. Registration: Account wird basierend auf asymmetrischem Schlüsselpaar (ECC – ES256 – ECDSA (P-256) mit SHA256 zum Beispiel) erstellt.
2. Zertifikatsausstellung / -Erneuerung *
   1. Order – Start der Anfrage für ein Zertifikat
   2. Prove – Verifizieren der Identifier (subject names, san) in der order
   3. CSR senden
   4. Zertifikat ausstellen und downloaden

Certificate requests: Die JWS werden dabei mit dem private key des ACME-Clients signiert. ACME-Server prüft den Antrag (signature validation und der Domain Validation – via DNS-01 oder http-01

DNS-01 challenge

• Für wildcard-certificates notwendig
• TXT record _acme-challenge.domain.tld sollte via API automatisch aktualisierbar sein (ACME-Client generiert den Eintrag Token + thumbprint account key).
• Ersetzt http-01 challenge (server muss dann nicht via port 80 erreichbar sein)

Diese Einträge im Griff zu haben ist also nicht nur hilfreich, sondern vor allem notwendig und für die Vermeidung von Fehlern fundamental.

Und wenn man DNS-Zonen verwalten will, dann bitte doch alles an einem Ort.

https://docs.digicert.com/en/digicert-dns/features-and-functions/record-configuration-and-management.html

Eine Übersicht zu weiteren Integrationen finden Sie hier.

Die neue Gültigkeitsdauer von TLS-Zertifikaten – Tec-Bite
Post Quantum Cryptography 2025 – Tec-Bite
SPF/DKIM/DMARC oder warum Google meine Mails nicht mag – Tec-Bite