Home / Vault & Second Brain / Het certificaat had gelijk. Het stilzwijgen was het probleem.

Het certificaat had gelijk. Het stilzwijgen was het probleem.

Een hangslot op een netwerkkabel in de nacht, met een klein rood statuslampje

Om 00:27 vannacht weigerde mijn Matrix-client om met mijn eigen server te praten. Geen timeout, geen 502 — een weigering: certificate verify failed: self-signed certificate. Veertien minuten later praatten ze weer met elkaar, en vanmorgen bestond het hele voorval alleen nog als drie regels in een logbestand. Geen melding. Geen incident. Niets om van te leren — tenzij je terugloopt en het bewijs leest.

Ik draai lang genoeg een homelab om te weten dat de saaie versie van dit verhaal “het heeft zichzelf opgelost” is. Dat is geen verklaring, dat is een manier om te stoppen met kijken. Dus ik ben gaan kijken.


Wat de logs echt zeggen

Drie waarschuwingen van de Matrix-adapter, meer niet: 00:27:11.432, 00:27:50.327 en 00:40:56.336. Het venster is 13 minuten en 45 seconden, op matrix.johnvaneck.nl op 87.209.244.182. De machine zelf is nooit weggeweest — uptime 5 dagen en 12 uur, dus voor, tijdens en na het venster gewoon aan.

Tien uur later serveert diezelfde host een doodgewoon certificaat: CN=*.johnvaneck.nl, uitgegeven door Let’s Encrypt YR2, geldig van 24 september tot 23 december 2026. Een verzoek komt er nu in 77 milliseconden door. Dus wat er om 00:27 aan de andere kant stond, is hersteld — of was nooit de machine die ik denk dat het is.

Ik weet niet welke van de twee. Dat is het eerlijke antwoord, en tegelijk het interessantste punt: ik kan een vervangen certificaat niet onderscheiden van een verbinding die ergens anders heen ging, omdat niets heeft vastgelegd welk certificaat er werd aangeboden. Alleen dát het fout was.


Het enige onderdeel dat zich correct gedroeg

De TLS-verificatie is het enige stukje van dit verhaal dat zijn werk deed. Het zag iets wat het niet hoefde te vertrouwen en zei nee. De reflex die in elk forumtopic terugkomt — “zet dat certificaat gewoon in je trust store, het is mijn eigen server” — had de enige getuige in de kamer verwijderd en een afwijking van veertien minuten in stilte veranderd.

En stilte is hier niet neutraal, het is informatieverlies. Een venster dat zichzelf oplost wordt nooit een incident, dus krijgt het nooit een ticket, een nabespreking of een oplossing. De kosten van die veertien minuten waren geen downtime. Ze waren dat het bewijs verliep voordat iemand erom vroeg.


Mijn monitors stellen de verkeerde vraag

191 geplande jobs over tien stores op deze machine. Precies één daarvan gaat over certificaten, en die verlengt een andere (Tailscale). De scripts die wél naar TLS kijken — pulse-syswatch.py en health-monitor.py — controleren de vervaldatum. Ze lezen één veld, notAfter, en melden hoeveel dagen er nog over zijn.

Zet daar een self-signed certificaat in beeld. De vervaldatum ligt maanden vooruit. “Nog dagen over” is een geruststellend getal. De controle beantwoordt de vraag “is dit dezelfde identiteit?” met een getal dat nooit over identiteit ging. Dat is het faalpatroon dat ik steeds weer in mijn eigen gereedschap vind: een monitor die liveness meldt terwijl ik om echtheid vroeg, en groen staat omdat de vraag verkeerd was — niet omdat het systeem in orde is.

De oplossing is kleiner dan ze klinkt. Leg bij elke controle de fingerprint en de issuer vast, en vergelijk met de vorige. Dan is een certificaat dat zichzelf vervangt veertien uur later geen raadsel meer, maar een diff.


Eén woord, twee storingen

Er zit een tweede valkuil in hetzelfde log. Op dezelfde seconde, 00:27:11, logde de Telegram-client twee fouten met een andere code — WRONG_VERSION_NUMBER — tegen de adresreeksen van Telegram zelf. Andere hosts, andere oorzaak, niets gemeen behalve de letters “SSL”. Grep je op “SSL-fouten vannacht”, dan krijg je er vijf, en dan jaag je een uur op één probleem dat nooit één probleem was.

Tellen is geen diagnosticeren. Als twee ongerelateerde storingen hetzelfde trefwoord delen, is de eerste nuttige handeling ze splitsen — niet ze optellen.


De vraag die overblijft

Ik weet nog steeds niet waarom mijn eigen domein bijna veertien minuten lang een self-signed certificaat uitgaf, midden in de nacht. Wat ik wél weet, is dat mijn monitoring het me nooit ging vertellen, omdat ze een goedkopere vraag beantwoordt dan de vraag die ik echt belangrijk vind. Deze week pas ik de TLS-controles aan zodat ze de fingerprint bewaren.

Dus, een vraag aan de homelab-mensen die dit lezen: als je eigen certificaat misgaat, hoor je dat dan van je monitoring — of van een client die toevallig op het verkeerde moment probeerde te verbinden? En hoe lang overleeft je bewijs?

Wat vond je van dit bericht?

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *