DuckDNS Let's Encrypt erfolgreich: Ursache war ein falscher aliases-Eintrag

Tatsaechliche Ursache der deploy_challenge-Fehlschlaege gefunden: ein
ueberfluessiger/falscher aliases-Eintrag (alias: datametric360 ohne
.duckdns.org) in der DuckDNS-Add-on-Konfiguration, zusammen mit
accept_terms: false. Nach Entfernen von aliases und accept_terms: true lief
die Zertifikatsanfrage sofort durch. Der DNS-Server war entgegen der
vorherigen Vermutung kein Faktor - Erfolg trat auch mit dem Speedport als
DNS ein.

configuration.yaml's alter http:-Block entfernt, HA migriert SSL-Pfade und
interne/externe URL jetzt ueber die Oberflaeche (Einstellungen > System >
Netzwerk). Dabei eine HA-Eigenheit dokumentiert: Netzwerkaenderungen muessen
innerhalb 5 Minuten per Dialog bestaetigt werden, sonst automatischer
Rollback.

HA ist jetzt per HTTPS mit gueltigem Let's-Encrypt-Zertifikat erreichbar.

AGENTS.md

@@ -205,11 +205,11 @@ capacitor/iframe/browser (`umgebung.ts`), types + entity table (`types.ts`), fac
 - [x] Decide broker reachability for the vehicle — port-forward 8883 (not VPS bridge), decided
       2026-08-11; DuckDNS hostname `datametric360.duckdns.org` set up and reliably updating,
       port-forward 8883 done on the Speedport Smart 4 Plus, FMM003 confirmed sending data. Let's
-      Encrypt for HA's own local UI deliberately dropped (`deploy_challenge` DNS-01 hook failed
-      reproducibly inside the DuckDNS add-on container specifically — root cause not found despite
-      thorough diagnosis; not worth pursuing since HA is Tailscale-only anyway, see
-      COMPANION_APP_ARCHITECTURE.md §5 item 2a for the full writeup). `configuration.yaml`'s
-      `http: ssl_certificate/ssl_key` block stays commented out permanently.
+      Encrypt for HA's own local UI is now working too (root cause of the earlier DNS-01 failures
+      was a stray `aliases` entry in the DuckDNS add-on config, not DNS/network — see
+      COMPANION_APP_ARCHITECTURE.md §5 item 2a for the full writeup). HA's SSL config now lives in
+      Settings → System → Network (UI), not `configuration.yaml`'s old `http:` block, which was
+      removed after HA started migrating/ignoring it.
 - [ ] MQTT Client Type on the FMM003: "Custom server" (value 3, seen in Configurator help text) was
       not selectable in practice — use **"AWS IoT Custom"** pointed at the own broker instead
       (confirmed working by two independent community reports); verify once the device is live

COMPANION_APP_ARCHITECTURE.md

@@ -351,22 +351,32 @@ else in this document:
    FMM003-Pfad tatsächlich entscheidende Teil. Router bestätigt **Dual-Stack** (kein DS-Lite), die
    Portfreigabe 8883 am Speedport Smart 4 Plus ist eingerichtet, FMM003 sendet bestätigt Daten.
 
-   **Let's-Encrypt-Zertifikat für die HA-Oberfläche selbst — bewusst NICHT umgesetzt:** Der
-   `deploy_challenge`-Hook (DNS-01, TXT-Eintrag via DuckDNS-API) scheiterte reproduzierbar mit
-   `timeout 120s` beim Warten auf den eigenen TXT-Eintrag. Diagnose ausführlich durchgeführt: der
-   TXT-Eintrag wird von DuckDNS korrekt gesetzt (manuell per `txt=`-Parameter bestätigt, `OK`/
-   `UPDATED`) und ist öffentlich sofort sichtbar (bestätigt per `nslookup` gegen `8.8.8.8` vom PC
-   *und* per `dig` aus der HA-eigenen SSH-Konsole gegen den internen Supervisor-Resolver
-   `127.0.0.11`/`172.30.32.3` — beide sahen den aktuellen Challenge-Wert sofort). Trotzdem scheiterte
-   ausgerechnet der interne `dig`-Aufruf *im DuckDNS-Add-on-Container selbst* wiederholt (auch nach
-   Wechsel des HA-DNS-Servers auf `1.1.1.1` und komplettem Host-Neustart, `host_network: false`
-   bestätigt — Ursache innerhalb des Add-on-Containers blieb ungeklärt). **Entscheidung:** Let's
-   Encrypt im DuckDNS-Add-on deaktiviert statt weiter zu debuggen — verhältnismäßig, weil HA laut
-   Sicherheitsprinzip oben sowieso nie öffentlich exponiert wird und nur über Tailscale erreichbar
-   ist (das verschlüsselt den Transport bereits); ein eigenes Zertifikat für die lokale UI ist damit
-   ein Nice-to-have, kein Sicherheitserfordernis. Der `http: ssl_certificate`/`ssl_key`-Block in
-   `configuration.yaml` bleibt deshalb dauerhaft auskommentiert (er hatte HA sonst am Start
-   gehindert, solange die referenzierten Dateien nie erzeugt wurden).
+   **Let's-Encrypt-Zertifikat für die HA-Oberfläche selbst — ✅ ERLEDIGT (2026-08-11), nach
+   ausführlicher Fehlersuche.** Der `deploy_challenge`-Hook (DNS-01, TXT-Eintrag via DuckDNS-API)
+   scheiterte zunächst wiederholt mit `timeout 120s` beim Warten auf den eigenen TXT-Eintrag, obwohl
+   DuckDNS den Eintrag nachweislich korrekt setzte (bestätigt per `nslookup` gegen `8.8.8.8` vom PC
+   *und* per `dig` aus der HA-eigenen SSH-Konsole gegen den internen Supervisor-Resolver). Der DNS-
+   Server selbst war am Ende kein Faktor (Erfolg trat auch mit dem Speedport als DNS-Server ein) —
+   **tatsächliche Ursache war ein fehlerhafter `aliases`-Eintrag** in der DuckDNS-Add-on-Konfiguration
+   (`alias: datametric360` ohne `.duckdns.org`, überflüssig und falsch, da keine externe Domain per
+   CNAME verwendet wird — `aliases` ist nur für diesen Fall gedacht) zusammen mit `accept_terms:
+   false`. Nach Entfernen von `aliases` und Setzen von `accept_terms: true` lief die Zertifikatsanfrage
+   beim nächsten Versuch sofort erfolgreich durch (`Challenge is valid! ... Creating fullchain.pem...
+   Done!`), Zertifikat gültig bis 2026-11-09.
+
+   Anschließend `configuration.yaml`'s alter `http:`-Block (der HA-Start blockiert hatte, solange die
+   Zertifikatsdateien nicht existierten) entfernt — HA migriert SSL-Zertifikatspfad/-Schlüssel und die
+   interne/externe URL inzwischen in die Oberfläche (Einstellungen → System → Netzwerk). **Eigenheit
+   dabei:** eine geänderte Netzwerkkonfiguration muss innerhalb von 5 Minuten über einen Dialog in der
+   Oberfläche bestätigt werden, sonst macht HA sie automatisch rückgängig und startet mit dem vorigen
+   Stand neu (`Pending HTTP config was not confirmed within 0:05:00` im Log) — beim ersten Versuch
+   deshalb ungewollt zurückgerollt, beim zweiten Versuch bewusst sofort bestätigt, seitdem stabil.
+   Externe URL bewusst leer gelassen (Port 8123 ist nicht freigegeben, HA bleibt nicht öffentlich
+   erreichbar); interne URL auf `https://192.168.2.216:8123` gesetzt — das Zertifikat ist auf den
+   Hostnamen ausgestellt, nicht auf die IP, der Browser zeigt deshalb bei IP-Zugriff weiterhin eine
+   Namensabgleich-Warnung (Verbindung bleibt trotzdem verschlüsselt); ein lokaler DNS-Eintrag, der
+   `datametric360.duckdns.org` intern auf die lokale IP auflöst, wäre die sauberere, aber optionale
+   Nachbesserung.
 
    Nebenbei geklärt: ein Vorschlag, stattdessen komplett auf Cloudflare zu setzen, wurde geprüft und
    **ist keine Alternative** — Cloudflare Tunnel kann kein rohes MQTT/TCP transportieren (nur HTTP),