Información sobre los certificados de Azure 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 el ciclo de vida el 12 de noviembre de 2024. Si está usando una versión anterior, consulte Actualización de IoT Edge.

IoT Edge usa diferentes tipos de certificados para diferentes propósitos. En este artículo se describen las distintas formas en que IoT Edge usa certificados con escenarios de puerta de enlace de Azure IoT Hub e IoT Edge.

Importante

Por ser más conciso, este artículo se aplica a IoT Edge versión 1.2 o posterior. Los conceptos de certificado de la versión 1.1 son similares, pero hay algunas diferencias:

• Se cambió el nombre del certificado de CA de dispositivo en la versión 1.1 al certificado de CA de Edge.
• El certificado de CA de la carga de trabajo de la versión 1.1 se retiró. En la versión 1.2 o posterior, el entorno de ejecución del módulo IoT Edge genera todos los certificados de servidor directamente desde el certificado de CA perimetral, sin el certificado de CA de carga de trabajo intermedio entre ellos en la cadena de certificados.

Resumen

Estos escenarios principales son en los que IoT Edge usa certificados. Use los vínculos para obtener más información sobre cada escenario.

Actor	Fin	Certificate
IoT Edge	Garantiza que se comunica con la instancia de IoT Hub correcta	Certificado de servidor de IoT Hub
IoT Hub	Garantiza que la solicitud procede de un dispositivo IoT Edge legítimo	Certificado de identidad de IoT Edge
Dispositivo IoT de bajada	Garantiza que se está comunicando a la puerta de enlace de IoT Edge correcta	Certificado de servidor del módulo edgeHub del centro de IoT Edge emitido por Edge CA
IoT Edge	Firma nuevos certificados de servidor de módulos. Por ejemplo, edgeHub	Certificado de CA perimetral
IoT Edge	Garantiza que la solicitud procede de un dispositivo de bajada legítimo	Certificado de identidad de dispositivo IoT

Requisitos previos

• Debe tener un conocimiento básico de criptografía de clave pública, los pares de claves y cómo una clave pública y una clave privada pueden cifrar o descifrar datos. Para obtener más información sobre cómo IoT Edge usa la criptografía de clave pública, consulte Descripción de la criptografía de clave pública y la infraestructura de clave pública X.509.
• Debe tener conocimientos básicos sobre cómo se relaciona IoT Edge con IoT Hub. Para obtener más información, consulte Información del entorno de ejecución de Azure IoT Edge y su arquitectura.

Escenario de dispositivo único

Para ayudar a comprender los conceptos de certificado de IoT Edge, imagine un escenario en el que un dispositivo IoT Edge denominado EdgeGateway se conecta a una instancia de Azure IoT Hub denominada ContosoIotHub. En este ejemplo, toda la autenticación se realiza con autenticación de certificados X.509 en lugar de claves simétricas. Para establecer la confianza en este escenario, es necesario garantizar que IoT Hub y el dispositivo IoT Edge son auténticos: "¿Es este dispositivo auténtico y válido?" y "¿Es la identidad de IoT Hub correcta?". El escenario se puede ilustrar de la siguiente manera:

Explicaremos las respuestas a cada pregunta y, a continuación, expandiremos el ejemplo en secciones posteriores del artículo.

El dispositivo comprueba la identidad de IoT Hub

¿Cómo comprueba EdgeGateway que se está comunicando con el punto de conexión ContosoIotHub auténtico? Cuando EdgeGateway quiere comunicarse con la nube, se conecta al punto de conexión ContosoIoTHub.Azure-devices.NET. Para asegurarse de que el punto de conexión es auténtico, IoT Edge necesita que ContosoIoTHub muestre la identificación (ID). El identificador debe ser emitido por una autoridad en la que EdgeGateway confíe. Para comprobar la identidad de IoT Hub, IoT Edge e IoT Hub usan el protocolo de enlace TLS para comprobar la identidad del servidor de IoT Hub. Un protocolo de enlace TLS se ilustra en el diagrama siguiente. Para simplificar el ejemplo, se han omitido algunos detalles. Para obtener más información sobre el protocolo de enlace TLS, consulte Protocolo de enlace TLS en Wikipedia.

