Mit der zunehmenden Größe und Komplexität von Angriffen auf die Internetinfrastruktur erfüllen klassische Modelle der Domainvalidierung nicht mehr die Anforderungen moderner öffentlicher PKI. Als Reaktion auf reale Bedrohungen wie selektives DNS Spoofing und regionales BGP Hijacking haben globale Zertifizierungsstellen, darunter DigiCert und Sectigo, im Jahr 2025 den verpflichtenden Mechanismus Multi-Perspective Issuance Corroboration (MPIC) eingeführt.
MPIC ist keine kosmetische prozedurale Änderung. Es handelt sich um eine Neugestaltung eines der zentralen Vertrauenselemente im Internet, nämlich der Methode zur Bestätigung, dass der Antragsteller eines Zertifikats die jeweilige Domain tatsächlich global kontrolliert und nicht nur lokal.
Inhaltsverzeichnis
Warum das traditionelle DCV-Modell nicht mehr ausreicht?
Bis vor kurzem basierte die Domain Control Validation auf der Annahme, dass:
- die von der Zertifizierungsstelle gesehene DNS- oder HTTP-Antwort dem tatsächlichen Zustand der Domain entspricht,
- das Netzwerk, aus dem die Validierung erfolgt, das globale Internet widerspiegelt,
- eventuelle Propagationsunterschiede kurzlebig und unbedeutend sind.
Die Praxis der letzten Jahre hat jedoch gezeigt, dass diese Annahmen falsch sind. Infrastrukturangriffe beruhen zunehmend nicht auf einer globalen Übernahme einer Domain, sondern auf einer zeitlich und regional begrenzten Manipulation von Routing oder DNS-Antworten. In einem solchen Szenario:
- sieht die Zertifizierungsstelle einen korrekten Eintrag,
- sieht der Domaininhaber einen korrekten Eintrag,
- jedoch nur aus einer vom Angreifer kontrollierten Perspektive.
Dies reichte aus, um ein unberechtigtes Zertifikat auszustellen. MPIC wurde genau entwickelt, um diesen Angriffsvektor dauerhaft zu schließen.
Was ist Multi-Perspective Issuance Corroboration in der Praxis?
MPIC ist ein Mechanismus, bei dem die Zertifizierungsstelle:
- die Domainvalidierung parallel aus mehreren unabhängigen Netzwerkperspektiven durchführt,
- autonome Systeme und unterschiedliche Netzbetreiber nutzt,
- DNS-, CAA- sowie HTTP/HTTPS-Antworten aus verschiedenen Regionen der Welt vergleicht.
Das entscheidende Wort ist hier unabhängig. MPIC-Perspektiven sind nicht nur geografisch verteilt. Sie müssen logisch voneinander getrennt sein, damit ein einzelner Routing-Vorfall, ein Betreiberfehler oder eine lokale Manipulation nicht den gesamten Prozess beeinflussen kann. Wenn auch nur eine Perspektive:
- keine Antwort erhält,
- eine abweichende Antwort erhält,
- durch eine Firewall oder WAF blockiert wird,
gilt die Validierung als inkonsistent und der Prozess der Zertifikatsausstellung wird abgebrochen.
MPIC als neuer Sicherheitsstandard der Vertrauenskette.
Aus Sicht des PKI-Ökosystems übernimmt MPIC eine ähnliche Rolle wie Certificate Transparency. Es ist kein Mechanismus, der für Endnutzer sichtbar ist, erhöht jedoch die Sicherheit des gesamten Systems erheblich.
Die Einführung von MPIC:
- reduziert das Risiko der Zertifikatsausstellung auf Basis eines manipulierten DNS-Blicks,
- begrenzt die Wirksamkeit kurzfristiger BGP-Angriffe,
- erzwingt eine höhere Konfigurationsdisziplin seitens der Domaininhaber.
Für die Branche ist dies ein klares Signal, dass die öffentliche PKI einzelnen Beobachtungspunkten nicht länger vertraut.
„Status Pre-signed Failed“ was bedeutet dieser Fehler wirklich?
Im Zusammenhang mit MPIC erscheint häufig die Meldung Status Pre-signed Failed. Dabei handelt es sich nicht um einen technischen Fehler der Zertifizierungsstelle oder einen Systemausfall. Sie bedeutet, dass:
- die Domainvalidierung den Mehrperspektiven-Konsistenztest nicht bestanden hat,
- mindestens eine MPIC-Perspektive die Kontrolle über die Domain nicht bestätigt hat,
- die Infrastruktur des Kunden global nicht vollständig erreichbar ist.
In der Praxis bedeutet dies, dass die Domain lokal korrekt funktioniert, jedoch nicht die Anforderungen an die globale Beobachtbarkeit erfüllt, die MPIC als notwendige Vertrauensbedingung betrachtet.
Häufigste Ursachen für MPIC-Probleme in Produktionsumgebungen.
Inkonsistente CAA-Einträge.
Der CAA-Eintrag muss identisch und global sichtbar sein. MPIC erkennt sehr schnell Situationen, in denen:
- verschiedene DNS-Server unterschiedliche Werte zurückgeben,
- die DNS-Zone nur teilweise aktualisiert wurde,
- Änderungen zu kurz vor der Validierung vorgenommen wurden.
Im MPIC-Zeitalter ist eine temporäre Inkonsistenz nicht mehr akzeptabel.
Netzwerkbeschränkungen und Sicherheitsfilter.
Firewalls, WAFs oder CDNs, die:
- Datenverkehr aus bestimmten Regionen blockieren,
- Anfragen anhand des User-Agent filtern,
- aggressive Rate-Limiting-Mechanismen einsetzen,
können die MPIC-Validierung effektiv verhindern, obwohl die Domain für Nutzer korrekt funktioniert.
Zu aggressive TTL-Werte und Automatisierung.
Moderne DevOps-Pipelines:
- reduzieren TTL-Werte auf ein Minimum,
- entfernen Validierungsdateien automatisch,
- nehmen DNS-Änderungen unmittelbar nach der ersten erfolgreichen Prüfung vor.
Im MPIC-Modell führt dieses Vorgehen zu zufälligen und schwer zu diagnostizierenden Fehlern.
Wie bereitet man die Infrastruktur auf MPIC vor? Operativer Ansatz.
MPIC erzwingt eine Änderung der Sichtweise auf die Zertifikatsvalidierung. Sie ist keine einmalige Operation mehr, sondern ein Test der globalen Konsistenz der Infrastruktur. Empfohlene Maßnahmen umfassen:
- DNS-Audits aus mehreren Standorten,
- Überprüfung von Sicherheitsregeln im Hinblick auf Validierungsverkehr,
- Stabilisierung von TTL-Werten und Validierungsprozessen,
- Sensibilisierung technischer Teams dafür, dass DCV ein mehrstufiger Prozess ist.
FAQ Multi-Perspective Issuance Corroboration.
1. Ist MPIC verpflichtend?
Ja. Für öffentlich vertrauenswürdige SSL/TLS-Zertifikate ist MPIC heute Standard und keine Option.
2. Gilt MPIC für alle Zertifikatstypen?
Es gilt für DV-, OV- und EV-Zertifikate. Jedes erfordert DCV, und DCV unterliegt MPIC.
3. Beeinflusst MPIC die Ausstellungsdauer eines Zertifikats?
Ja, sie kann sich verlängern, wenn die Domaininfrastruktur global nicht konsistent ist.
4. Reichen lokale DNS-Tests aus?
Nein. MPIC erfordert die Konsistenz von Antworten aus mehreren Netzwerken gleichzeitig.
5. Kann ein CDN MPIC-Probleme verursachen?
Ja, insbesondere bei Geoblocking, WAF-Regeln oder nicht standardisierten Traffic-Filtern.
6. Ist ein CAA-Eintrag immer erforderlich?
Er ist nicht verpflichtend, muss aber korrekt und global konsistent sein, sofern er existiert.
7. Ist ein kurzer TTL-Wert ein Fehler?
Nein, jedoch erhöhen sehr kurze TTL-Werte das Risiko von Inkonsistenzen während der MPIC-Validierung.
8. Erkennt MPIC BGP-Angriffe?
Nicht direkt, verhindert jedoch effektiv deren Nutzung zur Zertifikatsausstellung.
9. Gilt MPIC nur für DNS?
Nein. Je nach DCV-Methode umfasst es auch HTTP und HTTPS.
10. Kann MPIC deaktiviert werden?
Nein. Es ist Teil der Sicherheitsrichtlinien der Zertifizierungsstellen.
11. Unterliegen Testumgebungen ebenfalls MPIC?
Ja, sofern ein öffentlich vertrauenswürdiges Zertifikat beantragt wird.
12. Ist IP-Allowlisting für Zertifizierungsstellen erforderlich?
In stark gefilterten Umgebungen ist dies häufig notwendig.
13. Beeinflusst MPIC automatische Zertifikatserneuerungen?
Ja. Auch Erneuerungen durchlaufen eine vollständige DCV-Validierung.
14. Erhöht MPIC die Sicherheit für Endnutzer?
Ja. Es reduziert das Risiko der Ausstellung gefälschter Zertifikate.
15. Ist MPIC eine temporäre Änderung?
Nein. Es ist ein dauerhaftes Element der Architektur der öffentlichen PKI.
Multi-Perspective Issuance Corroboration ist einer der wichtigsten Schritte in der Weiterentwicklung des Vertrauens im Internet in den letzten Jahren. MPIC macht deutlich, dass Zertifikatssicherheit nicht bei der Kryptografie endet. Die globale Konsistenz der DNS- und Netzwerkinfrastruktur ist ebenso entscheidend.
Für Domaininhaber und Administratoren ist dies der Moment, SSL-Zertifikate nicht als Produkt, sondern als Sicherheitsprozess zu betrachten, der ein bewusstes Management erfordert. Bei HEXSSL betrachten wir MPIC als einen natürlichen und notwendigen Schritt in der Reifung der öffentlichen PKI.