Compartir a través de

Tutorial: Creación y cargar certificados para pruebas

  • Artículo

Puede usar certificados de cliente X.509 para autenticar dispositivos en su concentrador IoT. Para entornos de producción, le recomendamos que adquiera un certificado CA X.509 de un proveedor profesional de servicios de certificados. A continuación, puede emitir certificados dentro de su organización desde una entidad de certificación (CA) interna y autoadministrada encadenada al certificado CA adquirido como parte de una estrategia integral de infraestructura de clave pública (PKI). Para más información sobre cómo obtener un certificado de CA X.509 de un proveedor de servicios de certificación profesional, consulte la sección Obtener un certificado de CA X.509 de Autenticar dispositivos mediante certificados de CA X.509.

Sin embargo, crear su propia CA privada autoadministrada que use una CA raíz interna como ancla de confianza es adecuado para entornos de prueba. Una CA privada autoadministrada con al menos una CA subordinada encadenada a su CA raíz interna, con certificados de cliente para sus dispositivos firmados por sus CA subordinadas, le permite simular un entorno de producción recomendado.

Importante

No se recomienda el uso de certificados autofirmados para entornos de producción. En este tutorial se presenta únicamente con fines de demostración.

El siguiente tutorial usa OpenSSL y el Libro de cocina de OpenSSL para describir cómo realizar las siguientes tareas:

  • Creación de una entidad de certificación (CA) raíz interna y un certificado de CA raíz
  • Creación de una CA subordinada interna y de un certificado de CA subordinada, firmados por su certificado de CA raíz interna.
  • Cargue su certificado de CA subordinada en su concentrador IoT para realizar pruebas
  • Use la CA subordinada para crear certificados de cliente para los dispositivos IoT que desee probar con su concentrador IoT

Nota

Microsoft proporciona scripts de PowerShell y Bash para ayudarle a entender cómo crear sus propios certificados X.509 y autenticarlos en una instancia de IoT Hub. Los scripts se incluyen con el SDK de dispositivos Azure IoT Hub para C. Los scripts solo se proporcionan con fines de demostración. Los certificados creados por ellos no deben usarse para producción. Los certificados contienen contraseñas codificadas de forma rígida ("1234") y expiran después de 30 días. Deberá usar sus propios procedimientos recomendados para la creación de certificados y la administración de la vigencia en entornos de producción. Para obtener más información, consulte Administración de certificados de CA de prueba para obtener ejemplos y tutoriales en el repositorio de GitHub para el SDK de dispositivos de Azure IoT Hub para C.

Requisitos previos

  • Suscripción a Azure. Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

  • Una instancia de IoT Hub en la suscripción de Azure. Si aún no tiene un centro, puede seguir los pasos descritos en Creación de un centro de IoT.

  • La última versión de Git. Asegúrese de que Git se ha agregado a las variables de entorno accesibles desde la ventana de comandos. Consulte las herramientas de cliente de Git de Software Freedom Conservancy para instalar la versión más reciente de las herramientas git, lo que incluye Git Bash, la aplicación de línea de comandos que puede usar para interactuar con su repositorio de Git local.

  • Una instalación de OpenSSL. En Windows, la instalación de Git incluye una instalación de OpenSSL. Puede acceder a OpenSSL desde el símbolo del sistema de Git Bash. Para comprobar que OpenSSL está instalado, abra un símbolo del sistema de Git Bash y escriba openssl version.

    Nota:

    A menos que esté familiarizado con OpenSSL y ya lo tenga instalado en la máquina Windows, se recomienda usar OpenSSL desde el símbolo del sistema de Git Bash. Como alternativa, puede optar por descargar el código fuente y compilar OpenSSL. Para más información, consulte la página Descargas de OpenSSL. O bien, puede descargar la precompilación de OpenSSL de un tercero. Para más información, consulte la wiki de OpenSSL. Microsoft no garantiza la validez de los paquetes descargados de terceros. Si decide compilar o descargar OpenSSL, asegúrese de que se puede acceder al binario de OpenSSL en la ruta de acceso y de que la variable de entorno OPENSSL_CNF esté establecida en la ruta de acceso del archivo openssl.cnf.

