From e41eed08527240335d1fcfa1eb60a0451fe90407 Mon Sep 17 00:00:00 2001 From: jochen Date: Wed, 30 Sep 2026 01:30:24 +0200 Subject: [PATCH] Issue 129 is live and reproduced, and needs three steps rather than one MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The certificate is genuine, from Mesh Internal CA, and nothing on the workstation trusts it — verbatim the error the report gives. The public name on the same proxy verifies cleanly, which puts the fault exactly where the report puts it. What is in the way is not an assignment. `ca-trust` is merged in the catalogue and has never been registered with the mesh — 39 of 76 manifests are — so there is no module to assign. It dry-runs clean and needs no artifact built. Two findings from reproducing it, both their own issues: 157 — every routed name is published with an `.internal` alias that nothing serves. The hosts file says keycloak.novox.be.internal; the proxy serves keycloak.novox.internal and refuses the other by name. The first three names I tried came from the hosts file and failed with a TLS alert rather than a verification error, which pointed at a regression that had not happened. 158 — the proxy re-logs all 52 routes every two seconds, 31 times a minute. The one line that explained 157 sat between two of them. Also recorded, because it was nearly filed as a defect and is not one: step-ca publishes roots as /roots.pem, which is PEM, so ca-trust's fetch and its refuse-a-non-certificate guard are both right. Its other endpoint /roots returns JSON that contains the text the guard greps for, so the guard is sound only because of which path is published. --- .../00-report.md | 2 +- .../01-diagnosis.md | 105 ++++++++++++------ .../00-report.md | 63 +++++++++++ .../00-report.md | 49 ++++++++ 4 files changed, 184 insertions(+), 35 deletions(-) create mode 100644 04-ISSUES/157-a-routed-names-internal-alias-is-served-by-nothing/00-report.md create mode 100644 04-ISSUES/158-the-proxy-re-reads-and-re-logs-every-route-every-two-seconds/00-report.md diff --git a/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md b/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md index e88390a..abb3825 100644 --- a/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md +++ b/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/00-report.md @@ -1,5 +1,5 @@ --- -status: located +status: diagnosing opened: 2026-09-26 located-in: [mesh-catalog ca-trust] --- diff --git a/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/01-diagnosis.md b/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/01-diagnosis.md index e262608..b49e2d2 100644 --- a/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/01-diagnosis.md +++ b/04-ISSUES/129-nothing-makes-a-machine-trust-the-meshs-authority/01-diagnosis.md @@ -1,45 +1,82 @@ -# Diagnosis +# 129 — diagnosis -*2026-09-29.* +*2026-09-30, from the workstation the issue was opened on.* -## What was ruled out +## Still live, and reproduced exactly -**That something already carries the root and it is only misplaced.** It does not. The authority -serves its root at a path beside its ACME directory, and the one thing that fetches it — the route -proxy — puts it in a directory of its own and hands it to one program. Nothing has ever written -into a machine's trust store. Measured on three converged machines: the anchors present are the -predecessor's authority and a developer tool's local root, and on the machines where the -predecessor's was deliberately removed, every internal name fails verification. +The certificate is genuine, the authority is the mesh's, and nothing on the machine trusts it: -**That the private network could carry it, the way it carries the registry's trust.** That is what -the report proposed, and it was rejected on consideration rather than on difficulty -([ADR 0147](../../02-DECISIONS/0147-a-module-anchors-the-meshs-authority.md), option 1): being on -the network is what makes the registry *reachable* and is therefore the right trigger there, while -trusting an authority is a separate fact from being able to reach it. The anchor's directory and -the command that refreshes the extracted bundles are also one operating system's difference, which -is the host's half of the mesh and not the controller's. +``` +$ openssl s_client -connect keycloak.novox.internal:443 -servername keycloak.novox.internal +subject=CN=keycloak.novox.internal +issuer=O=Mesh Internal CA, CN=Mesh Internal CA Intermediate CA +Verify return code: 20 (unable to get local issuer certificate) -**That it needs a new host resource type.** It does not, today. A file and a service say the whole -of it, which the packet filter already proves. The primitive becomes the right answer when a second -operating system is in play, and not before. +$ curl https://keycloak.novox.internal/ +curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20) +``` -## Where it belongs +`trust list` holds no entry for the mesh. The anchors present are two `mkcert` development roots and +the predecessor's lab root — the report's account of the trust store is unchanged. -A module in the catalogue: it requires `internal-acme-ca`, fetches the root over the mesh's own -network, installs it as a trust anchor, refreshes the machine's bundles, and — because being -unassigned stops its unit, and stopping the unit is what undoes it — takes both away again. +The public name on the same proxy verifies cleanly (`CN=keycloak.novox.be`, Let's Encrypt, return code +0), which places the fault exactly where the report puts it: not in the proxy, not in the authority, +and not in the certificate. -The owner is therefore `mesh-catalog`, module `ca-trust`, and nothing in the control plane. +**The name matters, and the report's "every HTTPS name the mesh serves internally" is too broad.** The +served internal name is `