PKI-Ausschreibung: Vorlage und Anforderungskatalog 2026 für private CA und Zertifikatslebenszyklus-Management

Diese PKI-Ausschreibungsvorlage ist ein herstellerneutraler Anforderungskatalog für den Kauf einer privaten Zertifizierungsstelle (CA) und einer Plattform für Zertifikatslebenszyklus-Management (CLM). Sie folgt den sieben Gruppen, die eine PKI-Antwort in der Regel abdecken muss: CA und Ausstellung, Enrollment, Sichtbarkeit und Automatisierung, Schlüsselschutz, Anwendungsfälle, Governance sowie Betrieb und Anbieter. Jede Anforderung hat eine Priorität und die zu verlangenden Nachweise, und jede Tabelle lässt sich in eine Tabellenkalkulation kopieren.

Die Anforderungen sind Fähigkeiten, die eine ernstzunehmende Produktkategorie erfüllen und belegen kann. Punkte, die nur manche Architekturen bieten, sind als Erweitert gekennzeichnet, damit Sie entscheiden, ob sie in Ihrer Bewertung Gewicht verdienen. Wenn Sie noch zwischen Produkten wählen, lesen Sie zuerst die Kaufberatung zur besten PKI-Lösung.

---

Inhaltsverzeichnis

1. Für wen die Vorlage gedacht ist und wie Sie sie nutzen
2. Bevor Sie die Ausschreibung schreiben
3. Der PKI-Anforderungskatalog
4. Gewichtetes Bewertungsmodell
5. Fragen an die Anbieter
6. Warnsignale in Anbieterantworten
7. Proof-of-Concept-Plan
8. Vertrags- und Ausstiegsklauseln
9. Einleitungstext zum Kopieren
10. FAQ
11. Quellen

---

Für wen die Vorlage gedacht ist und wie Sie sie nutzen

Dieser Leitfaden richtet sich an Security-Architekten, PKI-Verantwortliche, Infrastruktur- und Einkaufsteams, die eine bestehende PKI (oft Microsoft AD CS) ersetzen oder erweitern, ein Zertifikatslebenszyklus-Management ergänzen oder sich auf kürzere Zertifikatslaufzeiten vorbereiten.

So gehen Sie vor:

1. Beantworten Sie die Scoping-Fragen unten und streichen Sie jede Anforderung, die für Sie nicht gilt.
2. Kopieren Sie die Tabellen in eine Tabellenkalkulation mit denselben vier Spalten: ID, Anforderung, Priorität, Nachweis.
3. Machen Sie aus Pflichtanforderungen K.-o.-Kriterien und aus Soll-Anforderungen bewertete Kriterien.
4. Ergänzen Sie Ihre eigenen regulatorischen und internen Vorgaben; diese Vorlage kennt sie nicht.
5. Senden Sie allen Anbietern dieselbe Datei und verlangen Sie je ID eine schriftliche Antwort mit Dokumentationslinks.

Legende der Prioritäten:

• Pflicht: K.-o.-Kriterium. Der Anbieter scheidet bei Nichterfüllung aus, es sei denn, Sie akzeptieren eine dokumentierte Übergangslösung.
• Soll: bewertet. Die meisten ausgereiften Produkte erfüllen diese Punkte.
• Erweitert: bewertet, optional. Unterscheidende Fähigkeiten, die nur manche Architekturen bieten. Nur aufnehmen, wenn Ihr Risikomodell es verlangt.

---

Bevor Sie die Ausschreibung schreiben

Scoping-Fragen

• Welche Zertifikatsgruppen sind betroffen: Server und Load Balancer, Kubernetes-Workloads, Windows-Clients und Benutzer, Mobilgeräte, Netzwerkkomponenten, IoT- oder OT-Geräte, S/MIME-Postfächer, Code Signing, SSH?
• Soll die Plattform Ihre bestehende CA ersetzen, ihr vorgeschaltet werden oder zusätzlich öffentliche CAs anbinden?
• Welche Enrollment-Protokolle sprechen Ihre Systeme bereits? Zählen Sie sie aus echten Konfigurationen, nicht aus dem Gedächtnis.
• Wie hoch sind Zertifikatsbestand, jährliches Ausstellungsvolumen und erwartetes Wachstum?
• Welche öffentlichen TLS-Zertifikate müssen dem Zeitplan des CA/Browser Forums folgen: maximal 200 Tage Gültigkeit ab dem 15. März 2026, 100 Tage ab dem 15. März 2027, 47 Tage ab dem 15. März 2029? (Der Zeitplan gilt für öffentlich vertrauenswürdiges TLS, nicht für eine private CA; viele Teams führen aber auch privat kurze Laufzeiten ein.)

Zuerst das Inventar

Bevor die Ausschreibung hinausgeht, führen Sie eine Erkennungsrunde durch: Netzwerk scannen, AD CS abfragen, Zertifikate bei Cloud-Anbietern auflisten und Kubernetes-Secrets lesen. Fast immer finden Sie Zertifikate ohne Verantwortlichen. Ohne diese Zahl kann kein Anbieter ein Angebot dimensionieren, und sie wird zur Ausgangsbasis Ihres PoC.

Stakeholder

Benennen Sie je Bereich einen Verantwortlichen: PKI/Security (CA-Richtlinie), Infrastruktur und Plattformteams (Verteilziele), Identity (AD, MDM), Anwendungsverantwortliche, Risiko und Revision (Nachweise), Recht und Einkauf (Vertrag, Ausstieg) und gegebenenfalls das OT- oder Produktsicherheitsteam, das Geräte provisioniert.

Entscheidungskriterien

Legen Sie die Gewichte fest, bevor Sie eine Antwort lesen (siehe Bewertungsmodell unten). Entscheiden Sie vorab, ob Rechtsraum, Zertifizierungen und Schlüsselhoheit K.-o.-Kriterien oder Bewertungspunkte sind.

---

Der PKI-Anforderungskatalog

Gruppe 1: CA und Ausstellung

Gruppe 2: Enrollment

Gruppe 3: Sichtbarkeit und Automatisierung

Gruppe 4: Schlüsselschutz

Gruppe 5: Anwendungsfälle

Gruppe 6: Governance

Gruppe 7: Betrieb und Anbieter

---

Gewichtetes Bewertungsmodell

Bewerten Sie jedes Soll- und Erweitert-Kriterium von 0 bis 5, multiplizieren Sie mit dem Gewicht und summieren Sie. Wenden Sie zuerst die Pflichtpunkte als Bestanden/Nicht-bestanden-Schwelle an.

Skala 0 bis 5.

Beispielgewichte. Dies sind generische Zahlen zur Veranschaulichung; legen Sie Ihre eigenen fest.

Rechenbeispiel (erfundene Zahlen). Anbieter A erreicht Durchschnitte von 4, 3, 4, 3, 3, 4, 4 über die sieben Gruppen in obiger Reihenfolge: 0,15x4 + 0,15x3 + 0,20x4 + 0,15x3 + 0,10x3 + 0,15x4 + 0,10x4 = 0,60 + 0,45 + 0,80 + 0,45 + 0,30 + 0,60 + 0,40 = 3,60 von 5. Anbieter B erreicht 3, 4, 3, 4, 4, 3, 4: 0,45 + 0,60 + 0,60 + 0,60 + 0,40 + 0,45 + 0,40 = 3,50. Ein so knapper Abstand heisst: Lassen Sie den Proof of Concept entscheiden.

Hinweis: Wenn Sie Erweitert-Punkte wie MPC-gehaltene CA-Schlüssel oder M-von-N-Quorum aufnehmen, geben Sie ihnen ein Gewicht, das Ihr Risikomodell widerspiegelt. Ein hohes Gewicht ohne entsprechendes Risiko verzerrt das Ergebnis; ein Gewicht von null bei einer hochwertigen Root ist ebenso falsch.

---

Fragen an die Anbieter

Verlangen Sie schriftliche Antworten mit Dokumentationslinks, je Anforderungs-ID.

CA und Ausstellung

1. Welche CA-Hierarchiemodelle unterstützen Sie (Offline-Root, Online-Zwischen-CAs, importierte CAs), und wie wird eine CA ausser Betrieb genommen?
2. Wie veröffentlichen und skalieren Sie CRL und OCSP, und welche Verfügbarkeit dokumentieren Sie für die Sperrendpunkte?
3. Welche externen CAs können Sie heute anbinden, und welche sind nur auf der Roadmap?