Nota:

En este ejemplo, ContosoIoTHub representa el nombre de host de IoT Hub ContosoIotHub.Azure-devices.NET.

En este contexto, no es necesario conocer los detalles exactos del algoritmo criptográfico. Es importante comprender que el algoritmo garantiza que el servidor posee la clave privada emparejada con su clave pública. Comprueba que el presentador del certificado no lo ha copiado ni robado. Si usamos un identificador de foto como ejemplo, la cara coincide con la foto en el identificador. Si alguien roba su identificador, no puede usarlo para la identificación porque su cara es única y difícil de reproducir. Para las claves criptográficas, el par de claves está relacionado y es único. En lugar de hacer coincidir una cara con un identificador de foto, el algoritmo criptográfico usa el par de claves para comprobar la identidad.

En nuestro escenario, ContosoIotHub muestra la siguiente cadena de certificados:

La entidad de certificación raíz (CA) es el certificado Baltimore CyberTrust Root. DigiCert firma este certificado raíz y es considerado ampliamente como de confianza y se almacena en muchos sistemas operativos. Por ejemplo, Ubuntu y Windows lo incluyen en el almacén de certificados predeterminado.

Almacén de certificados de Windows:

Almacén de certificados de Ubuntu:

Cuando un dispositivo comprueba el certificado Baltimore CyberTrust Root, está preinstalado en el sistema operativo. Desde la perspectiva de EdgeGateway, como la cadena de certificados que presenta ContosoIotHub está firmada por una entidad de certificación raíz en la que confía el sistema operativo, el certificado se considera de confianza. El certificado se conoce como certificado de servidor de IoT Hub. Para obtener más información sobre el certificado de servidor de IoT Hub, consulte Compatibilidad de la Seguridad de la capa de transporte (TLS) con IoT Hub.

En resumen, EdgeGateway puede comprobar y confiar en la identidad de ContosoIotHub porque:

• ContosoIotHub presenta su certificado de servidor de IoT Hub
• El certificado de servidor es de confianza en el almacén de certificados del sistema operativo
• ContosoIotHub puede descifrar los datos cifrados con la clave pública de ContosoIotHub, lo que demuestra su posesión de la clave privada

IoT Hub comprueba la identidad del dispositivo de IoT Edge

¿Cómo comprueba ContosoIotHub que se está comunicando con EdgeGateway? Dado que IoT Hub admite TLS mutua (mTLS), comprueba el certificado de EdgeGateway durante el protocolo de enlace TLS autenticado por el cliente. Para simplificar, omitiremos algunos pasos en el diagrama siguiente.

En este caso, EdgeGateway proporciona su certificado de identidad de dispositivo de IoT Edge. Desde la perspectiva de ContosoIotHub, comprueba que la huella digital del certificado proporcionado coincide con su registro y EdgeGateway tiene la clave privada emparejada con el certificado que presentó. Al aprovisionar un dispositivo IoT Edge en IoT Hub, proporciona una huella digital. La huella digital es lo que IoT Hub usa para comprobar el certificado.

Sugerencia

IoT Hub requiere dos huellas digitales al registrar un dispositivo IoT Edge. Como procedimiento recomendado, prepare dos certificados de identidad del dispositivo diferentes con fechas de expiración diferentes. De este modo, si un certificado expira, el otro sigue siendo válido y le da tiempo para rotar el certificado expirado. Sin embargo, también es posible usar solo un certificado para el registro. Use un único certificado estableciendo la misma huella digital de certificado para las huellas digitales principal y secundaria al registrar el dispositivo.

Por ejemplo, podemos usar el siguiente comando para obtener la huella digital del certificado de identidad en EdgeGateway:

sudo openssl x509 -in /var/lib/aziot/certd/certs/deviceid-random.cer -noout -nocert -fingerprint -sha256

El comando genera la huella digital SHA256 del certificado:

SHA256 Fingerprint=1E:F3:1F:88:24:74:2C:4A:C1:A7:FA:EC:5D:16:C4:11:CD:85:52:D0:88:3E:39:CB:7F:17:53:40:9C:02:95:C3

Si vemos el valor de huella digital SHA256 del dispositivo EdgeGateway registrado en IoT Hub, podemos ver que coincide con la huella digital en EdgeGateway:

En resumen, ContosoIotHub puede confiar en EdgeGateway porque EdgeGateway presenta un certificado de identidad de dispositivo IoT Edge válido cuya huella digital coincide con la registrada en IoT Hub.

Para obtener más información sobre el proceso de creación de certificados, consulte Creación y aprovisionamiento de un dispositivo IoT Edge en Linux mediante certificados X.509.

Nota:

En este ejemplo no se aborda Azure IoT Hub Device Provisioning Service (DPS), que tiene compatibilidad con la autenticación de entidad de certificación X.509 con IoT Edge cuando se aprovisiona con un grupo de inscripción. Con DPS, se carga el certificado de entidad de certificación o un certificado intermedio, se comprueba la cadena de certificados y, a continuación, se aprovisiona el dispositivo. Para obtener más información, consulte Atestación de certificados X.509 de DPS.

En Azure Portal, DPS muestra la huella digital SHA1 del certificado en lugar de la huella digital SHA256.

DPS registra o actualiza la huella digital SHA256 para IoT Hub. Puede comprobar la huella digital mediante el comando openssl x509 -in /var/lib/aziot/certd/certs/deviceid-long-random-string.cer -noout -fingerprint -sha256. Una vez registrada, Iot Edge usa la autenticación de huella digital con IoT Hub. Si se vuelve a aprovisionar el dispositivo y se emite un nuevo certificado, DPS actualiza IoT Hub con la nueva huella digital.

IoT Hub actualmente no admite la autenticación de entidad de certificación X.509 directamente con IoT Edge.

Uso de certificados para las operaciones de identidad de módulo

En los diagramas de comprobación de certificados, podría parecer que IoT Edge solo usa el certificado para comunicarse con IoT Hub. IoT Edge consta de varios módulos. Como resultado, IoT Edge usa el certificado para administrar identidades de módulo para módulos que envían mensajes. Los módulos no usan el certificado para autenticarse en IoT Hub, sino que usan claves SAS derivadas de la clave privada generada por el runtime del módulo de IoT Edge. Estas claves SAS no cambian aunque expire el certificado de identidad del dispositivo. Si el certificado expira, edgeHub, por ejemplo, continúa ejecutándose y solo se produce un error en las operaciones de identidad del módulo.

La interacción entre módulos e IoT Hub es segura porque la clave SAS se deriva de un secreto e IoT Edge administra la clave sin el riesgo de intervención humana.

Escenario de jerarquía de dispositivos anidados con IoT Edge como puerta de enlace

Ahora tiene una buena comprensión de una interacción sencilla entre IoT Edge e IoT Hub. Sin embargo, IoT Edge también puede actuar como puerta de enlace para dispositivos de nivel inferior u otros dispositivos IoT Edge. Estos canales de comunicación también deben cifrarse y ser de confianza. Debido a la complejidad adicional, tenemos que expandir nuestro escenario de ejemplo para incluir un dispositivo de bajada.

Agregamos un dispositivo IoT normal denominado TempSensor, que se conecta a su dispositivo primario IoT Edge EdgeGateway que se conecta a ContosoIotHub de IoT Hub. De forma similar a antes, toda la autenticación se realiza con la autenticación de certificados X.509. Nuestro nuevo escenario plantea dos preguntas nuevas: "¿Es legítimo el dispositivo TempSensor?" y "¿La identidad de EdgeGateway es correcta?". El escenario se puede ilustrar de la siguiente manera:

Sugerencia

TempSensor es un dispositivo IoT en el escenario. El concepto de certificado es el mismo si TempSensor es un dispositivo de bajada IoT Edge del EdgeGateway primario.

