Requisitos de certificado SSL/TLS para recursos locales
Este artículo forma parte de una serie de artículos que describen la ruta de acceso de implementación para la supervisión de OT con Microsoft Defender para IoT.
Use el siguiente contenido para conocer los requisitos para crear certificados SSL/TLS para su uso con dispositivos Microsoft Defender para IoT.
Defender para IoT usa certificados SSL/TLS para proteger la comunicación entre los siguientes componentes del sistema:
- Entre los usuarios y el sensor de OT o el acceso a la interfaz de usuario de la consola de administración local
- Entre sensores de OT y una consola de administración local, incluida la comunicación de API
- Entre una consola de administración local y un servidor de alta disponibilidad (HA), si está configurado
- Entre sensores de OT o consolas de administración locales y servidores asociados definidos en reglas de reenvío de alertas
Algunas organizaciones también validan sus certificados con una lista de revocación de certificados (CRL), la fecha de expiración del certificado y la cadena de confianza de certificados. Los certificados no válidos no se pueden cargar en sensores de OT ni en consolas de administración locales y bloquearán la comunicación cifrada entre los componentes de Defender para IoT.
Importante
Debe crear un certificado único para cada sensor de OT, la consola de administración local y el servidor de alta disponibilidad, donde cada certificado cumple los criterios necesarios.
Tipos de archivo admitidos
Al preparar certificados SSL/TLS para su uso con Microsoft Defender para IoT, asegúrese de crear los siguientes tipos de archivo:
| Tipo de archivo | Descripción |
|---|---|
| .crt: archivo contenedor de certificados | Un archivo .der o .pem, con una extensión diferente para que sea compatible con el Explorador de Windows. |
| .key: archivo de claves privadas | Un archivo de clave tiene el mismo formato que un archivo .pem, con una extensión diferente para la compatibilidad con el Explorador de Windows. |
| .pem: archivo de contenedor de certificados (opcional) | Opcional. Un archivo de texto con una codificación Base64 del texto del certificado y un encabezado y pie de página de texto sin formato para marcar el principio y el final del certificado. |
Requisitos de archivo CRT
Asegúrese de que los certificados incluyan los siguientes detalles del parámetro CRT:
| Campo | Requisito |
|---|---|
| Algoritmo de firma | SHA256RSA |
| Algoritmo hash de firma | SHA256 |
| Válido desde | Una fecha pasada válida |
| Válido hasta | Una fecha futura válida |
| Clave pública | RSA de 2048 bits (mínimo) o 4096 bits |
| Punto de distribución CRL | Dirección URL a un servidor CRL. Si su organización no valida los certificados en un servidor CRL, quite esta línea del certificado. |
| CN del firmante (nombre común) | nombre de dominio del dispositivo, como sensor.contoso.com o .contoso.com |
| (P)aís del firmante | Código de país de certificado, como US |
| Unidad organizativa (UO) del firmante | Nombre de unidad de la organización, como Contoso Labs |
| (O)rganización del firmante | Nombre de la organización, como Contoso Inc. |
Importante
Aunque los certificados con otros parámetros pueden funcionar, no son compatibles con Defender para IoT. Además, los certificados SSL comodín, que son certificados de clave pública que se pueden usar en varios subdominios, como .contoso.com, no son seguros y no se admiten. Cada dispositivo debe usar un CN único.
Requisitos de archivo de claves
Asegúrese de que sus archivos de claves de certificado utilizan RSA 2048 bits o 4096 bits. El uso de una longitud de clave de 4096 bits ralentiza el protocolo de enlace SSL al principio de cada conexión y aumenta el uso de CPU durante los protocolos de enlace.
Sugerencia
Se pueden usar los siguientes caracteres al crear una clave o certificado con una frase de contraseña: se admiten caracteres ASCII (a-z, A-Z, 0-9), así como los siguientes símbolos ! # % ( ) + , - . / : = ? @ [ \ ] ^ _ { } ~