AWS zieht E-Mail-Zertifikaten in Certificate Manager den Stecker

Das Ende eines bequemen Freigabewegs

AWS beendet die E-Mail-Validierung für öffentliche Zertifikate in Certificate Manager bis zum 30. September 2027 und verlangt von Kundinnen und Kunden bis dahin den Wechsel auf DNS-Validierung, wie das Unternehmen im Sicherheitsblog am 13. August 2026 mitteilt. Wer noch per E-Mail bestätigt, verliert diesen Weg nicht über Nacht, sondern über vier klar datierte Etappen, die bis ins Jahr 2028 reichen.

E-Mail-Validierung galt lange als bequemster Einstieg: Antragsteller bestätigten den Besitz einer Domain, indem sie eine Adresse wie admin@ oder webmaster@ anklickten. Genau dieser Mechanismus gilt als schwaches Glied, weil kompromittierte Postfächer, veraltete Weiterleitungen oder vergessene Catch-all-Adressen ausreichen, um ein Zertifikat im Namen einer fremden Domain zu erschleichen.

Das CA/B Forum, das Browserhersteller und Zertifizierungsstellen gemeinsam trägt, hat im November 2025 entschieden, diesen Validierungsweg branchenweit zum 15. März 2028 abzuschaffen. Ab diesem Datum vertrauen Browser keinem per E-Mail validierten Zertifikat mehr, unabhängig davon, welche Stelle es ausgestellt hat.

AWS setzt die eigene Frist bewusst ein Jahr vor diesen harten Forum-Stichtag. Wer die ACM-eigene Frist zum 30. September 2027 einhält, hat noch Puffer, bevor am 15. März 2028 die branchenweite Vertrauensgrenze fällt.

Für Unternehmen mit gewachsenen AWS-Umgebungen ist das mehr als eine Randnotiz. Wer über Jahre hinweg Zertifikate angehäuft hat, ohne die Validierungsmethode zu dokumentieren, steht jetzt vor der Aufgabe, den eigenen Bestand systematisch zu sichten, bevor eine der vier Fristen greift.

Autoren des Blogposts sind Adam Aboudi, technischer Produktmanager im ACM-Team, und Poojil Tripathi, Solutions Architect bei AWS. Beide betonen im Text, dass die Umstellung ohne neue Zertifikatsanforderung auskommt, was den Aufwand gegenüber einer kompletten Neubeantragung spürbar senkt.

Woher der Druck des CA/B Forums kommt

Das CA/B Forum setzt die technischen Mindeststandards, an die sich jede öffentlich vertrauenswürdige Zertifizierungsstelle halten muss. Browserhersteller sitzen über ihre Vertrauensspeicher faktisch mit am Tisch, denn ohne deren Zustimmung ist ein Zertifikat für den öffentlichen Einsatz wertlos.

Die Entscheidung vom November 2025 traf nicht nur AWS. Jede Zertifizierungsstelle, die öffentliche TLS-Zertifikate ausstellt, muss die E-Mail-Validierung bis zum 15. März 2028 abschalten, sonst drohen Zertifikate, die Browser stillschweigend ablehnen, sobald jemand die betroffene Seite aufruft.

Für Certificate Manager bedeutet das konkret: AWS zieht die eigene Deadline vor, statt bis zum letzten Forum-Tag zu warten. Diese Vorlaufzeit soll verhindern, dass Zertifikatsverantwortliche ihre Migration erst in den letzten Wochen vor dem Forum-Stichtag hektisch nachholen müssen.

Praktisch heißt das für Ihre Systeme: Jedes Zertifikat, das aktuell auf E-Mail-Validierung läuft, braucht vor September 2027 einen neuen Validierungsnachweis, sonst verlängert ACM es nicht mehr automatisch.

Andere große Cloud-Anbieter und Zertifizierungsstellen ziehen im gleichen Zeitraum nach, weil sie an dieselbe Forum-Vorgabe gebunden sind. Wer Zertifikate parallel bei mehreren Anbietern bezieht, sollte also nicht nur den ACM-Bestand prüfen, sondern auch externe Stellen nach deren eigenem Migrationsfahrplan fragen.

Vier Daten, die Zertifikatsverantwortliche jetzt markieren sollten

AWS nennt im Blogpost vier konkrete Stichtage. Zum 1. Januar 2027 bietet ACM E-Mail-Validierung in neuen AWS-Regionen nicht mehr an, betroffen sind also zunächst nur Regionen, die erst nach diesem Datum hinzukommen.