Crear una CA raíz

Primero debe crear una entidad de certificación (CA) raíz interna y un certificado de CA raíz autofirmado que sirva como ancla de confianza a partir de la cual pueda crear otros certificados para realizar pruebas. Los archivos que se usan para crear y mantener su CA raíz interna se almacenan en una estructura de carpetas y se inicializan como parte de este proceso. En ella, lleve a cabo los siguiente pasos.

  • Creación e inicialización de las carpetas y los archivos usados por la CA raíz
  • Creación de un archivo de configuración que OpenSSL usará para configurar la CA raíz y los certificados creados con ella.
  • Solicite y cree un certificado de CA autofirmado que sirva como su certificado de CA raíz

  1. Inicia una ventana Git Bash y ejecuta el siguiente comando, en el que sustituirá {base_dir} por el directorio deseado en el que crear los certificados en este tutorial.

    cd {base_dir}

  2. En la ventana de Git Bash, ejecuta los siguientes comandos, de uno en uno. Este paso crea la siguiente estructura de directorios y archivos de compatibilidad para la CA raíz.

    Directorio o archivo Descripción
    rootca El directorio raíz de la CA raíz.
    rootca/certs El directorio en el que se crean y almacenan los certificados CA para la CA raíz.
    rootca/db El directorio en el que se almacenan la base de datos de certificados y los archivos de soporte de la CA raíz.
    rootca/db/index La base de datos de certificados para la CA raíz. El comando touch crea un archivo sin contenido, para su uso posterior. La base de datos de certificados es un archivo de texto sin formato administrado por OpenSSL que contiene información sobre los certificados emitidos. Para más información sobre la base de datos de certificados, consulta la página del manual openssl-ca.
    rootca/db/serial Archivo que se usa para almacenar el número de serie del siguiente certificado que se creará para la CA raíz. El comando openssl crea un número aleatorio de 16 bytes en formato hexadecimal y lo almacena en este archivo para inicializar el archivo de creación del certificado de CA raíz.
    rootca/db/crlnumber Un archivo que se usa para almacenar los números de serie de los certificados revocados emitidos por la CA raíz. El comando echo introduce un número de serie de muestra, 1001, en el archivo.
    rootca/private Directorio en el que se almacenan los archivos privados de la CA raíz, incluida la clave privada.
    Los archivos de este directorio deben estar protegidos.    		 
    mkdir rootca
cd rootca
mkdir certs db private
chmod 700 private
touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber

  3. Crea un archivo de texto llamado rootca.conf en el directorio rootca creado en el paso anterior. Abre ese archivo en un editor de texto y, después, copia y guarda los siguientes parámetros de configuración de OpenSSL en ese archivo

    El archivo proporciona a OpenSSL los valores necesarios para configurar su CA raíz de prueba. Para este ejemplo, el archivo configura una CA raíz llamada rootca mediante los directorios y archivos creados en los pasos anteriores. El archivo también proporciona valores de configuración para:

    • La directiva de CA que usa la CA raíz para los campos de nombre distinguido (DN) del certificado.
    • Las solicitudes de certificados creadas por la CA raíz
    • Extensiones X.509 aplicadas a certificados de CA raíz, certificados de CA subordinada y certificados de cliente emitidos por la CA raíz.

    Nota

    El atributo home, en la sección ca_default, se establece en ../rootca, porque este archivo de configuración también se usa al crear el certificado para la entidad de certificación subordinada. La ruta de acceso relativa especificada permite a OpenSSL ir de la carpeta de la entidad de certificación subordinada a la carpeta de la entidad de certificación raíz durante ese proceso.

    Para más información sobre la sintaxis de los archivos de configuración de OpenSSL, consulte la página del manual config en la documentación de OpenSSL.

    [default]
name                     = rootca
domain_suffix            = exampledomain.com
aia_url                  = http://$name.$domain_suffix/$name.crt
crl_url                  = http://$name.$domain_suffix/$name.crl
default_ca               = ca_default
name_opt                 = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
commonName               = "rootca_common_name"

