14.4.6. Operaties: sleutels, verloop en probleemoplossing

Drie stukken certificaatwerk komen bij elk uitgerold apparaat terug: het beschermen van de privésleutel zodra die op de camera staat, het anticiperen op de dag waarop het certificaat verloopt, en de korte lijst foutmodi die zich in de praktijk voordoen.

14.4.6.1. De privésleutel beschermen

Telkens wanneer de camera een certificaat aanbiedt – als TLS-server, of als client in mTLS – moet de bijbehorende privésleutel op het apparaat staan, in onbewerkte DER, op het bestandssysteem of in ROMFS. Op die manier opgeslagen is hij leesbaar voor elke code die op de camera draait en voor iedereen met fysieke toegang ertoe: de USB-massaopslagschijf, een REPL-prompt, of het ruwe flashgeheugen. ROMFS en alleen-lezen-vlaggen voorkomen wijziging, niet uitlezing. Beschouw elke privésleutel die op een apparaat wordt meegeleverd als herstelbaar door een vastberaden aanvaller met fysieke toegang of codetoegang.

Dit maakt TLS niet zinloos – het bepaalt hoe je het uitrolt:

  • Gebruik een unieke sleutel en certificaat per apparaat. Flash nooit een gedeelde sleutel over de hele vloot: het uitlezen ervan uit één enkele eenheid zou een aanvaller dan in staat stellen om elke camera te imiteren. Sleutels per apparaat beperken een compromittering tot dat ene apparaat, dat je serverzijdig kunt intrekken of uitschakelen.

  • Houd certificaten kortlevend. Een gestolen sleutel is alleen nuttig zolang het bijbehorende certificaat geldig is; korte levensduur plus routinematige rotatie beperken de schade (zie Certificaatverloop en -rotatie hieronder).

  • Vermijd waar mogelijk om überhaupt een geheim op het apparaat te plaatsen. Als je alleen de server hoeft te verifiëren (serverauthenticatie, geen mTLS), slaat de camera als client alleen het CA-certificaat op – dat openbaar is – en bevat geen privésleutel die de moeite van het stelen waard is.

  • Lever nooit een sleutel mee in een openbaar firmware-image. Een sleutel die in ROMFS is ingebakken in een firmwarebuild die je distribueert, is niet geheim; iedereen die de firmware downloadt heeft hem. Provisioning per apparaat betekent het programmeren van de sleutel na de generieke firmware, niet erin.

  • Beperk de schaderadius. Beperk de reikwijdte van datgene waarvoor het certificaat authenticeert (minste privilege), en zorg ervoor dat één enkele gelekte apparaatidentiteit kan worden ingetrokken of uitgeschakeld zonder de rest te beïnvloeden.

Als je dreigingsmodel aanvallers met fysieke toegang omvat, ontwerp dan met de aanname dat de apparaatsleutel uiteindelijk zal lekken en maak dat overleefbaar, in plaats van aan te nemen dat hij geheim kan worden gehouden op hardware die daar geen voorziening voor heeft.

14.4.6.2. Certificaatverloop en -rotatie

Elk certificaat draagt een geldigheidsvenster. Zodra dat verstrijkt, weigert een ssl.CERT_REQUIRED-peer de verbinding – verloop is dus een reële, geplande storing, geen theoretisch risico. De klok van de camera moet ook correct zijn opdat de geldigheidscontrole eerlijk wordt geëvalueerd.

  • Zelfondertekend. Je koos de levensduur met -days. Wanneer die verstrijkt, moet je de sleutel/het certificaat opnieuw genereren en opnieuw uitrollen: kopieer de DER-bestanden opnieuw, of bouw en flash het ROMFS-image opnieuw als het certificaat is ingebakken. Kies een -days-waarde waar je daadwerkelijk aan zult denken om actie op te ondernemen.

  • Openbare CA. Deze zijn doelbewust kortlevend. Let’s Encrypt geeft certificaten van 90 dagen uit en verwacht geautomatiseerde verlenging ongeveer elke 60 dagen; er is geen optie om “één keer te installeren en te vergeten”.

De bredere trend is eenrichtingsverkeer: de maximale geldigheid van publiek vertrouwde TLS-certificaten blijft krimpen. Het was 825 dagen, is momenteel begrensd op 398 dagen, en het CA/Browser Forum heeft een schema aangenomen dat het tegen 2029 afbouwt naar ongeveer 47 dagen. De conclusie voor een apparaatontwerp is om aan te nemen dat certificaten kortlevend zijn en dat rotatie geautomatiseerd of op zijn minst routinematig moet zijn – lever geen product dat afhankelijk is van een mens die een tienjarig certificaat verwisselt.

Praktisch gezien, op de camera: geef de voorkeur aan ontwerpen waarbij het certificaat kan worden vervangen zonder opnieuw te flashen (een beschrijfbaar bestandssysteem plus een pad voor externe updates, of de camera als client draaien die een CA vertrouwt die je centraal roteert). Als een certificaat in ROMFS moet leven, plan dan firmware-updates rond de levensduur ervan.

14.4.6.3. Probleemoplossing

  • De klok moet zijn ingesteld. Een camera die zijn klok sinds het inschakelen niet heeft ingesteld, faalt de certificaatgeldigheidscontrole – roep eerst ntptime.settime() aan.

  • Hostnaam moet overeenkomen. Wanneer de client server_hostname doorgeeft, moet die overeenkomen met de subjectAltName van het certificaat (of CN op oudere stacks), anders mislukt de verificatie.

  • Verkeerd formaat. Een PEM-bestand dat naar de camera is gekopieerd, laadt niet – converteer eerst naar DER.

  • Certificaat verlopen. Een verbinding die voorheen werkte en nu faalt met OSError heeft mogelijk simpelweg een verlopen certificaat – controleer de geldigheidsdata en genereer/rol opnieuw uit indien nodig.

  • Ed25519-sleutels falen. Gebruik ECDSA P-256/P-384 of RSA, niet Ed25519.

  • Fouten zijn OSError. MicroPython implementeert ssl.SSLError niet; TLS-fouten (ongeldig certificaat, verlopen, onbekende CA, formaatfout, handshakefout) worden opgeworpen als OSError.