Zum 31. März 2027 verschwindet die E-Mail-Validierung für neue Zertifikatsanfragen in sämtlichen bestehenden Regionen. Wer ab diesem Tag ein neues öffentliches Zertifikat beantragt, kommt an DNS-Validierung oder, bei CloudFront-Bindung, an HTTP-Validierung nicht mehr vorbei.

Zum 30. September 2027 verlängert ACM keine bereits laufenden, per E-Mail validierten Zertifikate mehr. Ab diesem Datum betrifft der Umstieg nicht nur Neuanträge, sondern jedes Bestandszertifikat, das noch auf dem alten Weg läuft.

Die vier Daten bauen aufeinander auf, statt unabhängig nebeneinander zu stehen: Wer die erste Frist im Januar 2027 verpasst, merkt es zunächst nur bei neuen Regionen. Wer dagegen die dritte Frist im September 2027 reißt, riskiert, dass laufende Produktionszertifikate ohne Vorwarnung nicht mehr automatisch erneuert werden.

Der vierte Termin, der 15. März 2028, gehört formal dem CA/B Forum und nicht AWS allein. Er markiert den Punkt, an dem E-Mail-validierte Zertifikate branchenweit aus dem Vertrauen der Browser fallen, unabhängig davon, welche Zertifizierungsstelle sie einst ausgestellt hat.

Wer parallel prüft, wie andere Sicherheitslücken durch übersehene Altlasten entstehen, findet dazu Kontext in unserer Analyse zu Dateipfad-Schwachstellen bei Filebrowser Quantum. Auch dort reicht ein einzelner übersehener Pfad, um ein ganzes Vertrauensmodell zu unterlaufen.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptTwo gloved hands place blank polished metal rings into a transparent empty case on a plain stone surface, symbolizing a controlled validation handover using only unmarked shapes, no paper, no documents, no forms, no writing, no letters, no numbers, no labels, no logos, no screens, no interface, clean side light, photorealistic editorial style. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

DNS-Validierung verändert den Vertrauensanker

Mit DNS-Validierung verlagert sich der Vertrauensanker von einem Postfach auf einen Eintrag in der eigenen DNS-Zone. ACM stellt dafür einen CNAME-Datensatz bereit, den Kundinnen und Kunden bei ihrem DNS-Anbieter hinterlegen.

Der Unterschied wirkt technisch, hat aber handfeste Sicherheitsfolgen: Wer die DNS-Zone kontrolliert, kontrolliert auch die Validierung. Ein kompromittiertes E-Mail-Postfach reicht künftig nicht mehr aus, um ein Zertifikat für eine fremde Domain zu erschleichen.

AWS erweitert für den Wechsel die API UpdateCertificateOptions, mit der sich die Validierungsmethode eines bestehenden Zertifikats direkt von E-Mail auf DNS umstellen lässt. Die Amazon Resource Name bleibt dabei unverändert, sodass Referenzen in Load Balancern, CloudFront-Verteilungen oder API Gateways nicht angepasst werden müssen.

Sobald die Umstellung angestoßen ist, bleibt ein Fenster von 72 Stunden, um den bereitgestellten CNAME-Eintrag zu setzen. Wird das Fenster verpasst, bleibt das Zertifikat vorerst auf E-Mail-Validierung aktiv, und ein erneuter Versuch ist jederzeit möglich.

Diese Kulanzfrist unterscheidet ACM von manch anderer Zertifizierungsstelle, bei der ein verpasstes Fenster den gesamten Antrag neu startet. Hier bleibt der bestehende Zertifikatsstatus erhalten, während im Hintergrund ein neuer Versuch möglich ist, sobald der DNS-Eintrag korrekt gesetzt wurde.

Wie der Wechsel ohne neue ARN gelingt

Für die Bestandsaufnahme bietet die ACM-Konsole einen direkten Filter: Validierungsmethode gleich E-Mail, kombiniert mit Typ gleich Amazon Issued, listet alle betroffenen öffentlichen Zertifikate auf einen Blick.

Wer lieber automatisiert vorgeht, kann über die AWS Command Line Interface sämtliche Zertifikate einer Region abfragen und anhand der Validierungsmethode filtern. Das eignet sich besonders für Umgebungen mit vielen Konten oder Regionen, in denen eine manuelle Konsolenprüfung zu lange dauert.

Nach der Umstellung übernimmt ACM die Verlängerung automatisch, solange der CNAME-Eintrag in der DNS-Zone bestehen bleibt. Fällt der Eintrag versehentlich weg, etwa bei einer DNS-Migration, kann das die automatische Erneuerung unterbrechen.

