OpenMV MicroPython 14.4.3. Itse allekirjoitetut varmenteet#
Itse allekirjoitettu varmenne on nopein tapa saada TLS toimimaan kahden hallitsemasi laitteen välillä: molemmat päät luottavat yhteen itse luomaasi varmenteeseen. Se kattaa jokaisen käyttöönoton jossa määrität yhteyden molemmat puolet – julkinen varmentaja (Certificate Authority) tulee kuvaan vasta kun kolmannen osapuolen asiakkaiden on yhdistettävä ilman että heitä neuvotaan luottamaan mukautettuun varmenteeseen.
14.4.3.1. Itse allekirjoitetun varmenteen luominen#
Suorita OpenSSL kehityskoneellasi. subjectAltName (SAN) on se mitä nykyaikaiset TLS-asiakkaat tarkistavat isäntänimen todennuksen aikana, joten aseta se isäntänimi(i)n ja/tai IP-osoittee(seen/siin) joita asiakkaat käyttävät kameran tavoittamiseen (pelkkä CN on vanhentunut ja monet asiakkaat jättävät sen huomiotta). Korvaa DNS:openmv / IP:192.168.1.50 osoitteella johon asiakkaasi todella yhdistävät.
ECDSA P-256 – suositeltu:
# 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 – vahvempi, suurempi/hitaampi:
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 – paras yhteensopivuus:
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"
Muista
Asiakasvarmenne (käytetään keskinäiseen todennukseen, alla) luodaan täsmälleen näillä samoilla komennoilla – itse varmenteessa ei ole mitään asiakaskohtaista. Luo vain toinen, riippumaton avain/varmenne-pari eri nimillä (esim. client.key / client.crt) ja käytä sitä asiakkaalla kuten mTLS-esimerkissä näytetään. subjectAltName on merkityksellinen vain sille puolelle jonka isäntänimen vertaisosapuoli todentaa (asiakas tarkistaa palvelimen nimen; mikään ei tarkista asiakkaan nimeä), joten sen voi jättää pois pelkästään asiakkaalle tarkoitetusta varmenteesta. -subj / CN on niin ikään vain merkintä asiakasvarmenteessa – palvelinpuoli tässä tarkistaa vain että varmenne ketjuuntuu luotettuun CA:han, se ei koskaan täsmää nimeen – joten aseta se mihin tahansa joka tunnistaa kyseisen asiakkaan (esim. /CN=sensor-01). Säilytä jokin -subj-arvo joka tapauksessa, jotta OpenSSL voi luoda varmenteen ei-interaktiivisesti.
Varmenteen voimassaoloajan asettaa -days; varmenteet vanhenevat ja ne on luotava uudelleen ja otettava uudelleen käyttöön ennen sitä.
14.4.3.2. Muuntaminen DER-muotoon#
Muunna sekä varmenne että yksityinen avain DER-muotoon ennen niiden kopioimista kameralle:
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. Tiedostojen kopioiminen kameralle#
Kopioi DER-tiedostot kameran tiedostojärjestelmään – esimerkiksi vetämällä ne OpenMV Camin USB-asemaan, tai komennoilla mpremote cp server.der : ja mpremote cp server.key.der :. Kopioi todennuksen tekevälle puolelle myös CA- / vertaisvarmenne DER-muodossa.
DER-tiedostojen ei tarvitse sijaita kirjoitettavalla tiedostojärjestelmällä. MicroPython voi myös liittää vain luku -tilaisen ROMFS-levykuvan polkuun /rom, ja sinne sijoitetut varmenteet ladataan täsmälleen kuten mikä tahansa muu tiedosto – esim. ctx.load_cert_chain("/rom/server.der", "/rom/server.key.der"). ROMFS-levykuva valmistellaan kehityskoneellasi ja se on vain luettavissa ajon aikana, joten varmennetta ei voi muuttaa laitteella – hyödyllistä tuotantoyksikön lukitsemiseen. Huomaa että ROMFS:ssä tallennettu yksityinen avain on silti kameralla suoritettavan koodin luettavissa; ROMFS suojaa muokkaamiselta, ei poimimiselta. ROMFS:ssä sijaitsevan varmenteen voi korvata vain rakentamalla ja flashaamalla levykuvan uudelleen.
14.4.3.4. Varmenteen käyttäminen#
Täydellinen asiakas joka asettaa kellon, avaa pistokkeen, todentaa itse allekirjoitetun palvelimen ja vaihtaa dataa:
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()
Täydellinen palvelin joka esittää varmenteensa ja avaimensa:
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()
Keskinäisessä todennuksessa (mTLS) palvelin lisäksi vaatii ja todentaa asiakasvarmenteen, ja asiakas esittää oman varmenteensa:
# 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")
Katso täydellinen API ssl-moduulin dokumentaatiosta.
Muista
Kaikki tällä sivulla pätee muuttumattomana DTLS:ään (TLS UDP:n yli). Avaimet, varmenteet, DER-muoto, luottamusmalli, vanhenemiseen liittyvät huolet sekä load_cert_chain / load_verify_locations -kutsut ovat identtisiä; vain siirtotapa eroaa – kääräiset socket.SOCK_DGRAM-pistokkeen ja valitset ssl.PROTOCOL_DTLS_CLIENT / ssl.PROTOCOL_DTLS_SERVER TLS-protokollavakioiden sijaan. Yksi ylimääräinen mutka on palvelinpuolen huijaamisenestoeväste – ensimmäisen yhteyden uudelta asiakkaalta odotetaan epäonnistuvan ja asiakas yksinkertaisesti yrittää uudelleen; ks. DTLS-tuki lisätietoja.