Kurze Information, die mich bereits die Tage von einem Leser erreichte. Es hieß in einer Mail nur ganz kurz "HARICA zieht Zertifikate zurück". Die etwas längere Fassung lautet, dass die Zertifizierungsstelle HARICA am 25.07.2026 um 12:00 Uhr Serverzertifikate gesperrt hat. Grund ist, dass die Zertifikate wohl formale und technische Fehler in den Richtliniendokumenten (CPS) und den Zertifikatsprofilen aufweisen.
Das Kürzel HARICA steht für "Hellenic Academic and Research Institutions Certification Authority", also eine griechische Zertifikate-Autorisierungsstelle. HARICA stellt digitale Zertifikate für sichere Websites, E-Mail-Schutz, Code-Signing sowie rechtsverbindliche elektronische Signaturen und Siegel aus und ist weltweit anerkannt. Die Zertifikate für einen Server beginnen bei 36 Euro/Jahr und scheinen im Universitätsumfeld häufiger eingesetzt zu werden.
Die TU-Berlin informierte zum 17.7.2026 im Beitrag Kurzfristige Sperrung von HARICA-Serverzertifikaten über den Sachverhalt. Der Zertifizierungsanbieter HARICA hat bereits am 20.07.2026 Serverzertifikate gesperrt, die im Zeitraum vom 15.06.2026 bis 15.07.2026 ausgestellt wurden. Der Drops ist inzwischen längst gelutscht.
Aber es gab weitere Zertifikate mit Problemen. In dieser Mitteilung informiert das IT-Service-Zentrum der Martin-Luther Universität Halle-Wittenberg über die nächste Sperre. Es heißt "Nachdem wir bereits in der vergangenen Woche über die kurzfristige Sperrung von HARICA-Serverzertifikaten informiert haben, hat HARICA diese Woche erneut Zertifikate zurückgezogen. Aus diesem Grund werden am 25.07.2026 um 12:00 Uhr weitere betroffene Serverzertifikate gesperrt." Ähnliche hört man von der TU-Dresden.
Hintergrund ist in allen Fällen ein formaler Fehler in der von HARICA veröffentlichten Certification Practice Statement (CPS). Die betroffenen Zertifikate funktionieren technisch einwandfrei. Da die Spezifikation inzwischen korrigiert wurde, ist HARICA gemäß den geltenden Richtlinien verpflichtet, alle in diesem Zeitraum ausgestellten Serverzertifikate zu widerrufen und durch neue Zertifikate zu ersetzen, heißt es.
Ich finde es immer lustig, dass alle Welt alles mit Zertifikaten absichern will, die Dinger aber irgendwann sowieso ablaufen, und die Aussteller irgendwie ihre Technik nicht gebacken kriegen. Zudem wollen die Zertifikatsaussteller die Laufzeit der Zertifikate reduzieren. Dann muss noch häufiger erneuert werden, und wenn es dann Fehler bei der Ausstellung gibt, dürfen die IT-Leute ebenfalls ran. Vor allem ist es dann "hübsch", wenn nur einige Tage bis zum Widerruf bleiben. Vor einigen Monaten hatte es Nutzer von D-Trust-Zertifikaten erwischt (siehe folgende Links).
Ähnliche Artikel:
D-Trust verlangt bis 6.4.2026 (Ostermontag) Zertifikatsausstausch
D-Trust zieht am 8. Mai 2026 S/MIME-Zertifikate zurück
Frust mit D-Trust-Zertifikat – eine Nutzererfahrung mit AATL
Abgelaufenes Zertifikat verursacht Sicherheitswarnungen auf Microsoft Testseite
Nextcloud-Instanz bei Hetzner wirft Zertifikatsfehler (3.6.2026)
AIDA-Zeiterfassung kaputt; Web-Interface "EWAS" wegen Zertifikatsablauf gestört
Exchange Online, der Microsoft Support und das CA-1-TLS-Zertifikatskettendrama
Secure Boot-Zertifikate laufen am 24. Juni 2026 ab: Nutzererfahrungen mit HP …
MVP: 2013 – 2016
Neben TLS ist manchmal auch S/MIME betroffen.
Dazu muss man wissen, das Harica die CA für den gesamten GÉANT ist, also der europäische Forschungsverbund. Da hängt dann auch das DFN und entsprechend alle deutschen Forschungsenrichtungen und Universitäten dran.
Der erste Widerrruf von Do zu Mo war schon nervig, aber noch machbar.
Vom zweiten Widerruf (Di zu Sa) waren nun aber alle konsolidierten Zertifikate erneut betroffen, was die Infrastruktur von Harica anscheinend nicht mitgemacht hat, weder direkt noch per acme waren bis Donnerstagnachmittag die betroffenen Zertifikate zu erneuern. Weniger erfreuliche Woche…
War weniger lustig.
Genau das CA-(Wurzel)Zertifikat (RSA) ist aber noch (bis 2045) gültig. Die TLS-Certs für Eduroam sind nichtmal mehr als 199 Tage gültig und nur gegen das CA-Cert signiert.
Wo ist jetzt das Problem, das der Uni-Admin einen Einzeiler für eine neue Issuance startet? Gar nicht, wir haben das schon getan. Harica/DFN/Géant jetzt in den Raum werfen wenn das Wurzelcert absolut unbedruckt gültig ist sollte wohl den Sturm im Wasserglas bewirken.
Ersetze "der Uni-Admin" durch bis zu hunderte nicht hauptberufliche Admins für Projekte, Studien etc. Dann darf sich "der Uni-Admin" mit deren unterschiedlichsten Implementationen auseinandersetzen, deren renewal Scripte dann in timeouts laufen oder leere Zertifikate zurückschicken.
Der Uni-Admin hat so doch jede Menge zu tun.
Eine kleine Einordnung wäre noch schön gewesen:
1. Es hat schon viele PKI-Betreiber getroffen, HARICA fällt hier in den uneteren Bereich der PKIs, welche Probleme im Betrieb haben
2. Die Kommunikation von HARICA und (in Deutschland) vom DFN waren hervorragend. Es war zu jeder Zeit klar, was zu tun ist, so dass Ausfälle von wichtigen Diensten unwahrscheinlich waren.
3. Nicht HARICA setzt die kurzen Fristen, sondern das CA/Browser Forum. Jede PKI MUSS diese Fristen einhalten, um nicht aus den Root-Programmen zu fliegen.
Zudem finde ich den letzten Absatz leider eher unreflektiert.
> Ich finde es immer lustig, dass alle Welt alles mit Zertifikaten absichern will
Keiner "will" das, es ist schlicht zwingend, um die Kommunikation abzusichern.
> die Dinger aber irgendwann sowieso ablaufen
In der Regel ist das aber sehr gut planbar bzw. automatisierbar
> die Aussteller irgendwie ihre Technik nicht gebacken kriegen
Jein, es war kein technisches Problem, sondern ein Nichteinhalten von Comlianceregeln. Aber ja, hier ist ein Punkt einigermaßen korrekt angesprochen
> Zudem wollen die Zertifikatsaussteller die Laufzeit der Zertifikate reduzieren
Nein, das will ca CA/Browser Forum, sprich die OS- und Browseranbieter. Die PKIs müssen sich dem beugen, um compliant zu bleiben
> Dann muss noch häufiger erneuert werden, und wenn es dann Fehler bei der Ausstellung gibt, dürfen die IT-Leute ebenfalls ran
Hier ist das Stichwort: Automatisierung! Mit certbot u.ä. stellen auch kurze Laufzeiten kein Problem dar. Das Problem ist alte Gammelsoftware, die keine Automatisierung integriert bekommt
> Vor allem ist es dann "hübsch", wenn nur einige Tage bis zum Widerruf bleiben
Habe ich schon angesprochen. Mit der neuen ACME Erweiterung ARI (ACME Renewal Information) wird auch das sich zukünftig transparent automatisieren lassen. Leider ist die technik aber noch so neu, dass das heute noch nicht verbreitet ist.
Jein … der Erste Widerruf war kein Problem. Mit dem zweiten haben die Probleme begonnen. Die Endpunkte sind nicht erreichbar. Wenn ein Zertifikat ausgestellt wird, werden oft 0 byte große Zertifikate zum Download angeboten. Automatisiert funktioniert derzeit gar nichts. Das hat nix mit Gammelsoftware zu tun.
Du hast einen Punkt, das stimmt. HARICA hat die Last unterschätzt, die erzeugt wird, wenn alle gleichzeitig losrennen, um die Zertifikate neu zu generieren. Aber auch hier muss man sagen, dass die Probleme relativ fix behoben wurden und mehr Ressourcen bereitgestellt wurden.
Aber das ist m.E.n. kein Argument gegen Automatisierung. Hiermit meinte ich nur, dass es durch Automatisierung – wenn das Backend nicht zusammebricht – bei solchen Aktionen keine zusätzliche Arbeit erzeugt. Die "Gammelsoftware" ist die, wo im Zweifel am Samstag ein Admin tätig werden muss, um das ganze händisch auszutauschen.
Aber ja, HARICA muss noch lernen, wie eine große CA dimensioniert zu sein hat, damit die technischen Probleme nicht erneut autraten können.
Das Problem ist alte Gammelsoftware, die keine Automatisierung integriert bekommt…
Ja ACME und Windows mögen sich nicht – es gibt noch immer keine anständige Lösung ACME auf Windows Servern zu implementieren (und das sage ich als überzeugter Windows Admin)
WinACME ist sehr gut, und komfortabel. Und das sage ich als überzeugter Linux-Admin 😉
>> 2. Die Kommunikation von HARICA und (in Deutschland) vom DFN waren hervorragend. Es war zu jeder Zeit klar, was zu tun ist, so dass Ausfälle von wichtigen Diensten unwahrscheinlich waren.
Kannst du das genauer ausführen?
Ich sehe keine hervorragende Kommunikation von HARICA dazu – Es ist wohl auch kein Zufall, das in dem Blog Eintrag kein Link zu einer Veröffentlichung von HARICA zu dem Thema führt.
Meiner Erfahrung nach ist HARICA was Kommunikation angeht (auch/insbesondere was Änderungen an ihren APIs angeht) leider eher Schlampig. Das musste ich schon zwei mal bitter erleben.
Wir haben es auch bei PKI mit einer Diktatur von Big Tech zu tun. Wenn ich recht erinnere, ist ein Miarbeiter von HARICA auch Mitglied des bestimmenden PKI-Gremiums.
Die PKI vom DFN war pures Gold gegen das, was wir mit Sectigo (GÉANT) und HARICA bekommen haben.
Und der ganze Schisslaweng mit den Zertifikaten und immer kürzeren Laufzeiten, die immensen Kosten und der Zeitaufwand nur, um ein versch… Zertifikat zu bekommen, dessen Wurzel in den Zertifikatsspeichern der Betriebssysteme und Anwendungen hinterlegt ist, damit den abgeleiteten Zertifikaten ohne Wanrmeldung vertraut wird. Gott, man hat das System völlig verhunzt. Und Big Tech ist frech genug, sich weiterhin (Sbu-)CA-Zertifkate mit 30 Jahren Laufzeit auszustellen… dazu noch der Rotz mit den EFI/BIOS-Zertifikaten…
Wir haben uns vor 20 Jahren eine eigene PKI fürs interne Netz mit eigenem Wurzelzertifikat aufgebaut, mit dem wir wenigstens intern alle Netzwerkdienste absichern. Das CA-Cert haben wir in alle OS integriert, so dass abgeleiteten Zertifkaten ohne Warnmeldung vertraut wird. Die haben mind. 10 Jahre Laufzeit.
Himmel, das ist eine riesige Gelddruckmaschine, und wir müssen das bezahlen!
Eine Gelddruck-Maschine ist das nicht wirklich.
Die gebuchten Zertifikatspakete sind ja nicht entsprechend teurer geworden.
Mir ist jetzt kein Zertifikatsaussteller bekannt, der ein echtes Limit hat, wie häufig man im gebuchten Zeitraum das Zertifikat erneuern darf.
Es gibt leider zwei Knackpunkte, die es allerdings teilweise massive ABM bedeuten auf Administrationsseite, zum Teil suboptimale APIs mit Subaccount-Möglichkeiten, zum anderen wie hier schon wiederholte angemerkt, mangelnde Unterstützung bei nicht wenig Software, für eine schlichte Automatisierung.
In der Regel ist mindestens einmal richtig Hirnschmalz notwendig, um selber eine gescheite Automatisierung einzurichten.
Och, wenn man bedenkt, dass man die ganze Zertifikats-Chose mit openssl und 'nem Einzeiler selbst zum Laufen bekommt und dazu noch wunderbar 100 Prozent sichere Zertifikate bekommt, ist das schon eine Lizenz zum Gelddrucken.
Die Zertifikatsausteller machen ja nichts anderes, als eine (oder mehrere) openssl.cnf entsprechend ihren in ihrem gottgleichen Gremium so wunderbar definierten Super-Duper-Kriterien zu konfigurieren und dann tonnenweise Zertifikate für jeden Mist fein säuberlich einzeln aufgefieselt zu generieren und sich das preisgestaffelt vergolden zu lassen.