[ca_default]
home                     = ../rootca
database                 = $home/db/index
serial                   = $home/db/serial
crlnumber                = $home/db/crlnumber
certificate              = $home/$name.crt
private_key              = $home/private/$name.key
RANDFILE                 = $home/private/random
new_certs_dir            = $home/certs
unique_subject           = no
copy_extensions          = none
default_days             = 3650
default_crl_days         = 365
default_md               = sha256
policy                   = policy_c_o_match

[policy_c_o_match]
countryName              = optional
stateOrProvinceName      = optional
organizationName         = optional
organizationalUnitName   = optional
commonName               = supplied
emailAddress             = optional

[req]
default_bits             = 2048
encrypt_key              = yes
default_md               = sha256
utf8                     = yes
string_mask              = utf8only
prompt                   = no
distinguished_name       = ca_dn
req_extensions           = ca_ext

[ca_ext]
basicConstraints         = critical,CA:true
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[sub_ca_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:true,pathlen:0
extendedKeyUsage         = clientAuth,serverAuth
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[client_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:false
extendedKeyUsage         = clientAuth
keyUsage                 = critical,digitalSignature
subjectKeyIdentifier     = hash

  4. En la ventana Git Bash, ejecuta el siguiente comando para generar una solicitud de firma de certificado (CSR) en el directorio rootca y una clave privada en el directorio rootca/private. Para más información sobre el comando reqde OpenSSL, consulte la página del manual openssl-req en la documentación de OpenSSL.

    Nota:

    Aunque esta CA raíz es para fines de prueba y no se expondrá como parte de una infraestructura de clave pública (PKI), le recomendamos que no copie ni comparta la clave privada.

    winpty openssl req -new -config rootca.conf -out rootca.csr -keyout private/rootca.key

    Se le pedirá que ingrese una frase de paso PEM, como se muestra en el siguiente ejemplo, para el archivo de clave privada. Escriba y confirme una frase de contraseña para generar su clave privada y CSR.

    Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

    Confirma que el archivo CSR, rootca.csr, está presente en el directorio rootca que el archivo de clave privada, rootca.key, está presente en el subdirectorio private antes de continuar.

  5. En la ventana Git Bash, ejecute el siguiente comando para crear un certificado CA raíz autofirmado. El comando aplica las extensiones del archivo de configuración ca_ext al certificado. Estas extensiones indican que el certificado es para una entidad de certificación raíz y se pueden usar para firmar certificados y listas de revocación de certificados (CRL). Para más información sobre el comando ca de OpenSSL, consulte la página del manual openssl-ca en la documentación de OpenSSL.

    winpty openssl ca -selfsign -config rootca.conf -in rootca.csr -out rootca.crt -extensions ca_ext

    Se le pedirá que proporcione la frase de contraseña PEM, como se muestra en el siguiente ejemplo, para el archivo de clave privada. Después de proporcionar la frase de contraseña, OpenSSL genera un certificado y, a continuación, le solicita que firme y confirme el certificado para su CA raíz. Especifique y en ambos campos para generar el certificado autofirmado para su CA raíz.

    Using configuration from rootca.conf
Enter pass phrase for ../rootca/private/rootca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:51:41 2033 GMT (3650 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated

    Después de que OpenSSL actualice la base de datos de certificados, confirma que el archivo del certificado, rootca.crt, está presente en el directorio rootca y que el archivo del certificado PEM (.pem) para el certificado está presente en el directorio rootca/certs. El nombre del archivo .pem coincide con el número de serie del certificado de CA raíz.

Creación de una CA subordinada

Después de crear la CA raíz interna, debe crear una CA subordinada para usarla como CA intermedia con la que firmar certificados de cliente para sus dispositivos. En teoría, no necesita crear una CA subordinada; puede cargar su certificado de CA raíz en su concentrador IoT y firmar certificados de cliente directamente desde su CA raíz. Sin embargo, el uso de una CA subordinada como CA intermedia para firmar certificados de cliente simula mejor un entorno de producción recomendado, en el que la CA raíz se mantiene desconectada. También puede usar una CA subordinada para firmar otra CA subordinada, que a su vez puede firmar otra CA subordinada, etcétera. El uso de CA subordinadas para firmar otras CA subordinadas crea una jerarquía de CA intermedias como parte de una cadena de confianza de certificados. En un entorno de producción, la cadena de confianza de certificados permite una delegación de confianza hacia los dispositivos de firma. Para más información sobre la firma de dispositivos en una cadena de confianza de certificados, consulte Autenticación de dispositivos mediante certificados de CA X.509.

De forma similar a su CA raíz, los archivos que se usan para crear y mantener su CA subordinada se almacenan en una estructura de carpetas y se inicializan como parte de este proceso. En ella, lleve a cabo los siguiente pasos.

  • Creación e inicialización de las carpetas y archivos que usa la CA subordinada
  • Creación de un archivo de configuración que OpenSSL usará para configurar la CA subordinada y los certificados creados con ella.
  • Solicite y cree un certificado CA firmado por su CA raíz que sirva como certificado de su CA subordinada.

  1. Vuelve al directorio base que contiene el directorio rootca. En este ejemplo, tanto la entidad de certificación raíz como la entidad de certificación subordinada residen en el mismo directorio base.

    cd ..

  2. En la ventana de Git Bash, ejecuta los siguientes comandos, de uno en uno.

    Este paso crea una estructura de directorios y archivos de soporte para la CA subordinada similar a la estructura de carpetas y archivos creada para la CA raíz en la sección anterior.

    mkdir subca
cd subca
mkdir certs db private
chmod 700 private
touch db/index
openssl rand -hex 16 > db/serial
echo 1001 > db/crlnumber

  3. Crea un archivo de texto llamado subca.conf en el directorio subca creado en el paso anterior. Abre ese archivo en un editor de texto y, después, copia y guarda los siguientes parámetros de configuración de OpenSSL en ese archivo

    Al igual que con el archivo de configuración para su CA raíz de prueba, este archivo proporciona a OpenSSL los valores necesarios para configurar su CA subordinada de prueba. Puede crear varias CA subordinadas para administrar escenarios o entornos de prueba.

    Para más información sobre la sintaxis de los archivos de configuración de OpenSSL, consulte la página config del manual principal en la documentación de OpenSSL.

    [default]
name                     = subca
domain_suffix            = exampledomain.com
aia_url                  = http://$name.$domain_suffix/$name.crt
crl_url                  = http://$name.$domain_suffix/$name.crl
default_ca               = ca_default
name_opt                 = utf8,esc_ctrl,multiline,lname,align

[ca_dn]
commonName               = "subca_common_name"

[ca_default]
home                     = ../subca
database                 = $home/db/index
serial                   = $home/db/serial
crlnumber                = $home/db/crlnumber
certificate              = $home/$name.crt
private_key              = $home/private/$name.key
RANDFILE                 = $home/private/random
new_certs_dir            = $home/certs
unique_subject           = no
copy_extensions          = copy
default_days             = 365
default_crl_days         = 90
default_md               = sha256
policy                   = policy_c_o_match

[policy_c_o_match]
countryName              = optional
stateOrProvinceName      = optional
organizationName         = optional
organizationalUnitName   = optional
commonName               = supplied
emailAddress             = optional

[req]
default_bits             = 2048
encrypt_key              = yes
default_md               = sha256
utf8                     = yes
string_mask              = utf8only
prompt                   = no
distinguished_name       = ca_dn
req_extensions           = ca_ext

[ca_ext]
basicConstraints         = critical,CA:true
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[sub_ca_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:true,pathlen:0
extendedKeyUsage         = clientAuth,serverAuth
keyUsage                 = critical,keyCertSign,cRLSign
subjectKeyIdentifier     = hash

[client_ext]
authorityKeyIdentifier   = keyid:always
basicConstraints         = critical,CA:false
extendedKeyUsage         = clientAuth
keyUsage                 = critical,digitalSignature
subjectKeyIdentifier     = hash

  4. En la ventana Git Bash, ejecute los siguientes comandos para generar una clave privada y una solicitud de firma de certificado (CSR) en el directorio de la CA subordinada

    winpty openssl req -new -config subca.conf -out subca.csr -keyout private/subca.key

    Se le pedirá que ingrese una frase de paso PEM, como se muestra en el siguiente ejemplo, para el archivo de clave privada. Escriba y verifique una frase de contraseña para generar la clave privada y la CSR.

    Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----

    Confirma que el archivo CSR subca.csr está presente en el directorio de la CA subordinada y que el archivo de clave privada subca.key está presente en el subdirectorio private antes de continuar.

  5. En la ventana Git Bash, ejecute el siguiente comando para crear un certificado de CA subordinada en el directorio de CA subordinada. El comando aplica las extensiones del archivo de configuración sub_ca_ext al certificado. Estas extensiones indican que el certificado es para una CA subordinada y también se pueden usar para firmar certificados y listas de revocación de certificados (CRL). A diferencia del certificado de CA raíz, este certificado no está autofirmado. En su lugar, el certificado de CA subordinada se firma con el certificado de CA raíz, estableciendo una cadena de certificados similar a la que se utilizaría para una infraestructura de clave pública (PKI). A continuación, el certificado de CA subordinada se usa para firmar certificados de cliente para probar los dispositivos.

    winpty openssl ca -config ../rootca/rootca.conf -in subca.csr -out subca.crt -extensions sub_ca_ext

    Se le pedirá que ingrese la frase de paso, como se muestra en el siguiente ejemplo, para el archivo de clave privada de su CA raíz. Una vez que escriba la frase de paso, OpenSSL generará y mostrará los detalles del certificado y, a continuación, le pedirá que firme y confirme el certificado para su CA subordinada. Especifica y en ambos campos a fin de generar el certificado para tu CA subordinada.

    Using configuration from rootca.conf
Enter pass phrase for ../rootca/private/rootca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:55:00 2024 GMT (365 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated

    Después de que OpenSSL actualice la base de datos de certificados, confirma que el archivo del certificado, subca.crt, está presente en el directorio de la CA subordinada y que el archivo del certificado PEM (.pem) para el certificado está presente en el directorio rootca/certs. El nombre del archivo .pem coincide con el número de serie del certificado de la CA subordinada.

Registre su certificado de CA subordinada en su centro de IoT

Registra el certificado de CA subordinada en IoT Hub, donde se utilizará para autenticar los dispositivos durante el registro y la conexión. Los siguientes pasos describen cómo cargar y verificar automáticamente el certificado de CA subordinada en el concentrador IoT.

  1. En Azure Portal, ve a tu instancia de IoT Hub y selecciona Certificados en el menú de recursos, en Configuración de seguridad.

  2. Seleccione Agregar en la barra de comandos para agregar un nuevo certificado de CA.

  3. Escriba un nombre para su certificado de CA subordinada en el campo Nombre del certificado.

  4. Selecciona el archivo de certificado PEM (.pem) de tu certificado de CA subordinada del directorio rootca/certs para agregarlo en el campo Archivo de certificado .pem o .cer.

  5. Active la casilla situada junto a Set certificate status to verified on upload (Establecer el estado del certificado que se va a comprobar al cargar).

    Captura de pantalla en la que se muestra cómo comprobar automáticamente el estado del certificado al cargarlo.

  6. Seleccione Guardar.

Su certificado de CA subordinada cargado se mostrará con el estado Verificado en la ficha Certificados del panel de trabajo.

Creación de un certificado de cliente para un dispositivo

Después de crear su CA subordinada, puede crear certificados de cliente para sus dispositivos. Los archivos y carpetas creados para su CA subordinada se usan para almacenar la CSR, la clave privada y los archivos de certificado para sus certificados de cliente.

El certificado de cliente debe tener el valor de su campo Subject Common Name (CN) establecido en el valor del ID de dispositivo que se usó al registrar el dispositivo correspondiente en Azure IoT Hub.

En ella, lleve a cabo los siguiente pasos.

  • Creación de una clave privada y una solicitud de firma de certificado (CSR) para un certificado de cliente
  • Cree un certificado de cliente firmado por su certificado de CA subordinada

  1. En la ventana de Git Bash, asegúrate de que todavía estás en el directorio subca.

  2. En la ventana de Git Bash, ejecuta los siguientes comandos, de uno en uno. Reemplaza el marcador de posición por un nombre para el dispositivo IoT, por ejemplo, testdevice. Este paso crea la clave privada y la CSR para tu certificado de cliente.

    En este paso se crea una clave privada RSA de 2048 bits para su certificado de cliente y, a continuación, se genera una solicitud de firma de certificado (CSR) con dicha clave privada.

    winpty openssl genpkey -out private/<DEVICE_NAME>.key -algorithm RSA -pkeyopt rsa_keygen_bits:2048
winpty openssl req -new -key private/<DEVICE_NAME>.key -out <DEVICE_NAME>.csr

  3. Cuando se te pida, proporciona los detalles del certificado, como se muestra en el siguiente ejemplo.

    El único mensaje para el que debes proporcionar un valor específico es el Nombre común, que debe ser el mismo nombre de dispositivo proporcionado en el paso anterior. Puedes omitir o proporcionar valores arbitrarios para el resto de los mensajes.

    Después de proporcionar los detalles del certificado, OpenSSL genera y muestra los detalles del certificado y, a continuación, le solicita que firme y confirme el certificado para su CA subordinada. Especifique y en ambos campos para generar el certificado para su CA subordinada.

    -----
Country Name (2 letter code) [XX]:.
State or Province Name (full name) []:.
Locality Name (eg, city) [Default City]:.
Organization Name (eg, company) [Default Company Ltd]:.
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server hostname) []:'<DEVICE_NAME>'
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

    Confirma que el archivo CSR está presente en el directorio de la CA subordinada y que el archivo de clave privada está presente en el subdirectorio private antes de continuar. Para más información sobre los formatos de los archivos CSR y de clave privada, consulte Certificados X.509.

  4. En la ventana de Git Bash, ejecuta el siguiente comando y reemplaza los marcadores de posición de nombre de dispositivo por el mismo nombre que usaste en los pasos anteriores.

    Este paso crea un certificado de cliente en el directorio de la CA subordinada. El comando aplica las extensiones del archivo de configuración client_ext al certificado. Estas extensiones indican que se trata de un certificado de cliente, que no puede utilizarse como certificado de CA. El certificado de cliente se firma con el certificado de CA subordinada.

    winpty openssl ca -config subca.conf -in <DEVICE_NAME>.csr -out <DEVICE_NAME>.crt -extensions client_ext

    Se le pedirá que escriba la frase de paso, como se muestra en el siguiente ejemplo, para el archivo de clave privada de su CA subordinada. Una vez escrita la frase de paso, OpenSSL genera y muestra los detalles del certificado y, a continuación, le solicita que firme y confirme el certificado de cliente para su dispositivo. Especifique y en ambos campos para generar el certificado de cliente.

    Using configuration from subca.conf
Enter pass phrase for ../subca/private/subca.key:
Check that the request matches the signature
Signature ok
Certificate Details:
    {Details omitted from output for clarity}
Certificate is to be certified until Mar 24 18:51:41 2024 GMT (365 days)
Sign the certificate? [y/n]:


1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated

    Después de que OpenSSL actualice la base de datos de certificados, confirme que el archivo del certificado del cliente está presente en el directorio de la CA subordinada y que el archivo del certificado PEM (.pem) del certificado del cliente está presente en el subdirectorio certs del directorio de la CA subordinada. El nombre del archivo .pem coincide con el número de serie del certificado de cliente.

Pasos siguientes

Puede registrar su dispositivo en el centro de IoT para probar el certificado de cliente que ha creado para ese dispositivo. Para obtener más información sobre cómo registrar un dispositivo, consulte Creación y administración de identidades de dispositivo.

Si tiene varios dispositivos relacionados para probar, puede usar IoT Hub Device Provisioning Service para aprovisionar varios dispositivos en un grupo de inscripción. Para más información sobre el uso de grupos de inscripción en el servicio de aprovisionamiento de dispositivos, consulte Tutorial: Aprovisionamiento de varios dispositivos X.509 mediante grupos de inscripción.