Für Route 53 als DNS-Anbieter bietet AWS einen Ein-Klick-Weg, der die nötigen Einträge direkt anlegt. Wer einen externen DNS-Anbieter nutzt, exportiert die CNAME-Werte stattdessen als CSV-Datei und trägt sie manuell oder per API ein.

Größere Teams tun gut daran, den CLI-Weg in bestehende Inventarisierungs-Skripte einzubauen, statt jede Region einzeln per Konsole durchzuklicken. Ein einmal geschriebenes Skript lässt sich über mehrere Konten hinweg wiederverwenden und liefert eine belastbare Liste, bevor die erste der vier Fristen greift.

Für die Konsolenvariante liefert AWS im Blogpost auch Screenshots der einzelnen Schritte, von der Filterliste über den Button Update validation method bis zur Anzeige der neuen DNS-Datensätze. Diese visuelle Führung richtet sich vor allem an Teams, die Zertifikate selten manuell verwalten und den Ablauf nur einmal jährlich durchlaufen.

Wo Teams beim Umstieg stolpern

Der größte Stolperstein liegt selten in der Technik, sondern in der Übersicht: Wer Zertifikate über mehrere AWS-Konten, Regionen und Teams verteilt betreibt, verliert leicht den Überblick, welches Zertifikat noch auf E-Mail-Validierung läuft.

Ein zweites Risiko betrifft externe DNS-Anbieter außerhalb von Route 53. Wird der CNAME-Eintrag dort nicht rechtzeitig oder fehlerhaft gesetzt, bleibt das Zertifikat zwar vorerst gültig, verpasst aber die automatische Verlängerung, sobald die E-Mail-Validierung endgültig abgeschaltet ist.

Wer heute schon Zertifikate mit kurzen Laufzeiten verwaltet, sollte die Migration nicht auf die letzten Wochen vor dem 30. September 2027 verschieben. Gerade in verteilten Teams braucht die Abstimmung mit externen DNS-Verwaltern oft mehr Vorlauf als ein einzelner Klick in der Konsole.

Ein drittes, oft unterschätztes Problem sind vergessene Catch-all-Postfächer, über die frühere E-Mail-Validierungen ursprünglich liefen. Solange diese Adressen aktiv bleiben, bemerken Teams selten, wie viele Alt-Zertifikate noch auf ihnen aufsetzen, bis eine Prüfung der Validierungsmethode das offenlegt.

Wie unterschiedlich Unternehmen mit ablaufenden Vertrauensmechanismen umgehen, zeigt auch unser Beitrag zum Matter-Rollout von Eve und Aqara im Energiemanagement, wo ein neuer Standard ähnlich gestaffelt eingeführt wird.

Was nach dem 15. März 2028 gilt

Nach dem Forum-Stichtag im März 2028 bleiben bereits ausgestellte, per E-Mail validierte Zertifikate laut CA/B Forum bis zu ihrem regulären Ablaufdatum gültig. Neu ausgestellt oder verlängert werden darf auf diesem Weg dann aber branchenweit nicht mehr.

Für ACM heißt das im Ergebnis: Wer die eigene AWS-Frist zum 30. September 2027 verpasst, gerät nicht sofort in eine Sicherheitslücke, verliert aber die automatische Verlängerung und muss die Umstellung ohnehin vor dem Forum-Stichtag nachholen.

Zwei Wege bleiben für neue Zertifikate übrig: DNS-Validierung als von AWS empfohlener Standardweg sowie eine HTTP-Validierung, die ausschließlich für Zertifikate verfügbar ist, die mit Amazon CloudFront verknüpft sind. Beide Methoden ersetzen den manuellen Freigabeschritt der E-Mail-Validierung durch automatisierbare Nachweise.

Bei Rückfragen zur eigenen Migration verweist AWS im Blogpost auf den offiziellen Support-Kanal und ein Diskussionsforum im AWS re:Post. Wer die vier Daten jetzt im Kalender markiert, verschiebt das Thema nicht auf 2027, sondern erledigt es, während noch Zeit für Tests bleibt.

Am Ende bleibt die Migration überschaubar: ein CNAME-Eintrag pro Zertifikat, ein Fenster von 72 Stunden und eine ARN, die konstant bleibt. Wer diesen einen Schritt frühzeitig einplant, muss sich um den harten Forum-Stichtag im März 2028 keine Sorgen mehr machen.

Für Teams, die ohnehin regelmäßig Infrastruktur-Skripte pflegen, lässt sich die Umstellung als einmalige Aufgabe in den nächsten Wartungszyklus einbauen, statt als separates Sicherheitsprojekt zu behandeln. Der Aufwand pro Zertifikat bleibt gering, solange die DNS-Zone bekannt und zugänglich ist.