diff --git a/hosts/cfgmon.md b/hosts/cfgmon.md
index c132ba0..7c0050e 100644
--- a/hosts/cfgmon.md
+++ b/hosts/cfgmon.md
@@ -58,23 +58,40 @@ Eine IP-Allowlist ist **keine** Option: Let's Encrypt veröffentlicht seine
 Validierungs-IPs nicht und prüft seit Einführung der Multi-Perspective Validation
 aus mehreren Regionen gleichzeitig.
 
-**IPv6 ist der Fallstrick.** `rohana`, `selendis` (und noch `www.*`, siehe
-[ZONE-01](../shared/zone-axion1337.md)) haben AAAA-Records auf
-`2a01:4f8:c17:93eb::1`. Damit validiert LE **bevorzugt über IPv6**. Die
-Hetzner-Cloud-Firewall braucht für 443 deshalb eine Regel mit Quelle `::/0` —
-`0.0.0.0/0` deckt IPv6 **nicht** mit ab. Fehlt sie, scheitert die Erneuerung, obwohl
-IPv4 offen ist.
+**IPv6 war der vermutete Fallstrick — geprüft und in Ordnung.** `rohana`, `selendis`
+(und noch `www.*`, siehe [ZONE-01](../shared/zone-axion1337.md)) haben AAAA-Records
+auf `2a01:4f8:c17:93eb::1`. Damit validiert LE **bevorzugt über IPv6**. Die
+Hetzner-Cloud-Firewall kennt kein familienübergreifendes „any": das Feld *Source IPs*
+ist eine Liste, `0.0.0.0/0` deckt IPv6 **nicht** mit ab, `::/0` muss separat drinstehen.
 
-Vom Host aus ist das **nicht verifizierbar**: eine Verbindung auf die eigene
-öffentliche Adresse läuft lokal und sagt nichts über den Weg von außen. Das
-Ausliefern über IPv6 funktioniert (`rohana` und `selendis` antworten mit 200,
-Traefik lauscht auf `[::]:443`) — das ist aber nicht dasselbe wie von außen
-erreichbar.
+Stand 2026-07-30 enthält die Inbound-Regel für TCP 443 **beide** Einträge — vom User
+in der Hetzner-Console nachgesehen. Damit ist der IPv6-Pfad frei.
+
+Diese Angabe stammt **nicht** aus einer Messung von diesem Host aus, sondern aus der
+Console. Vom Host ist es nicht verifizierbar: die Cloud-Firewall liegt außerhalb des
+Systems, `iptables` und `ufw` sagen nichts darüber (und Root gibt es hier nicht), eine
+Verbindung auf die eigene öffentliche Adresse läuft lokal, es gibt keinen zweiten Host
+für eine Rückverbindung, und Traefik läuft ohne Access-Log — es existieren also auch
+keine historischen Client-IPs. Für eine Prüfung von hier aus wäre ein
+Hetzner-API-Token mit Read-Berechtigung nötig.
+
+Auch die erfolgreiche Ausstellung vom 2026-07-30 um 12:00 UTC belegt IPv6 **nicht**:
+zu dem Zeitpunkt existierte für `selendis` noch kein AAAA-Record, LE hat also über
+IPv4 validiert. Die Erneuerung Ende September ist der erste Lauf, der IPv6 überhaupt
+versucht.
+
+**Damit bleibt als Risiko nur, ob die Ports offen bleiben.** Sie wurden am
+2026-07-30 für die Ausstellung geöffnet; der Normalzustand dieser Umgebung ist, 80
+und 443 aus Sicherheitsvorsicht auf die eigene IP zu beschränken. Werden sie wieder
+zugezogen, scheitert die Erneuerung Ende September genau wie heute Mittag — und zwar
+still.
 
 **Nächster Schritt:** Entscheidung zwischen
 
-- **A — Port 443 zur Erneuerung öffnen**, für IPv4 *und* IPv6. Nichts umbauen, aber
-  alle ~60 Tage daran denken, und das Scheitern fällt nicht auf.
+- **A — Ports offen lassen** bzw. zur Erneuerung wieder öffnen. Nichts umzubauen,
+  aber alle ~60 Tage daran zu denken, und ein Fehlschlag fällt erst auf, wenn jemand
+  die Seite aufruft. Wenn A, dann mit einem Kalendereintrag auf **Mitte September**,
+  nicht auf das Ablaufdatum.
 - **B — auf DNS-01 umstellen** (empfohlen). Validierung über einen TXT-Record,
   **kein offener Port nötig**, läuft bei dichter Firewall durch. Braucht ein
   API-Token für die Zone bei IONOS, als Secret für Traefik hinterlegt. Ermöglicht