14.4.6. Drift: nycklar, utgång och felsökning

Tre delar av certifikatarbetet berör varje driftsatt enhet: att skydda den privata nyckeln när den väl finns på kameran, att planera för dagen då certifikatet går ut, och den korta listan med fellägen som dyker upp i praktiken.

14.4.6.1. Skydda den privata nyckeln

Närhelst kameran presenterar ett certifikat – som en TLS-server, eller som klient i mTLS – måste dess privata nyckel finnas på enheten, i ren DER, på filsystemet eller i ROMFS. Lagrad på det sättet är den läsbar för all kod som körs på kameran och för alla med fysisk åtkomst till den: USB-masslagringsenheten, en REPL-prompt eller det råa flashminnet. ROMFS och skrivskyddsflaggor förhindrar modifiering, inte extrahering. Betrakta varje privat nyckel som levereras på en enhet som möjlig att återskapa av en beslutsam angripare med fysisk åtkomst eller kodåtkomst.

Detta gör inte TLS meningslöst – det formar hur du driftsätter det:

  • Använd en unik nyckel och ett unikt certifikat per enhet. Flasha aldrig en delad nyckel över hela flottan: att extrahera den från en enda enhet skulle då låta en angripare utge sig för att vara varje kamera. Nycklar per enhet begränsar en kompromettering till just den enheten, som du kan återkalla eller inaktivera på serversidan.

  • Håll certifikat kortlivade. En stulen nyckel är bara användbar så länge dess certifikat är giltigt; korta livslängder plus rutinmässig rotation begränsar skadan (se Certifikatutgång och rotation nedan).

  • Undvik att alls lägga en hemlighet på enheten när du kan. Om du bara behöver verifiera servern (serverautentisering, inte mTLS) lagrar kameran som klient endast CA-certifikatet – som är offentligt – och har ingen privat nyckel värd att stjäla.

  • Leverera aldrig en nyckel i en offentlig firmware-avbildning. En nyckel inbakad i ROMFS i en firmware-build som du distribuerar är inte hemlig; alla som laddar ner firmwaren har den. Provisionering per enhet innebär att programmera nyckeln efter den generiska firmwaren, inte inuti den.

  • Begränsa skadeområdet. Avgränsa det som certifikatet autentiserar (lägsta möjliga behörighet), och se till att en enda läckt enhetsidentitet kan återkallas eller inaktiveras utan att påverka resten.

Om din hotmodell omfattar angripare med fysisk åtkomst, designa utifrån antagandet att enhetsnyckeln kommer att läcka så småningom och gör det möjligt att överleva, snarare än att anta att den kan hållas hemlig på hårdvara som inte har någon möjlighet att göra det.

14.4.6.2. Certifikatutgång och rotation

Varje certifikat har ett giltighetsfönster. När det väl passerat avvisar en ssl.CERT_REQUIRED-motpart anslutningen – så utgång är ett verkligt, schemalagt avbrott, inte en teoretisk risk. Kamerans klocka måste också vara korrekt för att giltighetskontrollen ska kunna utvärderas ärligt.

  • Självsignerat. Du valde livslängden med -days. När det löper ut måste du regenerera nyckeln/certifikatet och driftsätta det på nytt: kopiera DER-filerna igen, eller bygg om och flasha om ROMFS-avbildningen om certifikatet är inbakat. Välj ett -days-värde som du faktiskt kommer ihåg att agera på.

  • Offentlig CA. Dessa är medvetet kortlivade. Let’s Encrypt utfärdar 90-dagarscertifikat och förväntar sig automatiserad förnyelse ungefär var 60:e dag; det finns inget alternativ med ”installera en gång och glöm”.

Den bredare trenden är enkelriktad: den maximala giltigheten för offentligt betrodda TLS-certifikat fortsätter att krympa. Den var 825 dagar, är för närvarande begränsad till 398 dagar, och CA/Browser Forum har antagit ett schema som trappar ner den mot ungefär 47 dagar fram till 2029. Slutsatsen för en enhetsdesign är att anta att certifikat är kortlivade och att rotation måste vara automatiserad eller åtminstone rutinmässig – leverera inte en produkt som är beroende av att en människa byter ut ett tioårscertifikat.

Rent praktiskt, på kameran: föredra designer där certifikatet kan bytas ut utan att flasha om (ett skrivbart filsystem plus en väg för fjärruppdatering, eller att köra kameran som en klient som litar på en CA du roterar centralt). Om ett certifikat måste finnas i ROMFS, schemalägg firmware-uppdateringar kring dess livslängd.

14.4.6.3. Felsökning

  • Klockan måste vara inställd. En kamera som inte har ställt sin klocka sedan uppstart misslyckas med certifikatets giltighetskontroll – anropa ntptime.settime() först.

  • Värdnamnet måste stämma. När klienten skickar server_hostname måste det matcha certifikatets subjectAltName (eller CN på äldre stackar), annars misslyckas verifieringen.

  • Fel format. En PEM-fil som kopierats till kameran kommer inte att laddas – konvertera till DER först.

  • Certifikatet har gått ut. En anslutning som fungerade tidigare och nu misslyckas med OSError kan helt enkelt ha ett utgånget certifikat – kontrollera giltighetsdatumen och regenerera/driftsätt på nytt vid behov.

  • Ed25519-nycklar misslyckas. Använd ECDSA P-256/P-384 eller RSA, inte Ed25519.

  • Fel är OSError. MicroPython implementerar inte ssl.SSLError; TLS-fel (felaktigt certifikat, utgånget, okänd CA, formatfel, handskakningsfel) genereras som OSError.