From 9063e53ce2d230aa41d06ae9c38920dc14243a0a Mon Sep 17 00:00:00 2001 From: Keith Jackson Date: Sat, 5 Sep 2026 11:11:53 -0500 Subject: [PATCH] =?UTF-8?q?docs(prod):=20prod=20verified=20end-to-end=20th?= =?UTF-8?q?rough=20the=20real=20resolver=20=E2=80=94=20dnsmasq=20profile?= =?UTF-8?q?=20installed?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Operator installed infra/workstation/dnsmasq/install.sh. Verified afterwards: RESOLUTION (live NetworkManager dnsmasq, `getent hosts`): prod.home / gitea.prod / keycloak.prod / grafana.prod -> 192.168.2.20 unifi.prod -> 192.168.2.21 crafty-mc.prod -> 192.168.2.22 gitea.home / home.keithjackson.dev -> 192.168.2.50 DEV, UNCHANGED HTTPS with NO --resolve override and NO -k, all landing on 192.168.2.20: apex 200 · gitea 200 · headlamp 200 · semaphore 200 keycloak 302 (login) · grafana 302 (SSO) · nextcloud 302 · pihole 302 CERTIFICATE, confirmed by SNI — this is the check that actually settles the earlier confusion, because the resolver bug made dev's cert look like a broken prod cert: subject CN=*.prod.home.keithjackson.dev issuer C=US, O=Let's Encrypt, CN=YR1 (LE production) SAN *.prod.home.keithjackson.dev, prod.home.keithjackson.dev valid 2026-09-05 .. 2026-12-04 Dev checked in the same pass still serves CN=*.home.keithjackson.dev. Also noted so it is not misread as a fault: `curl --cert-status` reports "(91) No OCSP response received" because Let's Encrypt retired OCSP responders in 2025 — there is nothing to staple. The plain requests validated normally. Prod is now reachable and trusted from the workstation by name. Outstanding items are unchanged: MinIO routing (prod is on pfSense's WAN), the apex flip being the same event as the legacy-prod 443 cutover, and delivering the backup-tenancy commits to prod via a c8c1d29-based branch. Refs R-DNS-02, R-PLAT-01. Co-Authored-By: Claude Opus 5 --- infra/PROD-STANDUP.md | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/infra/PROD-STANDUP.md b/infra/PROD-STANDUP.md index 61c4208..d9a342c 100644 --- a/infra/PROD-STANDUP.md +++ b/infra/PROD-STANDUP.md @@ -231,13 +231,30 @@ timeout 3600 infra/devcontainer/dev.sh run bootstrap/standup.sh \ | Published DNS | **36 records** under `prod.home.keithjackson.dev`, every TXT registry entry `owner=prod` | | Dev's records | **57, byte-identical to the pre-standup baseline — nothing added, changed or removed** | -End-to-end HTTPS, certificate validated (no `-k`), pinned to prod's gateway: +End-to-end HTTPS **through the workstation's own resolver — no `--resolve` override, no `-k`** (after +installing the dnsmasq profile below). Every request landed on `192.168.2.20`: ``` -prod.home.keithjackson.dev 200 keycloak.… 302 (login redirect) -gitea.prod.home.keithjackson.dev 200 grafana.… 302 (SSO redirect) +prod.home.keithjackson.dev 200 headlamp. 200 keycloak. 302 (login) nextcloud. 302 +gitea. 200 semaphore. 200 grafana. 302 (SSO) pihole. 302 ``` +The served certificate is prod's own, confirmed by SNI — **not** dev's wildcard, which is what the +resolver bug previously made it look like: + +``` +subject = CN=*.prod.home.keithjackson.dev +issuer = C=US, O=Let's Encrypt, CN=YR1 (LE production) +SAN = *.prod.home.keithjackson.dev, prod.home.keithjackson.dev +valid = 2026-09-05 .. 2026-12-04 +``` + +Dev, checked in the same pass, still serves `CN=*.home.keithjackson.dev` — **unchanged**. + +> Ignore `curl: (91) No OCSP response received` if you pass `--cert-status`: Let's Encrypt retired +> OCSP responders in 2025, so there is nothing to staple. It is not a certificate fault, and the plain +> requests above all validated normally. + ### Workstation DNS — install the prod dnsmasq profile **CORRECTION (operator, 2026-09-05): this is the workstation's own dnsmasq, NOT pfSense.** Earlier