Administración de certificados de IoT Edge
Se aplica a:
IoT Edge 1.5 IoT Edge 1.4
Importante
IoT Edge 1.5 LTS e IoT Edge 1.4 LTS son versiones compatibles. IoT Edge 1.4 LTS finaliza su ciclo de vida el 12 de noviembre de 2024. Si está usando una versión anterior, consulte Actualización de IoT Edge.
Todos los dispositivos IoT Edge usan certificados para crear conexiones seguras entre el entorno de ejecución y los módulos que se ejecutan en el dispositivo. Los dispositivos IoT Edge que funcionan como puertas de enlace usan estos mismos certificados para conectarse también a sus dispositivos de nivel inferior.
Nota:
El término entidad de certificación raíz que se usa en este artículo hace referencia al certificado de la entidad de nivel superior de la cadena de certificados de la solución de IoT. No es necesario usar la raíz del certificado de una entidad de certificación sindicada o la raíz de la entidad de certificación de la organización. A menudo, es realmente un certificado de ENTIDAD de certificación intermedio.
Requisitos previos
Debe estar familiarizado con los conceptos de Descripción de cómo Azure IoT Edge usa certificados, en particular cómo IoT Edge usa certificados.
Un dispositivo IoT Edge.
Si no tiene un dispositivo IoT Edge configurado, puede crear uno en una máquina virtual de Azure. Siga los pasos de alguno de los artículos de inicio rápido para Crear un dispositivo virtual Linux o Crear un dispositivo virtual de Windows.
Capacidad de editar el archivo de configuración
config.tomlde IoT Edge siguiendo la plantilla de configuración.Si su
config.tomlno se basa en la plantilla, abra la plantilla y use las instrucciones comentadas para agregar secciones de configuración siguiendo la estructura de la plantilla.Si tiene una nueva instalación de IoT Edge que no se ha configurado, copie la plantilla para inicializar la configuración. No use este comando si tiene una configuración existente. Sobrescribe el archivo.
sudo cp /etc/aziot/config.toml.edge.template /etc/aziot/config.toml
Requisitos de formato
Sugerencia
- Un certificado se puede codificar en una representación binaria denominada DER (reglas de codificación distinguida) o una representación textual denominada PEM (Correo mejorado de privacidad). El formato PEM tiene un encabezado
-----BEGIN CERTIFICATE-----seguido del DER codificado en base64 seguido de un pie de página-----END CERTIFICATE-----. - De forma similar al certificado, la clave privada se puede codificar en DER binario o en un PEM de representación textual.
- Dado que PEM está delineado, también es posible construir un PEM que combine
CERTIFICATEyPRIVATE KEYsecuencialmente en el mismo archivo. - Por último, el certificado y la clave privada se pueden codificar juntos en una representación binaria denominada PKCS#12, cifrada con una contraseña opcional.
Las extensiones de archivo son arbitrarias y debe ejecutar el comando file o ver el archivo para comprobar el tipo. En general, los archivos usan las siguientes convenciones de extensión:
.ceres un certificado en formato DER o PEM..pemes un certificado, una clave privada o ambos en formato PEM..pfxes un archivo PKCS#12.
IoT Edge requiere que el certificado y la clave privada sean:
- Formato PEM
- Archivos independientes
- En la mayoría de los casos, con la cadena completa
Si obtiene un archivo .pfx del proveedor de PKI, es probable que el certificado y la clave privada se codifiquen juntos en un archivo. Compruebe que es un tipo de archivo PKCS#12 mediante el comando file. Puede convertir un archivo PKCS#12 .pfx en archivos PEM mediante el comando openssl pkcs12.
Si el proveedor de PKI proporciona un archivo .cer, puede contener el mismo certificado que .pfx, o bien podría ser el certificado emisor (raíz) del proveedor de PKI. Para comprobarlo, inspeccione el archivo con el comando openssl x509. Si es el certificado emisor:
- Si está en formato DER (binario), conviértalo a PEM con
openssl x509 -in cert.cer -out cert.pem. - Use el archivo PEM como agrupación de confianza. Para más información sobre la agrupación de confianza, consulte la siguiente sección.
Importante
La infraestructura de PKI debe admitir claves RSA-2048 de bits y claves EC P-256. Por ejemplo, los servidores EST deben admitir estos tipos de claves. Puede usar otros tipos de claves, pero solo se prueban claves RSA-2048 bits y claves EC P-256.
Requisitos de permisos de
En la tabla siguiente se enumeran los permisos de archivo y directorio necesarios para los certificados de IoT Edge. El directorio preferido para los certificados es /var/aziot/certs/ y /var/aziot/secrets/ para las claves.
| Archivo o directorio | Permisos | Propietario |
|---|---|---|
Directorio de certificados /var/aziot/certs/ |
drwxr-xr-x (755) | aziotcs |
Archivos de certificado en /var/aziot/certs/ |
-wr-r--r-- (644) | aziotcs |
Directorio de claves /var/aziot/secrets/ |
drwx------ (700) | aziotks |
Archivos de clave en /var/aziot/secrets/ |
-wr------- (600) | aziotks |
Para crear los directorios, establezca los permisos y establezca el propietario y ejecute los siguientes comandos:
# If the certificate and keys directories don't exist, create, set ownership, and set permissions
sudo mkdir -p /var/aziot/certs
sudo chown aziotcs:aziotcs /var/aziot/certs
sudo chmod 755 /var/aziot/certs
sudo mkdir -p /var/aziot/secrets
sudo chown aziotks:aziotks /var/aziot/secrets
sudo chmod 700 /var/aziot/secrets
# Give aziotcs ownership to certificates
# Read and write for aziotcs, read-only for others
sudo chown -R aziotcs:aziotcs /var/aziot/certs
sudo find /var/aziot/certs -type f -name "*.*" -exec chmod 644 {} \;
# Give aziotks ownership to private keys
# Read and write for aziotks, no permission for others
sudo chown -R aziotks:aziotks /var/aziot/secrets
sudo find /var/aziot/secrets -type f -name "*.*" -exec chmod 600 {} \;
# Verify permissions of directories and files
sudo ls -Rla /var/aziot
La salida de la lista con la propiedad y el permiso correctos es similar a la siguiente salida:
azureUser@vm:/var/aziot$ sudo ls -Rla /var/aziot
/var/aziot:
total 16
drwxr-xr-x 4 root root 4096 Dec 14 00:16 .
drwxr-xr-x 15 root root 4096 Dec 14 00:15 ..
drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 certs
drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 secrets
/var/aziot/certs:
total 20
drwxr-xr-x 2 aziotcs aziotcs 4096 Jan 14 00:31 .
drwxr-xr-x 4 root root 4096 Dec 14 00:16 ..
-rw-r--r-- 1 aziotcs aziotcs 1984 Jan 14 00:24 azure-iot-test-only.root.ca.cert.pem
-rw-r--r-- 1 aziotcs aziotcs 5887 Jan 14 00:27 iot-edge-device-ca-devicename-full-chain.cert.pem
/var/aziot/secrets:
total 16
drwx------ 2 aziotks aziotks 4096 Jan 23 17:23 .
drwxr-xr-x 4 root root 4096 Dec 14 00:16 ..
-rw------- 1 aziotks aziotks 3243 Jan 14 00:28 iot-edge-device-ca-devicename.key.pem
Administración de la entidad de certificación raíz de confianza (agrupación de confianza)
El uso de un certificado de entidad de certificación (CA) autofirmado como raíz de confianza con IoT Edge y módulos se conoce como agrupación de confianza. El conjunto de confianza está disponible para que IoT Edge y los módulos se comuniquen con los servidores. Para configurar el conjunto de confianza, especifique su ruta de acceso de archivo en el archivo de configuración de IoT Edge.
Obtenga el certificado de ENTIDAD de certificación raíz de un proveedor PKI.
Compruebe que el certificado cumple los requisitos de formato.
Copie el archivo PEM y conceda acceso al servicio de certificados de IoT Edge. Por ejemplo, con el directorio
/var/aziot/certs:# Make the directory if doesn't exist sudo mkdir /var/aziot/certs -p # Change cert directory user and group ownership to aziotcs and set permissions sudo chown aziotcs:aziotcs /var/aziot/certs sudo chmod 755 /var/aziot/certs # Copy certificate into certs directory sudo cp root-ca.pem /var/aziot/certs # Give aziotcs ownership to certificate and set read and write permission for aziotcs, read-only for others sudo chown aziotcs:aziotcs /var/aziot/certs/root-ca.pem sudo chmod 644 /var/aziot/certs/root-ca.pemEn el archivo de configuración de IoT Edge
config.toml, busque la sección Certificado de agrupación de confianza. Si falta la sección, puede copiarla desde el archivo de plantilla de configuración.Sugerencia
Si el archivo de configuración todavía no existe en el dispositivo, use
/etc/aziot/config.toml.edge.templatecomo plantilla para crear uno.Establezca la clave
trust_bundle_certen la ubicación del archivo de certificado.trust_bundle_cert = "file:///var/aziot/certs/root-ca.pem"Aplique la configuración.
sudo iotedge config apply
Instalación de la entidad de certificación raíz en el almacén de certificados de sistema operativo
La instalación del certificado en el archivo de agrupación de confianza hace que esté disponible para los módulos de contenedor, pero no para módulos host como Azure Device Update o Defender. Si usa componentes de nivel de host o tiene otros problemas de TLS, instale también el certificado de entidad de certificación raíz en el almacén de certificados del sistema operativo:
sudo cp /var/aziot/certs/my-root-ca.pem /usr/local/share/ca-certificates/my-root-ca.pem.crt
sudo update-ca-certificates
Importe los archivos de clave privada y certificado
IoT Edge puede usar certificados existentes y archivos de clave privada para autenticar o atestiguar a Azure, emitir nuevos certificados de servidor de módulos y autenticarse en servidores EST. Para instalarlos:
Compruebe que los archivos de certificado y clave privada cumplen los requisitos de formato.
Copie el archivo PEM en el dispositivo IoT Edge al que los módulos de IoT Edge pueden acceder. Por ejemplo, el directorio
/var/aziot/.# If the certificate and keys directories don't exist, create, set ownership, and set permissions sudo mkdir -p /var/aziot/certs sudo chown aziotcs:aziotcs /var/aziot/certs sudo chmod 755 /var/aziot/certs sudo mkdir -p /var/aziot/secrets sudo chown aziotks:aziotks /var/aziot/secrets sudo chmod 700 /var/aziot/secrets # Copy certificate and private key into the correct directory sudo cp my-cert.pem /var/aziot/certs sudo cp my-private-key.pem /var/aziot/secretsConceda la propiedad al servicio de certificados
aziotcsde IoT Edge y el servicio de clavesaziotksal certificado y a la clave privada, respectivamente.# Give aziotcs ownership to certificate # Read and write for aziotcs, read-only for others sudo chown aziotcs:aziotcs /var/aziot/certs/my-cert.pem sudo chmod 644 /var/aziot/certs/my-cert.pem # Give aziotks ownership to private key # Read and write for aziotks, no permission for others sudo chown aziotks:aziotks /var/aziot/secrets/my-private-key.pem sudo chmod 600 /var/aziot/secrets/my-private-key.pemEn
config.toml, busque la sección pertinente para el tipo de certificado que se va a configurar. Por ejemplo, puede buscar la palabra clavecert.Con el ejemplo de la plantilla de configuración, configure el certificado de identidad del dispositivo o los archivos de entidad de certificación perimetral. El patrón de ejemplo es:
cert = "file:///var/aziot/certs/my-cert.pem" pk = "file:///var/aziot/secrets/my-private-key.pem"Aplicación de la configuración
sudo iotedge config apply
Para evitar errores cuando expiren los certificados, recuerde actualizar manualmente los archivos y la configuración antes de la expiración del certificado.
Ejemplo: uso de archivos de certificado de identidad de dispositivo del proveedor de PKI
Solicite un certificado de cliente de TLS y una clave privada del proveedor de PKI.
Requisitos de certificado de identidad de dispositivo:
- Extensiones de certificado de cliente estándar: extendedKeyUsage = clientAuth keyUsage = critical, digitalSignature
- Identificadores clave para ayudar a distinguir entre las CA emisoras con el mismo CN para la rotación de certificados de ENTIDAD de certificación.
- subjectKeyIdentifier = hash
- authorityKeyIdentifier = keyid:always,issuer:always
Asegúrese de que el nombre común (CN) coincide con el identificador de dispositivo de IoT Edge registrado con IoT Hub o el identificador de registro con DPS. Por ejemplo, en el siguiente certificado de identidad de dispositivo, Subject: CN = my-device es el campo importante que debe coincidir.
Certificado de identidad de dispositivo de ejemplo:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 48 (0x30)
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN = myPkiCA
Validity
Not Before: Jun 28 21:27:30 2022 GMT
Not After : Jul 28 21:27:30 2022 GMT
Subject: CN = my-device
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:ad:b0:63:1f:48:19:9e:c4:9d:91:d1:b0:b0:e5:
...
80:58:63:6d:ab:56:9f:90:4e:3f:dd:df:74:cf:86:
04:af
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage:
Digital Signature
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Subject Key Identifier:
C7:C2:DC:3C:53:71:B8:42:15:D5:6C:4B:5C:03:C2:2A:C5:98:82:7E
X509v3 Authority Key Identifier:
keyid:6E:57:C7:FC:FE:50:09:75:FA:D9:89:13:CB:D2:CA:F2:28:EF:9B:F6
Signature Algorithm: ecdsa-with-SHA256
30:45:02:20:3c:d2:db:06:3c:d7:65:b7:22:fe:df:9e:11:5b:
...
eb:da:fc:f1:6a:bf:31:63:db:5a:16:02:70:0f:cf:c8:e2
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----
Sugerencia
Si quiere probar sin acceso a los archivos de certificado proporcionados por una PKI, consulte Creación de certificados de demostración para probar las características del dispositivo para generar un certificado de identidad de dispositivo de corta duración y una clave privada.
Ejemplo de configuración al aprovisionar con IoT Hub:
[provisioning]
source = "manual"
# ...
[provisioning.authentication]
method = "x509"
identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"
Ejemplo de configuración al aprovisionar con DPS:
[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"
identity_cert = "file:///var/aziot/device-id.pem"
identity_pk = "file:///var/aziot/device-id.key.pem"
La sobrecarga con la administración manual de certificados puede ser arriesgada y propensa a errores. Para producción, se recomienda usar IoT Edge con la administración automática de certificados.
Administrar de CA perimetral
La CA perimetral tiene dos modos diferentes:
- Inicio rápido es el comportamiento predeterminado. El Inicio rápido es para pruebas y no es adecuado para producción.
- El modo de producción requiere que proporcione su propio origen para el certificado de la CA perimetral y la clave privada.
CA perimetral de Inicio rápido
Para ayudarle a empezar, IoT Edge genera automáticamente un certificado de CA perimetral cuando se inicia por primera vez de forma predeterminada. Este certificado autofirmado está concebido únicamente para escenarios de desarrollo y pruebas, no para producción. De forma predeterminada, el certificado expira después de 90 días. La expiración se puede configurar. Este comportamiento se conoce como CA perimetral de inicio rápido.
La CA perimetral de Inicio rápido permite a edgeHub y otros módulos de IoT Edge tener un certificado de servidor válido cuando IoT Edge se instala por primera vez sin ninguna configuración. El certificado es necesario para edgeHub porque los módulos o los dispositivos de nivel inferior necesitan establecer canales de comunicación seguros. Sin la CA perimetral de inicio rápido, los primeros pasos serían significativamente más difíciles porque tendría que proporcionar un certificado de servidor válido desde un proveedor de PKI o con herramientas como openssl.
Importante
Nunca use la CA perimetral de inicio rápido para producción porque el certificado generado localmente en ella no está conectado a una PKI.
La seguridad de una identidad basada en certificados se deriva de una PKI (la infraestructura) bien operada en la que el certificado (un documento) es solo un componente. Una PKI bien operada permite definir, aplicar, administrar y aplicar directivas de seguridad para incluir, entre otros, la emisión de certificados, la revocación y la administración del ciclo de vida.
Personalización de la duración de la CA perimetral de inicio rápido
Para configurar la expiración del certificado en un valor distinto a los 90 días predeterminados, agregue el valor en días a la sección Certificado de CA de Edge (inicio rápido) del archivo de configuración.
[edge_ca]
auto_generated_edge_ca_expiry_days = 180
Elimine el contenido de las carpetas /var/lib/aziot/certd/certs y /var/lib/aziot/keyd/keys para quitar los certificados generados previamente y, después, aplique la configuración.
Renovación del CA de Edge de inicio rápido
De forma predeterminada, IoT Edge renueva automáticamente el certificado de CA perimetral al 80 % de la duración del certificado. Por lo tanto, para un certificado con una duración de 90 días, IoT Edge regenera automáticamente el certificado de CA perimetral a los 72 días a partir de la emisión.
Para cambiar la lógica de renovación automática, agregue la siguiente configuración a la sección Certificado de CA perimetral en config.toml. Por ejemplo:
[edge_ca.auto_renew]
rotate_key = true
threshold = "70%"
retry = "2%"
CA perimetral en producción
Una vez que pase a un escenario de producción o quiera crear un dispositivo de puerta de enlace, ya no podrá usar la CA perimetral de inicio rápido.
Una opción es proporcionar sus propios certificados y administrarlos manualmente. Sin embargo, para evitar el proceso de administración manual de certificados, que es peligroso y propenso a errores, use un servidor EST siempre que sea posible.
Precaución
El nombre común (CN) del certificado de entidad de certificación perimetral no puede coincidir con el parámetro nombre de host del dispositivo definido en el archivo de configuración del dispositivo config.toml o el identificador de dispositivo registrado en IoT Hub.
Planeación de la renovación de CA perimetral
Cuando se renueva el certificado de CA perimetral, se vuelven a generar todos los certificados que emitió, como los certificados de servidor de módulos. Para proporcionar a los módulos nuevos certificados de servidor, IoT Edge reinicia todos los módulos cuando se renueva el certificado de CA perimetral.
Para minimizar los posibles efectos negativos de los reinicios del módulo, planee renovar el certificado de CA perimetral en un momento específico (por ejemplo, threshold = "10d") y notificar a los dependientes de la solución sobre el tiempo de inactividad.
Ejemplo: uso de archivos de certificado de CA perimetral del proveedor de PKI
Solicite los siguientes archivos del proveedor de PKI:
- El certificado de CA raíz de la PKI
- Un certificado de CA o emisión y una clave privada asociada
Para que el certificado de CA emisor se convierta en CA perimetral, debe tener estas extensiones:
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always
basicConstraints = critical, CA:TRUE, pathlen:0
keyUsage = critical, digitalSignature, keyCertSign
Ejemplo del certificado de CA perimetral resultante:
openssl x509 -in my-edge-ca-cert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 4098 (0x1002)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = myPkiCA
Validity
Not Before: Aug 27 00:00:50 2022 GMT
Not After : Sep 26 00:00:50 2022 GMT
Subject: CN = my-edge-ca.ca
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (4096 bit)
Modulus:
00:e1:cb:9c:c0:41:d2:ee:5d:8b:92:f9:4e:0d:3e:
...
25:f5:58:1e:8c:66:ab:d1:56:78:a5:9c:96:eb:01:
e4:e3:49
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
FD:64:48:BB:41:CE:C1:8A:8A:50:9B:2B:2D:6E:1D:E5:3F:86:7D:3E
X509v3 Authority Key Identifier:
keyid:9F:E6:D3:26:EE:2F:D7:84:09:63:84:C8:93:72:D5:13:06:8E:7F:D1
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Key Usage: critical
Digital Signature, Certificate Sign
Signature Algorithm: sha256WithRSAEncryption
20:c9:34:41:a3:a4:8e:7c:9c:6e:17:f5:a6:6f:e5:fc:6e:59:
...
7c:20:5d:e5:51:85:4c:4d:f7:f8:01:84:87:27:e3:76:65:47:
9e:6a:c3:2e:1a:f0:dc:9d
-----BEGIN CERTIFICATE-----
MIICdTCCAhugAwIBAgIBMDAKBggqhkjOPQQDAjAXMRUwEwYDVQQDDAxlc3RFeGFt
...
354RWw+eLOpQSkTqXxzjmfw/kVOOAQIhANvRmyCQVb8zLPtqdOVRkuva/PFqvzFj
21oWAnAPz8ji
-----END CERTIFICATE-----
Una vez que reciba los archivos más recientes, actualice la agrupación de confianza:
trust_bundle_cert = "file:///var/aziot/root-ca.pem"
Después, configure IoT Edge para usar los archivos de certificado y clave privada:
[edge_ca]
cert = "file:///var/aziot/my-edge-ca-cert.pem"
pk = "file:///var/aziot/my-edge-ca-private-key.key.pem"
Si ha usado antes otros certificados para IoT Edge en el dispositivo, elimine los archivos de /var/lib/aziot/certd/certs y las claves privadas asociadas a certificados (no todas las claves) en /var/lib/aziot/keyd/keys. IoT Edge los vuelve a crear con el nuevo certificado de CA que ha proporcionado.
Este enfoque requiere que actualice manualmente los archivos a medida que expire el certificado. Para evitar este problema, considere la posibilidad de usar EST para la administración automática.
Administración automática de certificados con servidor EST
IoT Edge puede interactuar con un servidor de Inscripción a través de transporte seguro (EST) para la emisión y renovación automáticas de certificados. Se recomienda usar EST para producción, ya que reemplaza la necesidad de administración manual de certificados, lo que puede ser arriesgado y propenso a errores. Se puede configurar globalmente y invalidar para cada tipo de certificado.
En este escenario, se espera que el certificado de arranque y la clave privada sean de larga duración y potencialmente instalados en el dispositivo durante la fabricación. IoT Edge usa las credenciales de arranque para autenticarse en el servidor EST para que la solicitud inicial emita un certificado de identidad para las solicitudes posteriores y para la autenticación en Microsoft System Center Data Protection Manager o IoT Hub.
Obtenga acceso a un servidor EST. Si no tiene un servidor EST, use una de las siguientes opciones para iniciar las pruebas:
Cree un servidor EST de prueba siguiendo los pasos descritos en Tutorial: Configuración de la Inscripción a través de servidor de transporte seguro para Azure IoT Edge.
Microsoft se asocia con GlobalSign para proporcionar una cuenta de demostración.
En el archivo de configuración del dispositivo de IoT Edge
config.toml, configure la ruta de acceso a un certificado raíz de confianza que IoT Edge usa para validar el certificado TLS del servidor EST. Este paso es opcional si el servidor EST tiene un certificado de TLS raíz de confianza pública.[cert_issuance.est] trusted_certs = [ "file:///var/aziot/root-ca.pem", ]Proporcione una dirección URL predeterminada para el servidor EST. En
config.toml, agregue la siguiente sección con la dirección URL del servidor EST:[cert_issuance.est.urls] default = "https://example.org/.well-known/est"Para configurar el certificado EST para la autenticación, agregue la siguiente sección con la ruta de acceso al certificado y la clave privada:
[cert_issuance.est.auth] bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem" bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem" [cert_issuance.est.identity_auto_renew] rotate_key = true threshold = "80%" retry = "4%"Aplique los cambios de configuración.
sudo iotedge config apply
La configuración de [cert_issuance.est.identity_auto_renew] se trata en la sección siguiente.
Autenticación mediante nombre de usuario y contraseña
Si la autenticación en el servidor EST mediante el certificado no es posible, puede usar un secreto compartido o un nombre de usuario y una contraseña en su lugar.
[cert_issuance.est.auth]
username = "username"
password = "password"
Configuración de parámetros de renovación automática
En lugar de administrar manualmente los archivos de certificado, IoT Edge tiene la capacidad integrada de obtener y renovar certificados antes de la expiración. La renovación de certificados requiere un método de emisión que IoT Edge pueda administrar. La Inscripción a través de servidor de transporte seguro (EST) es un método de emisión, pero IoT Edge también puede renovar automáticamente la CA de inicio rápido de forma predeterminada. La renovación de certificados se configura por tipo de certificado.
En
config.toml, busque la sección pertinente para el tipo de certificado que se va a configurar. Por ejemplo, puede buscar la palabra claveauto_renew.Con el ejemplo de la plantilla de configuración, configure el certificado de identidad del dispositivo, la CA perimetral o los certificados de identidad de EST. El patrón de ejemplo es:
[REPLACE_WITH_CERT_TYPE] # ... method = "est" # ... [REPLACE_WITH_CERT_TYPE.auto_renew] rotate_key = true threshold = "80%" retry = "4%"Aplicación de la configuración
sudo iotege config apply
En la tabla siguiente se muestra lo que hace cada opción en auto_renew:
| Parámetro | Descripción |
|---|---|
rotate_key |
Controla si se debe rotar la clave privada cuando IoT Edge renueva el certificado. |
threshold |
Establece cuándo IoT Edge debe empezar a renovar el certificado. Se puede especificar como: - Porcentaje: entero entre 0 y 100 seguido de %. La renovación se inicia en relación con la duración del certificado. Por ejemplo, cuando se establece en 80%, un certificado válido durante 100 días comienza la renovación a los 20 días antes de su expiración. - Tiempo absoluto: entero seguido de min (minutos) o day (días). La renovación se inicia en relación con el tiempo de expiración del certificado. Por ejemplo, cuando se establece en 4day durante cuatro días o 10min durante 10 minutos, el certificado comienza a renovarse en ese momento antes de la expiración. Para evitar una configuración incorrecta involuntaria en la que threshold sea mayor que la duración del certificado, se recomienda usar porcentaje en su lugar siempre que sea posible. |
retry |
controla la frecuencia con la que se debe reintentar la renovación en caso de error. Al igual que threshold, se puede especificar de forma similar como un porcentaje o un tiempo absoluto con el mismo formato. |
Ejemplo: renovación automática del certificado de identidad de dispositivo con EST
Para usar IoT Edge y EST para la emisión y renovación automáticas de certificados de identidad de dispositivo, que se recomienda para producción, IoT Edge deben aprovisionarse como parte de un grupo de inscripción basado en CA de DPS. Por ejemplo:
## DPS provisioning with X.509 certificate
[provisioning]
source = "dps"
# ...
[provisioning.attestation]
method = "x509"
registration_id = "my-device"
[provisioning.attestation.identity_cert]
method = "est"
common_name = "my-device"
[provisioning.attestation.identity_cert.auto_renew]
rotate_key = true
threshold = "80%"
retry = "4%"
La renovación automática para Edge CA debe estar habilitada cuando el método de emisión está establecido en EST. Se debe evitar la expiración de Edge CA, ya que interrumpe muchas funcionalidades de IoT Edge. Si una situación requiere un control total sobre el ciclo de vida de los certificados de CA perimetral, use el método manual de administración de CA perimetral en su lugar.
No use EST ni auto_renew con otros métodos de aprovisionamiento, incluido el aprovisionamiento manual de X.509 con IoT Hub y DPS con inscripción individual. IoT Edge no puede actualizar las huellas digitales de certificado en Azure cuando se renueva un certificado, lo que impide que IoT Edge se vuelva a conectar.
Ejemplo: administración automática de CA perimetrales con EST
Use la emisión y renovación automáticas de la CA perimetral de EST para producción. Una vez configurado el servidor EST, puede usar la configuración global o invalidarlo de forma similar a este ejemplo:
[edge_ca]
method = "est"
common_name = "my-edge-CA"
url = "https://ca.example.org/.well-known/est"
bootstrap_identity_cert = "file:///var/aziot/my-est-id-bootstrap-cert.pem"
bootstrap_identity_pk = "file:///var/aziot/my-est-id-bootstrap-pk.key.pem"
[edge_ca.auto_renew]
rotate_key = true
threshold = "90%"
retry = "2%"
Certificados de servidor de módulos
El demonio de Edge emite certificados de identidad y servidor de módulos para que los usen los módulos de Edge. Sigue siendo responsabilidad de los módulos perimetrales renovar sus certificados de identidad y servidor según sea necesario.
Renovación
Es posible que los certificados de servidor se emita fuera del certificado de Edge CA. Independientemente del método de emisión, el módulo debe renovar estos certificados. Si desarrolla un módulo personalizado, debe implementar la lógica de renovación en el módulo.
El módulo edgeHub admite una característica de renovación de certificados. Puede configurar la renovación del certificado del servidor del módulo edgeHub utilizando las siguientes variables de entorno:
- ServerCertificateRenewAfterInMs: establece la duración en milisegundos cuando se renueva el certificado de servidor edgeHub independientemente del tiempo de expiración del certificado.
- MaxCheckCertExpiryInMs: establece la duración en milisegundos cuando el servicio edgeHub verifica la caducidad del certificado del servidor edgeHub. Si se establece la variable, la comprobación se produce independientemente del tiempo de expiración del certificado.
Para obtener más información sobre las variables de entorno, consulte las variables de entorno EdgeHub y EdgeAgent.
Cambios en la versión 1.2 y posteriores
- Se ha cambiado el nombre del certificado de CA del dispositivo por certificado de CA perimetral.
- El certificado de CA de carga de trabajo está en desuso. Ahora el administrador de seguridad de IoT Edge genera el certificado de servidor del centro de IoT Edge
edgeHubdirectamente desde el certificado de CA perimetral, sin el certificado de CA de carga de trabajo intermedio entre ellos. - El archivo de configuración predeterminado tiene un nuevo nombre y ubicación, de
/etc/iotedge/config.yamla/etc/aziot/config.tomlde forma predeterminada. El comandoiotedge config importse puede usar para ayudar a migrar la información de configuración de la ubicación y la sintaxis anteriores a las nuevas.
Pasos siguientes
La instalación de certificados en un dispositivo IoT Edge es un paso necesario antes de implementar la solución en producción. Obtenga más información sobre cómo preparar la implementación de la solución de IoT Edge en producción.