El dispositivo comprueba la identidad de la puerta de enlace

¿Cómo comprueba TempSensor que se está comunicando con el EdgeGateway original? Cuando TempSensor quiere hablar con EdgeGateway, TempSensor necesita que EdgeGateway muestre un identificador. El identificador debe ser emitido por una autoridad en la que TempSensor confíe.

El flujo es el mismo que cuando EdgeGateway se comunica con ContosoIotHub. TempSensor y EdgeGateway usan el protocolo de enlace TLS para comprobar la identidad de EdgeGateway. Hay dos detalles importantes:

• Especificidad del nombre de host: el certificado presentado por EdgeGateway debe emitirse al mismo nombre de host (dominio o dirección IP) que TempSensor usa para conectarse a EdgeGateway.
• Especificidad de CA raíz autofirmada: es probable que la cadena de certificados presentada por EdgeGateway no esté en el almacén raíz de confianza predeterminado del sistema operativo.

Para comprender los detalles, examinemos primero la cadena de certificados presentada por EdgeGateway.

Especificidad del nombre de host

El nombre común del certificado CN = edgegateway.local aparece en la parte superior de la cadena. edgegateway.local es el nombre común del certificado de servidor edgeHub. edgegateway.local también es el nombre de host de EdgeGateway en la red local (LAN o VNet) donde se conectan TempSensor y EdgeGateway. Podría ser una dirección IP privada, como 192.168.1.23 o un nombre de dominio completo (FQDN), como el diagrama. El certificado de servidor edgeHub se genera mediante el parámetro nombre de host definido en el archivo config.toml de IoT Edge. No confunda el certificado del servidor edgeHub con el certificado Edge CA. Para obtener más información sobre cómo administrar el certificado de entidad de certificación de Edge, consulte Administración de certificados de IoT Edge.

Cuando TempSensor se conecta a EdgeGateway, TempSensor usa el nombre de host edgegateway.local para conectarse a EdgeGateway. TempSensor comprueba el certificado presentado por EdgeGateway y comprueba que el nombre común del certificado es edgegateway.local. Si el nombre común del certificado es diferente, TempSensor rechaza la conexión.

Nota:

Para simplificar, en el ejemplo se muestra el nombre común del certificado del firmante (CN) como una propiedad que se valida. En la práctica, si un certificado tiene un nombre alternativo de firmante (SAN), SAN se valida en lugar de CN. Por lo general, dado que SAN puede contener varios valores, tiene el nombre de host o dominio principal para el titular del certificado, así como cualquier dominio alternativo.

¿Por qué es necesario informar a EdgeGateway sobre su propio nombre de host?

EdgeGateway no tiene una manera confiable de saber cómo otros clientes de la red pueden conectarse a él. Por ejemplo, en una red privada, podría haber servidores DHCP o servicios mDNS que muestran EdgeGateway como 10.0.0.2 o example-mdns-hostname.local. Sin embargo, algunas redes podrían tener servidores DNS que asignan edgegateway.local a la dirección IP 10.0.0.2 de EdgeGateway.

Para resolver el problema, IoT Edge usa el valor de nombre de host configurado en config.toml y crea un certificado de servidor para ello. Cuando se trata de una solicitud al módulo edgeHub, presenta el certificado con el nombre común del certificado (CN) correcto.

¿Por qué IoT Edge crea certificados?

En el ejemplo, observe que hay una instancia de iotedged workload ca edgegateway en la cadena de certificados. Es la entidad de certificación (CA) que existe en el dispositivo IoT Edge conocido como CA perimetral (anteriormente conocida como CA de dispositivo en la versión 1.1). Al igual que la CA Baltimore CyberTrust Root en el ejemplo anterior, la CA perimetral puede emitir otros certificados. Lo más importante, y también en este ejemplo, es que emite el certificado de servidor al módulo edgeHub. Sin embargo, también puede emitir certificados a otros módulos que se ejecutan en el dispositivo IoT Edge.

Importante

