14.4.3. Certificados autoassinados¶

Um certificado autoassinado é a forma mais rápida de fazer TLS funcionar entre dois dispositivos que controla: ambos os extremos confiam num único certificado que gera você mesmo. Cobre todas as implementações onde configura ambos os lados da ligação – uma Autoridade de Certificação pública só entra em cena quando clientes de terceiros precisam de se ligar sem serem informados para confiar num certificado personalizado.

14.4.3.1. Criar um certificado autoassinado¶

Execute o OpenSSL na sua máquina de desenvolvimento. O subjectAltName (SAN) é o que os clientes TLS modernos verificam durante a verificação do nome de anfitrião, por isso defina-o para o(s) nome(s) de anfitrião e/ou endereço(s) IP que os clientes utilizarão para aceder à câmara (CN isolado é legado e é ignorado por muitos clientes). Substitua DNS:openmv / IP:192.168.1.50 pelo endereço ao qual os seus clientes realmente se ligam.

ECDSA P-256 – recomendado:

# 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 – mais forte, maior/mais lento:

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 – compatibilidade máxima:

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"

Nota

Um certificado de cliente (utilizado para autenticação mútua, abaixo) é criado exatamente com estes mesmos comandos – não há nada específico do cliente no próprio certificado. Basta gerar um segundo par chave/certificado independente com nomes diferentes (p.ex. client.key / client.crt) e utilizá-lo no cliente conforme mostrado no exemplo mTLS. O subjectAltName só é importante para o lado cujo nome de anfitrião o par verifica (o cliente verifica o nome do servidor; nada verifica o do cliente), por isso pode ser omitido num certificado apenas para cliente. O -subj / CN é igualmente apenas uma etiqueta num certificado de cliente – o lado servidor aqui verifica apenas que o certificado encadeia a uma CA de confiança, nunca faz corresponder o nome – por isso defina-o para o que identifica esse cliente (p.ex. /CN=sensor-01). Mantenha algum valor -subj independentemente, para que o OpenSSL possa gerar o certificado de forma não interativa.

O tempo de vida do certificado é definido por -days; os certificados expiram e têm de ser regenerados e reimplementados antes disso.

14.4.3.2. Converter para DER¶

Converta tanto o certificado como a chave privada para DER antes de os copiar para a câmara:

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. Copiar ficheiros para a câmara¶

Copie os ficheiros DER para o sistema de ficheiros da câmara – por exemplo arrastando-os para a unidade USB da OpenMV Cam, ou com mpremote cp server.der : e mpremote cp server.key.der :. No lado verificador, copie também o certificado CA / par em formato DER.

Os ficheiros DER não têm de residir no sistema de ficheiros gravável. O MicroPython também pode montar uma imagem ROMFS de apenas leitura em /rom, e os certificados colocados aí são carregados exatamente como qualquer outro ficheiro – p.ex. ctx.load_cert_chain("/rom/server.der", "/rom/server.key.der"). Uma imagem ROMFS é preparada na sua máquina de desenvolvimento e é de apenas leitura em tempo de execução, pelo que o certificado não pode ser alterado no dispositivo – útil para bloquear uma unidade de produção. Note que uma chave privada armazenada no ROMFS ainda é legível pelo código em execução na câmara; o ROMFS protege contra a modificação, não contra a extração. Um certificado residente em ROMFS só pode ser substituído reconstruindo e reinstalando o firmware.

14.4.3.4. Utilizar o certificado¶

Um cliente completo que define o relógio, abre um socket, verifica um servidor autoassinado e troca dados:

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()

Um servidor completo que apresenta o seu certificado e chave:

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()

Para autenticação mútua (mTLS) o servidor exige e verifica adicionalmente um certificado de cliente, e o cliente apresenta o seu próprio:

# 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")

Consulte a documentação do módulo ssl para a API completa.

Nota

Tudo nesta página aplica-se sem alterações ao DTLS (TLS sobre UDP). As chaves, certificados, formato DER, modelo de confiança, preocupações de expiração e as chamadas load_cert_chain / load_verify_locations são idênticos; apenas o transporte difere – envolve um socket socket.SOCK_DGRAM e seleciona ssl.PROTOCOL_DTLS_CLIENT / ssl.PROTOCOL_DTLS_SERVER em vez das constantes de protocolo TLS. A única complicação adicional é um cookie anti-falsificação do lado do servidor – a primeira ligação de um novo cliente deverá falhar e o cliente simplesmente tenta novamente; consulte Suporte a DTLS para detalhes.