Enrollment und Automatisierung

4. Welche der Protokolle ACME, EST, SCEP, CMP und Microsoft-Autoenrollment bedienen Sie nativ, und welche dokumentierten Einschränkungen gibt es je Protokoll?
5. Unterstützen Sie ACME Renewal Information, und nutzt Ihr eigener ACME-Client gegenüber öffentlichen CAs sie?
6. Welche maximale Ausstellungsrate haben Sie gemessen, auf welcher Hardware, mit welcher Challenge-Validierung, und ist der Test reproduzierbar?
7. Wie verhält sich die Erneuerung, wenn die Zertifikatslaufzeit kürzer ist als Ihr Standard-Erneuerungsfenster?
8. Welche Verteilziele unterstützen Sie, und was passiert, wenn eine Verteilung mittendrin scheitert?

Schlüsselschutz

9. Wo werden CA-Schlüssel erzeugt und wo liegen sie? Existiert jemals eine Kopie in Software?
10. Welche HSMs und Cloud-KMS-Dienste werden unterstützt, und für welche Schlüsselalgorithmen?
11. Wie werden Post-Quanten-CA-Schlüssel geschützt, und unterscheidet sich das von klassischen Schlüsseln?
12. Falls Sie Threshold- oder MPC-Schlüsselhoheit anbieten: Welche Algorithmen deckt sie ab, welche nicht, und wie ist ihr Produktionsstatus?

Governance

13. Welche Operationen können eine Freigabe durch mehrere Personen verlangen, und lässt sich ein M-von-N-Quorum festlegen?
14. Wie kann ein Prüfer verifizieren, dass das Audit-Log weder verändert noch gekürzt wurde?
15. Welche Felder enthalten Audit-Ereignisse, und wie gelangen sie in unser SIEM?

Betrieb und Anbieter

16. Welche RTO und RPO gelten für jede Betriebsoption, und wann haben Sie zuletzt eine Wiederherstellung getestet?
17. Wer beim Anbieter kann auf unseren Mandanten, unsere CA-Daten und unsere Schlüssel zugreifen, unter welcher Autorisierung, und wo sitzen diese Personen?
18. Welche Zertifizierungen und Prüfberichte können Sie vorlegen, mit Umfang und Datum?
19. Was geschieht bei Kündigung mit unseren Daten und unserer Konfiguration, und in welchem Format und welcher Frist geben Sie sie zurück?
20. Welche Komponenten Ihrer Plattform sind Open Source, von Dritten oder unterbeauftragt, und wie lautet Ihre End-of-Life-Richtlinie?

---

Warnsignale in Anbieterantworten

• "Unterstützt alle Protokolle" ohne Dokumentationslink je Protokoll und ohne Hinweis auf Einschränkungen.
• 47-Tage-Bereitschaft als Trend oder Marketingaussage, ohne getestetes Volumen oder reproduzierbare Bedingungen.
• Rollback "verfügbar", aber bei einer fehlgeschlagenen Verteilung nicht vorführbar.
• CA-Schlüssel "im HSM", ohne Aussage dazu, ob je eine Software-Kopie existiert.
• Ein Audit-Log wird als "unveränderlich" beschrieben, ohne dass Sie die Integrität prüfen können.
• Post-Quanten-"Unterstützung", die nur auf der Roadmap steht oder nur in der Testumgebung gilt.
• Preise, die sich für Ihr Zertifikatsvolumen nicht abschätzen lassen oder kurze Laufzeiten mit steigender Automatisierung bestrafen.
• Keine klare Antwort darauf, wer an Ihre CA-Schlüssel kommt, oder nur ein allgemeiner Datenschutzhinweis.
• Referenzkunden, die nicht erreichbar sind oder eine andere Produktlinie nutzen.
• Ein "Ja" in der Antwort ohne passende Stelle in der öffentlichen Dokumentation.

---

Proof-of-Concept-Plan

Führen Sie einen zeitlich begrenzten PoC (zwei bis vier Wochen) mit Bestanden/Nicht-bestanden-Tests auf Ihren eigenen Systemen durch. Dokumentieren Sie Bedingungen und Ergebnisse.

Wenn Sie Erweitert-Punkte aufgenommen haben, ergänzen Sie: eine CA mit Threshold-gehaltenem Schlüssel erstellen und darüber signieren; eine Quorum-Freigabe mit M-von-N-Freigebenden durchführen; eine IP- oder zeitbasierte Richtlinie anwenden und prüfen, dass sie richtlinienwidrige Anfragen ablehnt.

---

Vertrags- und Ausstiegsklauseln

• Schlüsselhoheit. Der Vertrag legt fest, wer CA-Schlüssel nutzen oder darauf zugreifen darf, unter welcher Autorisierung, und dass der Anbieter ohne Ihre Zustimmung nicht damit signieren kann.
• Datenexport. Auf Anforderung und bei Vertragsende gibt der Anbieter CA-Konfiguration, Zertifikate, Inventar und Audit-Logs in dokumentierten offenen Formaten innerhalb einer festgelegten Frist zurück.
• Schlüsselübergang. Schriftliche Unterstützung bei der Migration von CA-Schlüsseln oder der Neuausstellung aus einer neuen CA, mit durchgehendem Sperrdienst, bis das letzte ausgestellte Zertifikat abgelaufen ist.
• Servicelevel. Verfügbarkeit für Ausstellung und Sperrendpunkte, Reaktionszeiten des Supports je Schweregrad und Gutschriften bei Verletzung.
• Sicherheit und Audit. Prüfrecht oder jährliche Übergabe von Prüfberichten (ISO 27001, SOC 2 oder gleichwertig), Meldefristen bei Vorfällen und Verantwortlichkeiten bei Verstössen.
• Unterauftragnehmer und Rechtsraum. Offenlegung und Benachrichtigung bei Änderungen von Unterauftragnehmern, Datenstandort und anwendbarem Recht.
• Laufzeitänderungen. Zusage, Änderungen bei den Laufzeiten öffentlicher Zertifikate und Algorithmenmigrationen ohne zusätzliche Lizenzkosten für das Erneuerungsvolumen zu unterstützen.
• Kündigung. Keine Gebühr für den Export; angemessene Unterstützung beim Übergang.

---

Einleitungstext zum Kopieren

[Organisation] sucht eine Plattform für private PKI und Zertifikatslebenszyklus-Management für [Anzahl] Zertifikate auf [Servern, Workloads, Endgeräten, Geräten, Signaturen]. Die Lösung muss private Zertifizierungsstellen betreiben, deren Schlüssel in Hardware oder einem verwalteten Schlüsseldienst geschützt sind, die in Gruppe 2 genannten Enrollment-Protokolle bedienen, Zertifikate aus allen Quellen erkennen und inventarisieren, Erneuerung und Verteilung bei Gültigkeiten von 47 Tagen oder weniger automatisieren, eine rollenbasierte Governance mit überprüfbarem Prüfpfad bieten und als [SaaS / On-Premises / hybrid] unter [Rechtsraum] betreibbar sein. Anbieter beantworten jede nummerierte Anforderung schriftlich unter Angabe ihrer Dokumentation, nennen jede Einschränkung und nehmen an einem Proof of Concept mit den Systemen von [Organisation] teil. Die Antworten werden anhand der gewichteten Kriterien in Anhang [X] bewertet; als Pflicht gekennzeichnete Anforderungen sind zwingend.

---

FAQ

Was gehört in eine PKI-Ausschreibung? Sie enthält Umfang und Mengen sowie Anforderungen, gegliedert nach CA und Ausstellung, Enrollment-Protokollen, Sichtbarkeit und Automatisierung, Schlüsselschutz, Anwendungsfällen, Governance sowie Betrieb und Anbieterbedingungen. Ergänzen Sie ein Bewertungsmodell, einen PoC-Plan und Ausstiegsklauseln. Diese Vorlage liefert jeden dieser Bausteine.

Wie formuliere ich herstellerneutrale PKI-Anforderungen? Formulieren Sie jede Anforderung als prüfbare Fähigkeit (z. B. "ACME nach RFC 8555 mit dns-01") statt als Produktfunktionsnamen und verlangen Sie Nachweise. Ordnen Sie unterscheidende Fähigkeiten als Erweitert ein, damit sie bewertet und nicht vorausgesetzt werden.