De forma predeterminada sin configuración, CA perimetral se genera automáticamente mediante el runtime del módulo IoT Edge cuando se inicia por primera vez, lo que se conoce como CA perimetral de inicio rápido y, a continuación, emite un certificado al módulo edgeHub. Este proceso acelera la conexión del dispositivo de bajada al permitir que EdgeHub presente un certificado válido firmado. Sin esta característica, tendría que conseguir que la entidad de certificación emita un certificado para el módulo edgeHub. No se admite el uso de una CA perimetral de inicio rápido generada automáticamente para su uso en producción. Para obtener más información sobre la CA perimetral de inicio rápido, consulte CA perimetral de Inicio rápido.

¿No es peligroso tener un certificado de emisor en el dispositivo?

La CA perimetral está diseñada para habilitar soluciones con conectividad limitada, poco confiable, costosa o ausente, pero al mismo tiempo tiene estrictas regulaciones o directivas sobre las renovaciones de certificados. Sin la CA perimetral, IoT Edge y, en particular edgeHub, no pueden funcionar.

Para proteger la CA perimetral en producción:

• Coloque la clave privada de CA perimetral en un módulo de plataforma segura (TPM), preferiblemente de forma que la clave privada se genere efímeramente y nunca deje el TPM.
• Use una infraestructura de clave pública (PKI) en la que se acumule la CA perimetral. Esto proporciona la capacidad de deshabilitar o rechazar la renovación de certificados en peligro. La PKI se puede administrar mediante TI del cliente si tiene el conocimiento de cómo (menor costo) o a través de un proveedor de PKI comercial.

Especificad de CA raíz autofirmado

El módulo edgeHub es un componente importante que constituye IoT Edge controlando todo el tráfico entrante. En este ejemplo, usa un certificado emitido por la CA perimetral, que, a su vez, lo emite una entidad de certificación raíz autofirmada. Dado que la entidad de certificación raíz no es de confianza para el sistema operativo, la única manera para que TempSensor confíe en ella es instalar el certificado CA en el dispositivo. Esto también se conoce como escenario de agrupación de confianza, donde debe distribuir la raíz a los clientes que necesitan confiar en la cadena. El escenario de agrupación de confianza puede ser problemático porque necesita acceder al dispositivo e instalar el certificado. La instalación del certificado requiere planificación. Se puede hacer con scripts, agregados durante la fabricación o preinstalados en la imagen del sistema operativo.

Nota:

Algunos clientes y SDK no usan el almacén raíz de confianza del sistema operativo y debe pasar el archivo de CA raíz directamente.

Al aplicar todos estos conceptos, TempSensor puede comprobar que se está comunicando con el edgeGateway original porque presentó un certificado que coincide con la dirección y el certificado está firmado por una raíz de confianza.

Para comprobar la cadena de certificados, puede usar openssl en el dispositivo TempSensor. En este ejemplo, observe que el nombre de host de la conexión coincide con el CN del certificado de profundidad 0 y que la entidad de certificación raíz coincide.

openssl s_client -connect edgegateway.local:8883 --CAfile my_private_root_CA.pem

depth=3 CN = my_private_root_CA
verify return:1
depth=2 CN = my_optional_intermediate_CA
verify return:1
depth=1 CN = iotedged workload ca edgegateway
verify return:1
depth=0 CN = edgegateway.local
verify return: 1
CONNECTED(00000003)
---
Certificate chain
0 s:/CN=edgegateway.local
  i:/CN=iotedged workload ca edgegateway
1 s:/CN=iotedged workload ca edgegateway
  i:/CN=my_optional_intermediate_CA
2 s:/CN=my_optional_intermediate_CA
  i:/CN=my_private_root_CA

Para obtener más información sobre el comando openssl, consulte la documentación de OpenSSL.

También puede inspeccionar los certificados donde se almacenan de forma predeterminada en /var/lib/aziot/certd/certs. Puede encontrar certificados de CA perimetral, certificados de identidad de dispositivo y certificados de módulo en el directorio. Puede usar comandos openssl x509 para inspeccionar los certificados. Por ejemplo:

sudo ls -l /var/lib/aziot/certd/certs

total 24
-rw-r--r-- 1 aziotcs aziotcs 1090 Jul 27 21:27 aziotedgedca-86f154be7ff14480027f0d00c59c223db6d9e4ab0b559fc523cca36a7c973d6d.cer
-rw-r--r-- 1 aziotcs aziotcs 2589 Jun 22 18:25 aziotedgedmoduleIoTEdgeAPIProxy637913460334654299server-c7066944a8d35ca97f1e7380ab2afea5068f39a8112476ffc89ea2c46ca81d10.cer
-rw-r--r-- 1 aziotcs aziotcs 2576 Jun 22 18:25 aziotedgedmoduleedgeHub637911101449272999server-a0407493b6b50ee07b3fedbbb9d181e7bb5f6f52c1d071114c361aca628daa92.cer
-rw-r--r-- 1 aziotcs aziotcs 1450 Jul 27 21:27 deviceid-bd732105ef89cf8edd2606a5309c8a26b7b5599a4e124a0fe6199b6b2f60e655.cer

En resumen, TempSensor puede confiar en EdgeGateway porque:

• El módulo edgeHub mostró un certificado de servidor de módulo de IoT Edge válido para edgegateway.local
• La CA perimetral emite el certificado que emite my_private_root_CA
• Esta entidad de certificación raíz privada también se almacena en TempSensor como CA raíz de confianza anteriormente
• Los algoritmos criptográficos comprueban que la propiedad y la cadena de emisión son de confianza

Certificados para otros módulos

Otros módulos pueden obtener certificados de servidor emitidos por la CA perimetral. Por ejemplo, un módulo de Grafana que tiene una interfaz web. También puede obtener un certificado de la CA perimetral. Los módulos se tratan como dispositivos de bajada hospedados en el contenedor. Sin embargo, poder obtener un certificado del runtime del módulo de IoT Edge es un privilegio especial. Los módulos llaman a la API de carga de trabajo para recibir el certificado de servidor encadenado a la CA perimetral configurada.

La puerta de enlace comprueba la identidad del dispositivo

¿Cómo comprueba EdgeGateway que se está comunicando con TempSensor? EdgeGateway usa la autenticación de cliente TLS para autenticar TempSensor.

La secuencia es similar a cómo ContosoIotHub comprueba un dispositivo. Sin embargo, en un escenario de puerta de enlace, EdgeGateway se basa en ContosoIotHub como origen de verdad para el registro de los certificados. EdgeGateway también mantiene una copia o caché sin conexión en caso de que no haya ninguna conexión a la nube.

Sugerencia

A diferencia de los dispositivos IoT Edge, los dispositivos IoT de bajada no se limitan a la autenticación X.509 de huella digital. La autenticación de entidad de certificación X.509 también es una opción. En lugar de buscar una coincidencia en la huella digital, EdgeGateway también puede comprobar si el certificado de TempSensor se basa en una CA que se ha cargado en ContosoIotHub.

En resumen, EdgeGateway puede confiar en TempSensor porque:

• TempSensor presentó un certificado de identidad de dispositivo IoT válido para su nombre
• La huella digital del certificado de identidad coincide con la cargada en ContosoIotHub
• Los algoritmos criptográficos comprueban que la propiedad y la cadena de emisión son de confianza

Dónde obtener los certificados y la administración

En la mayoría de los casos, puede proporcionar sus propios certificados o usarlos en certificados generados automáticamente. Por ejemplo, la CA perimetral y el certificado de edgeHub se generan automáticamente.

Sin embargo, el procedimiento recomendado es configurar los dispositivos para que usen un servidor de Enrollment over Secure Transport (EST) para administrar certificados x509. El uso de un servidor EST hace que no tenga que controlar manualmente los certificados e instalarlos en dispositivos. Para obtener más información sobre el uso de un servidor EST, consulte Configuración del protocolo Enrollment over Secure Transport para Azure IoT Edge.

