OpenMV MicroPython 14.4.3. Zelfondertekende certificaten#
Een zelfondertekend certificaat is de snelste manier om TLS werkend te krijgen tussen twee apparaten die je beheert: beide uiteinden vertrouwen één enkel certificaat dat je zelf genereert. Het dekt elke uitrol waarbij je beide zijden van de verbinding configureert – een openbare Certificate Authority komt pas in beeld wanneer externe clients moeten verbinden zonder te worden verteld een aangepast certificaat te vertrouwen.
14.4.3.1. Een zelfondertekend certificaat aanmaken#
Voer OpenSSL uit op je ontwikkelmachine. De subjectAltName (SAN) is wat moderne TLS-clients controleren tijdens hostnaamverificatie, dus stel die in op de hostnaam(en) en/of het IP-adres(sen) die clients zullen gebruiken om de camera te bereiken (CN alleen is verouderd en wordt door veel clients genegeerd). Vervang DNS:openmv / IP:192.168.1.50 door het adres waarmee je clients daadwerkelijk verbinden.
ECDSA P-256 – aanbevolen:
# Generate a P-256 private key.
openssl ecparam -name prime256v1 -genkey -noout -out server.key
# Self-signed certificate valid for one year, with a SAN.
openssl req -new -x509 -key server.key -out server.crt -days 365 \
-subj "/CN=openmv" -addext "subjectAltName=DNS:openmv,IP:192.168.1.50"
ECDSA P-384 – sterker, groter/langzamer:
openssl ecparam -name secp384r1 -genkey -noout -out server.key
openssl req -new -x509 -key server.key -out server.crt -days 365 \
-subj "/CN=openmv" -addext "subjectAltName=DNS:openmv,IP:192.168.1.50"
RSA-2048 – maximale compatibiliteit:
openssl req -new -x509 -newkey rsa:2048 -nodes -keyout server.key \
-out server.crt -days 365 -subj "/CN=openmv" \
-addext "subjectAltName=DNS:openmv,IP:192.168.1.50"
Notitie
Een client-certificaat (gebruikt voor wederzijdse authenticatie, hieronder) wordt aangemaakt met exact dezelfde opdrachten – er is niets clientspecifieks aan het certificaat zelf. Genereer gewoon een tweede, onafhankelijk sleutel/certificaat-paar onder andere namen (bijv. client.key / client.crt) en gebruik het op de client zoals getoond in het mTLS-voorbeeld. De subjectAltName is alleen van belang voor de zijde wiens hostnaam de peer verifieert (de client controleert de naam van de server; niets controleert die van de client), dus kan worden weggelaten voor een uitsluitend client-certificaat. De -subj / CN is eveneens slechts een label op een clientcertificaat – de serverzijde controleert hier alleen of het certificaat naar een vertrouwde CA herleidt, hij matcht de naam nooit – dus stel die in op wat die client ook maar identificeert (bijv. /CN=sensor-01). Houd hoe dan ook een -subj-waarde aan, zodat OpenSSL het certificaat niet-interactief kan genereren.
De levensduur van het certificaat wordt ingesteld met -days; certificaten verlopen en moeten daarvoor opnieuw worden gegenereerd en uitgerold.
14.4.3.2. Converteren naar DER#
Converteer zowel het certificaat als de privésleutel naar DER voordat je ze naar de camera kopieert:
openssl x509 -in server.crt -outform DER -out server.der
openssl pkey -in server.key -outform DER -out server.key.der
14.4.3.3. Bestanden naar de camera kopiëren#
Kopieer de DER-bestanden naar het bestandssysteem van de camera – bijvoorbeeld door ze naar de USB-schijf van de OpenMV Cam te slepen, of met mpremote cp server.der : en mpremote cp server.key.der :. Kopieer aan de verifiërende zijde ook het CA-/peer-certificaat in DER-vorm.
De DER-bestanden hoeven niet op het beschrijfbare bestandssysteem te staan. MicroPython kan ook een alleen-lezen ROMFS-image aankoppelen op /rom, en daar geplaatste certificaten worden precies zo geladen als elk ander bestand – bijv. ctx.load_cert_chain("/rom/server.der", "/rom/server.key.der"). Een ROMFS-image wordt voorbereid op je ontwikkelmachine en is alleen-lezen tijdens runtime, dus het certificaat kan niet op het apparaat worden gewijzigd – handig om een productie-eenheid te vergrendelen. Let op dat een in ROMFS opgeslagen privésleutel nog steeds leesbaar is voor code die op de camera draait; ROMFS beschermt tegen wijziging, niet tegen uitlezing. Een in ROMFS aanwezig certificaat kan alleen worden vervangen door het image opnieuw te bouwen en te flashen.
14.4.3.4. Het certificaat gebruiken#
Een volledige client die de klok instelt, een socket opent, een zelfondertekende server verifieert en gegevens uitwisselt:
import socket
import ssl
import ntptime
ntptime.settime() # correct clock for the validity check
# Open a plain TCP connection.
addr = socket.getaddrinfo("openmv", 8443)[0][-1]
sock = socket.socket()
sock.connect(addr)
# Wrap it for TLS, trusting the server's self-signed certificate.
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.verify_mode = ssl.CERT_REQUIRED
ctx.load_verify_locations(cafile="server.der")
ssock = ctx.wrap_socket(sock, server_hostname="openmv")
ssock.write(b"hello\n")
print(ssock.read())
ssock.close()
Een volledige server die zijn certificaat en sleutel aanbiedt:
import socket
import ssl
import ntptime
ntptime.settime() # correct clock for the validity check
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ctx.load_cert_chain("server.der", "server.key.der")
sock = socket.socket()
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(socket.getaddrinfo("0.0.0.0", 8443)[0][-1])
sock.listen(1)
while True:
client, addr = sock.accept()
sclient = ctx.wrap_socket(client, server_side=True)
sclient.write(b"hello\n")
print(sclient.read())
sclient.close()
Voor wederzijdse authenticatie (mTLS) vereist en verifieert de server bovendien een clientcertificaat, en biedt de client er een van zichzelf aan:
# Server side: also demand and verify a client certificate.
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ctx.load_cert_chain("server.der", "server.key.der")
ctx.verify_mode = ssl.CERT_REQUIRED
ctx.load_verify_locations(cafile="client.der")
# Client side: present a certificate of our own.
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.load_cert_chain("client.der", "client.key.der")
ctx.verify_mode = ssl.CERT_REQUIRED
ctx.load_verify_locations(cafile="server.der")
Zie de documentatie van de ssl-module voor de volledige API.
Notitie
Alles op deze pagina is ongewijzigd van toepassing op DTLS (TLS over UDP). De sleutels, certificaten, het DER-formaat, het vertrouwensmodel, de verloopkwesties en de load_cert_chain- / load_verify_locations-aanroepen zijn identiek; alleen het transport verschilt – je omhult een socket.SOCK_DGRAM-socket en selecteert ssl.PROTOCOL_DTLS_CLIENT / ssl.PROTOCOL_DTLS_SERVER in plaats van de TLS-protocolconstanten. De enige extra complicatie is een anti-spoofing-cookie aan de serverzijde – van de eerste verbinding van een nieuwe client wordt verwacht dat die mislukt en de client probeert het simpelweg opnieuw; zie DTLS-ondersteuning voor details.