OpenMV MicroPython 14.4.3. Selbstsignierte Zertifikate#
Ein selbstsigniertes Zertifikat ist der schnellste Weg, TLS zwischen zwei von Ihnen kontrollierten Geräten zum Laufen zu bringen: Beide Enden vertrauen einem einzelnen Zertifikat, das Sie selbst erzeugen. Es deckt jede Bereitstellung ab, bei der Sie beide Seiten der Verbindung konfigurieren – eine öffentliche Zertifizierungsstelle kommt erst ins Spiel, wenn sich Drittanbieter-Clients verbinden müssen, ohne angewiesen zu werden, einem benutzerdefinierten Zertifikat zu vertrauen.
14.4.3.1. Ein selbstsigniertes Zertifikat erstellen#
Führen Sie OpenSSL auf Ihrem Entwicklungsrechner aus. Der subjectAltName (SAN) ist das, was moderne TLS-Clients bei der Hostnamen-Verifizierung prüfen, setzen Sie ihn also auf die Hostnamen und/oder IP-Adressen, über die Clients die Kamera erreichen (CN allein ist veraltet und wird von vielen Clients ignoriert). Ersetzen Sie DNS:openmv / IP:192.168.1.50 durch die Adresse, mit der sich Ihre Clients tatsächlich verbinden.
ECDSA P-256 – empfohlen:
# 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 – stärker, größer/langsamer:
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 Kompatibilität:
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"
Bemerkung
Ein Client-Zertifikat (verwendet für die gegenseitige Authentifizierung, siehe unten) wird mit genau denselben Befehlen erstellt – am Zertifikat selbst ist nichts Client-spezifisch. Erzeugen Sie einfach ein zweites, unabhängiges Schlüssel-/Zertifikatspaar unter anderen Namen (z. B. client.key / client.crt) und verwenden Sie es auf dem Client wie im mTLS-Beispiel gezeigt. Der subjectAltName ist nur für die Seite relevant, deren Hostnamen der Peer verifiziert (der Client prüft den Namen des Servers; den Client prüft niemand), daher kann er bei einem reinen Client-Zertifikat weggelassen werden. Das -subj / CN ist bei einem Client-Zertifikat ebenfalls nur eine Bezeichnung – die Serverseite prüft hier nur, dass das Zertifikat zu einer vertrauenswürdigen CA verkettet ist, sie gleicht den Namen nie ab – setzen Sie es also auf das, was diesen Client identifiziert (z. B. /CN=sensor-01). Behalten Sie in jedem Fall einen -subj-Wert bei, damit OpenSSL das Zertifikat nicht-interaktiv erzeugen kann.
Die Zertifikatslebensdauer wird über -days festgelegt; Zertifikate laufen ab und müssen vorher neu erzeugt und erneut bereitgestellt werden.
14.4.3.2. Nach DER konvertieren#
Konvertieren Sie sowohl das Zertifikat als auch den privaten Schlüssel nach DER, bevor Sie sie auf die Kamera kopieren:
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. Dateien auf die Kamera kopieren#
Kopieren Sie die DER-Dateien in das Dateisystem der Kamera – zum Beispiel, indem Sie sie auf das USB-Laufwerk der OpenMV Cam ziehen, oder mit mpremote cp server.der : und mpremote cp server.key.der :. Kopieren Sie auf der verifizierenden Seite zusätzlich das CA-/Peer-Zertifikat in DER-Form.
Die DER-Dateien müssen nicht im beschreibbaren Dateisystem liegen. MicroPython kann auch ein schreibgeschütztes ROMFS-Image unter /rom einhängen, und dort abgelegte Zertifikate werden genau wie jede andere Datei geladen – z. B. ctx.load_cert_chain("/rom/server.der", "/rom/server.key.der"). Ein ROMFS-Image wird auf Ihrem Entwicklungsrechner vorbereitet und ist zur Laufzeit schreibgeschützt, sodass das Zertifikat auf dem Gerät nicht verändert werden kann – nützlich, um eine Produktionseinheit abzuriegeln. Beachten Sie, dass ein in ROMFS gespeicherter privater Schlüssel weiterhin von auf der Kamera laufendem Code lesbar ist; ROMFS schützt vor Änderung, nicht vor Extraktion. Ein in ROMFS residentes Zertifikat lässt sich nur durch Neubau und erneutes Flashen des Images ersetzen.
14.4.3.4. Das Zertifikat verwenden#
Ein vollständiger Client, der die Uhr stellt, einen Socket öffnet, einen selbstsignierten Server verifiziert und Daten austauscht:
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()
Ein vollständiger Server, der sein Zertifikat und seinen Schlüssel vorlegt:
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()
Für die gegenseitige Authentifizierung (mTLS) verlangt und verifiziert der Server zusätzlich ein Client-Zertifikat, und der Client legt ein eigenes vor:
# 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")
Die vollständige API finden Sie in der Dokumentation des Moduls ssl.
Bemerkung
Alles auf dieser Seite gilt unverändert für DTLS (TLS über UDP). Die Schlüssel, Zertifikate, das DER-Format, das Vertrauensmodell, die Ablaufproblematik sowie die Aufrufe load_cert_chain / load_verify_locations sind identisch; nur der Transport unterscheidet sich – Sie umhüllen einen socket.SOCK_DGRAM-Socket und wählen ssl.PROTOCOL_DTLS_CLIENT / ssl.PROTOCOL_DTLS_SERVER anstelle der TLS-Protokollkonstanten. Die eine zusätzliche Feinheit ist ein serverseitiger Anti-Spoofing-Cookie – die erste Verbindung eines neuen Clients schlägt erwartungsgemäß fehl, und der Client versucht es einfach erneut; Einzelheiten siehe DTLS-Unterstützung.