También puede usar certificados para autenticarse en el servidor EST. Estos certificados se usan para autenticarse con servidores EST para emitir otros certificados. El servicio de certificados usa un certificado de arranque para autenticarse con un servidor EST. El certificado de arranque es de larga duración. Tras la autenticación inicial, el servicio de certificados realiza una solicitud al servidor EST para emitir un certificado de identidad. Este certificado de identidad se usa en futuras solicitudes EST al mismo servidor.

Si no puede usar un servidor EST, debe solicitar certificados del proveedor de PKI. Puede administrar manualmente los archivos de certificado en IoT Hub y los dispositivos IoT Edge. Para obtener más información, consulte Administración de certificados en un dispositivo IoT Edge.

Para el desarrollo de prueba de concepto, puede crear certificados de prueba. Para obtener más información, consulte Creación de certificados de demostración para probar las características de dispositivo IoT Edge.

Certificados en IoT

Entidad de certificación

La entidad de certificación (CA) es una entidad que emite certificados digitales. Una entidad de certificación actúa como un tercero de confianza entre el propietario y el receptor del certificado. Un certificado digital certifica la propiedad de una clave pública por parte del receptor del certificado. La cadena de certificados de confianza funciona mediante la emisión de un certificado raíz inicialmente, que es la base de confianza de todos los certificados emitidos por la autoridad. El propietario del certificado raíz puede emitir más certificados intermedios (certificados de dispositivo de nivel inferior).

Certificado de entidad de certificación raíz

Un certificado de CA raíz es la raíz de confianza de todo el proceso. En escenarios de producción, este certificado de CA es un certificado adquirido a través de una entidad de certificación comercial de confianza, como Baltimore, Verisign o DigiCert. Para tener un control completo sobre los dispositivos que se conectan a los dispositivos de IoT Edge, es posible usar una entidad de certificación de nivel corporativo. En cualquier caso, toda la cadena de certificados de IoT Edge a IoT Hub lo usa. Los dispositivos IoT de bajada deben confiar en el certificado raíz. Puede almacenar el certificado de CA raíz en el almacén de la entidad de certificación raíz de confianza o proporcionar los detalles del certificado en el código de la aplicación.

Certificados intermedios

En un proceso de fabricación típico para crear dispositivos seguros, rara vez se usan certificados de CA raíz directamente, principalmente debido al riesgo de pérdida o exposición. El certificado de entidad de certificación raíz crea y firma digitalmente uno o varios certificados de este tipo intermedios. Puede haber solo uno o bien una cadena de estos certificados intermedios. Los escenarios que requieren una cadena de certificados intermedios incluyen:

• Una jerarquía de departamentos dentro de un fabricante
• Varias empresas implicadas en serie en la producción de un dispositivo
• Un cliente que compra un certificado de CA raíz y deriva un certificado de firma para que el fabricante firme los dispositivos que realizan en nombre de ese cliente

En cualquier caso, el fabricante utiliza un certificado de CA intermedia al final de esta cadena para firmar el certificado de CA perimetral colocado en el dispositivo final. Estos certificados intermedios están estrechamente protegidos en la planta industrial. Se someten a procesos estrictos, tanto físicos como electrónicos, para su uso.

Pasos siguientes

• Para más información sobre cómo instalar certificados en un dispositivo IoT Edge y hacerles referencia desde el archivo de configuración, consulte Administración de certificados en un dispositivo IoT Edge.
• Información sobre los módulos de Azure IoT Edge
• Configuración de un dispositivo IoT Edge para que actúe como puerta de enlace transparente
• En este artículo se habla sobre los certificados que se usan para proteger las conexiones entre los distintos componentes de un dispositivo IoT Edge o entre un dispositivo IoT Edge y los dispositivos de bajada. También puede usar certificados para autenticar el dispositivo IoT Edge en IoT Hub. Estos certificados de autenticación son diferentes y no se tratan en este artículo. Para obtener más información sobre cómo autenticar el dispositivo con certificados, consulte Creación y aprovisionamiento de un dispositivo IoT Edge mediante certificados X.509.