Welche Punkte sollten in einer PKI-Ausschreibung Pflicht sein? Typischerweise nicht exportierbare, HSM- oder KMS-geschützte CA-Schlüssel, Sperrung, die bereits genutzten Enrollment-Protokolle, Erkennung und automatische Erneuerung, RBAC, ein exportierbares Audit-Log mit SIEM-Weiterleitung, HA/DR und eine Datenexport-Klausel. Alles Weitere hängt von Bestand und Risiko ab.

Wie teste ich die Bereitschaft für 47-Tage-Zertifikate? Führen Sie in der Staging-Umgebung einen Test mit 47 Tagen Gültigkeit und mindestens einigen hundert Zertifikaten durch, messen Sie Erneuerungserfolg, Alarmvolumen und Ausstellungsrate und prüfen Sie, dass keine Erneuerungsschleifen entstehen. Der Zeitplan des CA/Browser Forums gilt für öffentliches TLS, aber dieselbe Automatisierungsanforderung gilt für jedes kurzlebige Zertifikat.

Sollte ich Post-Quanten-Zertifikate in einer PKI-Ausschreibung verlangen? Nehmen Sie sie für private CAs als Soll auf, mit ML-DSA (FIPS 204) und SLH-DSA (FIPS 205), idealerweise hybrid oder Composite, und fragen Sie, wie Post-Quanten-CA-Schlüssel geschützt werden. Öffentliches TLS akzeptiert sie noch nicht, verlangen Sie sie dort also nicht.

Sollte MPC- oder Threshold-Schlüsselhoheit für CA-Schlüssel Pflicht sein? Nur wenn Ihr Bedrohungsmodell verlangt, dass kein einzelnes HSM, kein einzelner Administrator und kein einzelner Host einen CA-Schlüssel nutzen kann. Es ist eine unterscheidende Fähigkeit, die nur manche Anbieter bieten; bewerten Sie sie als Erweitert, statt Anbieter allein deshalb auszuschliessen.

Wie lange sollte die Antwortfrist einer Ausschreibung sein? Planen Sie drei bis vier Wochen für schriftliche Antworten und zwei bis vier Wochen PoC mit den ausgewählten Anbietern. Kürzere PoCs decken selten Erkennung, Erneuerung bei realem Volumen und Fehlertests ab.

Kann ich diese Tabellen in eine Tabellenkalkulation übernehmen? Ja. Kopieren Sie jede Tabelle in Ihr Tabellenkalkulationsprogramm, behalten Sie die ID-Spalte und ergänzen Sie Spalten für Antwort, Bewertung und Nachweislink jedes Anbieters.

---

Fazit

Eine gute PKI-Ausschreibung besteht aus prüfbaren Anforderungen, einem klaren Bewertungsmodell und einem kurzen Proof of Concept, der die Aussagen des Anbieters zu widerlegen versucht. Nutzen Sie die Pflichtpunkte zum Filtern, die Soll-Punkte zum Differenzieren und die Erweitert-Punkte nur dort, wo Ihr Risikomodell sie rechtfertigt. Prüfen Sie dann jede Antwort in Ihrer eigenen Umgebung.

DuoKey veröffentlicht seine PKI-Fähigkeiten nach denselben Kriterien auf den Vergleichsseiten und in der Kaufberatung. Um den PoC-Plan oben mit DuoKey durchzuführen, starten Sie einen Test oder lesen Sie die Produktseite Zertifikatsverwaltung.

---

Quellen

• CA/Browser Forum: Baseline Requirements für öffentlich vertrauenswürdige TLS-Serverzertifikate (Ballot SC-081)
• NIST FIPS 204: ML-DSA
• NIST FIPS 205: SLH-DSA
• RFC 8555: ACME
• RFC 7030: EST
• RFC 8894: SCEP
• RFC 4210: CMP und RFC 9483: Lightweight-CMP-Profil
• RFC 6960: OCSP
• RFC 3161: Time-Stamp Protocol
• RFC 9881: ML-DSA in X.509
• Microsoft Learn: Überblick über Active Directory Certificate Services
• DuoKey Docs: PKI und SSL im Überblick
• DuoKey Docs: Enrollment-Protokolle