OpenMV MicroPython 14.4.3. Certificats auto-signés#
Un certificat auto-signé est le moyen le plus rapide de faire fonctionner TLS entre deux appareils que vous contrôlez : les deux extrémités font confiance à un seul certificat que vous générez vous-même. Il couvre tous les déploiements où vous configurez les deux côtés de la connexion – une autorité de certification publique n’entre en jeu que lorsque des clients tiers doivent se connecter sans qu’on leur ait demandé de faire confiance à un certificat personnalisé.
14.4.3.1. Créer un certificat auto-signé#
Exécutez OpenSSL sur votre machine de développement. Le subjectAltName (SAN) est ce que les clients TLS modernes vérifient lors de la validation du nom d’hôte ; définissez-le donc avec le ou les noms d’hôte et/ou la ou les adresses IP que les clients utiliseront pour atteindre la caméra (le CN seul est obsolète et ignoré par de nombreux clients). Remplacez DNS:openmv / IP:192.168.1.50 par l’adresse à laquelle vos clients se connectent réellement.
ECDSA P-256 – recommandé:
# 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 – plus robuste, plus volumineux/plus lent:
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 – compatibilité maximale:
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"
Note
Un certificat client (utilisé pour l’authentification mutuelle, ci-dessous) se crée avec exactement ces mêmes commandes – il n’y a rien de spécifique au client dans le certificat lui-même. Générez simplement une seconde paire clé/certificat indépendante sous des noms différents (par exemple client.key / client.crt) et utilisez-la sur le client comme indiqué dans l’exemple mTLS. Le subjectAltName n’a d’importance que pour le côté dont le pair vérifie le nom d’hôte (le client vérifie le nom du serveur ; rien ne vérifie celui du client), il peut donc être omis pour un certificat purement client. Le -subj / CN n’est de même qu’une étiquette sur un certificat client – le côté serveur ici vérifie uniquement que le certificat remonte à une CA de confiance, il ne fait jamais correspondre le nom – définissez-le donc avec ce qui identifie ce client (par exemple /CN=sensor-01). Conservez tout de même une valeur -subj, afin qu’OpenSSL puisse générer le certificat de façon non interactive.
La durée de vie du certificat est définie par -days ; les certificats expirent et doivent être régénérés et redéployés avant cette échéance.
14.4.3.2. Conversion en DER#
Convertissez à la fois le certificat et la clé privée en DER avant de les copier sur la caméra:
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. Copier les fichiers sur la caméra#
Copiez les fichiers DER dans le système de fichiers de la caméra – par exemple en les faisant glisser sur le lecteur USB de l’OpenMV Cam, ou avec mpremote cp server.der : et mpremote cp server.key.der :. Du côté qui effectue la vérification, copiez également le certificat de la CA / du pair au format DER.
Les fichiers DER n’ont pas à résider sur le système de fichiers accessible en écriture. MicroPython peut aussi monter une image ROMFS en lecture seule sur /rom, et les certificats qui y sont placés sont chargés exactement comme n’importe quel autre fichier – par exemple ctx.load_cert_chain("/rom/server.der", "/rom/server.key.der"). Une image ROMFS est préparée sur votre machine de développement et est en lecture seule à l’exécution, de sorte que le certificat ne peut pas être modifié sur l’appareil – utile pour verrouiller une unité de production. Notez qu’une clé privée stockée dans ROMFS reste lisible par le code s’exécutant sur la caméra ; ROMFS protège contre la modification, pas contre l”extraction. Un certificat résidant dans ROMFS ne peut être remplacé qu’en reconstruisant et en reprogrammant l’image.
14.4.3.4. Utiliser le certificat#
Un client complet qui règle l’horloge, ouvre une socket, vérifie un serveur auto-signé et échange des données:
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()
Un serveur complet présentant son certificat et sa clé:
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()
Pour l”authentification mutuelle (mTLS), le serveur exige et vérifie en plus un certificat client, et le client en présente un qui lui est propre:
# 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")
Consultez la documentation du module ssl pour l’API complète.
Note
Tout ce qui figure sur cette page s’applique sans modification à DTLS (TLS sur UDP). Les clés, les certificats, le format DER, le modèle de confiance, les considérations d’expiration ainsi que les appels load_cert_chain / load_verify_locations sont identiques ; seul le transport diffère – vous encapsulez une socket socket.SOCK_DGRAM et sélectionnez ssl.PROTOCOL_DTLS_CLIENT / ssl.PROTOCOL_DTLS_SERVER au lieu des constantes de protocole TLS. La seule subtilité supplémentaire est un cookie anti-usurpation côté serveur – la première connexion d’un nouveau client est censée échouer et le client réessaie simplement ; voir Prise en charge DTLS pour les détails.