Windows
Implemente certificados en dispositivos Windows mediante SCEP en Intune usando SCEPman.
El siguiente artículo describe la implementación de certificados de dispositivo o/y de usuario para dispositivos Windows. La implementación del certificado raíz SCEPman es obligatoria. Después, puede elegir entre implementar solo el tipo de certificado de dispositivo, de usuario o incluso ambos.
Certificado raíz
La base para implementar certificados SCEP es confiar en el certificado raíz de SCEPman. Por lo tanto, debe descargar el certificado raíz de la CA e implementarlo como un certificado de confianza perfil a través de Microsoft Intune:
Tenga en cuenta que debe usar el mismo grupo para asignar el certificado de confianza y el perfil SCEP. De lo contrario, la implementación de Intune podría fallar.
Certificados de dispositivo
Formato del nombre del sujeto: CN={{DeviceName}} o CN={{DeviceId}} o CN={{AAD_Device_ID}}
Recomendado: Use {{DeviceName}}para el RDN CN para tener un nombre significativo del certificado en el dispositivo o al buscar el certificado.
Opcional: Si se configura en CN={{DeviceId}} o CN={{AAD_Device_ID}}, SCEPman usa el campo CN del nombre del sujeto para identificar el dispositivo y como semilla para la generación del número de serie del certificado. Microsoft Entra ID (Azure AD) e Intune ofrecen dos identificadores distintos:
{{DeviceId}}: Este ID lo genera y lo usa Intune. (requiere SCEPman 2.0 o superior y AppConfig:IntuneValidation:DeviceDirectory que se establezca en Intune o AADAndIntune){{AAD_Device_ID}}: Este ID lo genera y lo usa Microsoft Entra ID (Azure AD).
En caso de que ni CN={{DeviceId}} ni CN={{AAD_Device_ID}} se usen en el campo CN (p. ej. CN={{DeviceName}}), SCEPman identificará el dispositivo en función del ID de dispositivo de Intune (Valor (URI): IntuneDeviceId://{{DeviceId}}) proporcionado en el nombre alternativo del sujeto (SAN).
Importante: La elección del campo CN afecta al comportamiento de revocación automática de los certificados emitidos para sus dispositivos administrados por Intune.
Puede agregar otros RDN si es necesario (p. ej.: CN={{DeviceId}}, O=Contoso, CN={{WiFiMacAddress}}). Las variables compatibles se enumeran en la documentación de Microsoft.
Nombre alternativo del sujeto: (URI)Valor: IntuneDeviceId://{{DeviceId}}
El campo URI es recomendado por Microsoft para soluciones NAC para identificar los dispositivos en función de su ID de dispositivo de Intune. El valor debe ser:
El campo URI es obligatorio en caso de que no se use ni CN={{DeviceId}} ni CN={{AAD_Device_ID}} ni en el campo Formato del nombre del sujeto .
Se pueden agregar otros valores SAN, como DNS, si es necesario.
Periodo de validez del certificado: 1 año
La cantidad de tiempo restante antes de que el certificado expire. El valor predeterminado se establece en un año.
SCEPman limita la validez del certificado al máximo configurado en el ajuste AppConfig:ValidityPeriodDays, pero, por lo demás, usa la validez configurada en la solicitud.
Proveedor de almacenamiento de claves (KSP): Inscribirse en el proveedor KSP del Módulo de plataforma segura (TPM), de lo contrario fallar
Este ajuste determina la ubicación de almacenamiento de la clave privada para los certificados de usuario final. El almacenamiento en el TPM es más seguro que el almacenamiento por software porque el TPM proporciona una capa adicional de seguridad para evitar el robo de claves.
Nota: Hay un error en algunas versiones antiguas de firmware TPM que invalida algunas firmas creadas con una clave privada respaldada por TPM. En tales casos, el certificado no puede utilizarse para la autenticación EAP, como es habitual en las conexiones Wi‑Fi y VPN. Además, esto podría interrumpir su proceso de incorporación de Autopilot.
Las versiones de firmware TPM afectadas incluyen:
STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100, 73.20.17568.6684
Intel: 11.8.50.3399, 2.0.0.2060
Infineon: 7.63.3353.0
IFX: Versión 3.19 / Especificación 1.2
IFX versión 7.63.3353.0 especificación 2.0
Si usa TPM con este firmware, actualice el firmware a una versión más reciente o seleccione "Software KSP" como proveedor de almacenamiento de claves.
Actualización: Puede evitar el error de TPM eliminando los algoritmos de firma RSA-PSS —que causan el problema— del registro; para más información consulte el artículo de Richard Hicks y Microsoft Q&A
Uso de claves: Firma digital y Cifrado de claves
Active ambas acciones criptográficas.
SCEPman establece automáticamente el uso de clave en Firma digital y Cifrado de claves y sobrescribe la configuración aquí, a menos que el ajuste AppConfig:UseRequestedKeyUsages esté configurado en true.
Certificado raíz: Perfil del paso anterior (perfil de certificado raíz)
Seleccione el perfil de Intune de #Certificado raíz. Si está usando una CA intermedia, debe seleccionar el perfil de certificado de confianza para la CA intermedia, ¡no la CA raíz!
Uso extendido de clave: Autenticación de cliente, 1.3.6.1.5.5.7.3.2
Por favor, elija Autenticación de cliente (1.3.6.1.5.5.7.3.2) en Valores predefinidos. Los demás campos se completarán automáticamente.
Umbral de renovación (%): 20
Este valor define cuándo se permite al dispositivo renovar su certificado (según la vida útil restante de un certificado existente). Lea la nota bajo Periodo de validez del certificado y seleccione un valor adecuado que permita al dispositivo renovar el certificado durante un largo periodo. Un valor del 20 % permitiría a un dispositivo con un certificado válido durante 1 año iniciar la renovación 73 días antes de la expiración.
URL del servidor SCEP: Abra el portal de SCEPman y copie la URL de Intune MDM
Ejemplo
Ejemplo
Certificados de usuario
Siga las instrucciones de #Certificados de dispositivo y tenga en cuenta las siguientes diferencias:
Formato del nombre del sujeto: CN={{UserName}},E={{EmailAddress}}
Puede definir RDN según sus necesidades. Las variables compatibles se enumeran en la documentación de Microsoft. Recomendamos incluir el nombre de usuario (p. ej.: janedoe) y la dirección de correo electrónico (p. ej.: [email protected]) como configuración básica.
Nombre alternativo del sujeto: (UPN)Valor: {{UserPrincipalName}}
Debe agregar el nombre principal del usuario como nombre alternativo del sujeto. Agregue '{{UserPrincipalName}}' como nombre alternativo del sujeto de tipo nombre principal del usuario (UPN). Esto garantiza que SCEPman pueda vincular los certificados a objetos de usuario en AAD. La configuración de 'Formato del nombre del sujeto' es libremente seleccionable.
Se pueden agregar otros valores SAN, como una dirección de correo electrónico, si es necesario.
Según los comentarios de los clientes, parece que algunos clientes VPN (por ejemplo, Azure VPN Client para Virtual WAN) no pueden detectar el certificado de usuario cuando se almacena en el TPM. Intente inscribirlo en su lugar en el KSP de software.
Ejemplo
Certificado de firma digital de usuario
Puede usar SCEPman para firmas digitales transaccionales, es decir, para la firma S/MIME en Microsoft Outlook. Si planea usar los certificados para la firma de mensajes, debe agregar los usos extendidos de clave correspondientes en la configuración del perfil de Intune.
No use SCEPman para cifrado de correo electrónico es decir, para el cifrado de correo S/MIME en Microsoft Outlook (sin una tecnología separada para la gestión de claves). La naturaleza de el protocolo SCEP no incluye un mecanismo para hacer copia de seguridad o archivar material de clave privada. Si utilizara SCEP para cifrado de correo electrónico, podría perder las claves para descifrar los mensajes posteriormente.
AppConfig:UseRequestedKeyUsagesestablecer entrueAppConfig:ValidityPeriodDaysestablecer en365(es posible un valor máximo de 1825 - 5 años)
Para implementar certificados de usuario usados para Firmas digitales siga las instrucciones de #Certificados de usuario y tenga en cuenta las siguientes diferencias y notas:
Nombre alternativo del sujeto
(obligatorio) Nombre principal del usuario (UPN):
{{UserPrincipalName}}(obligatorio) Dirección de correo electrónico:
{{EmailAddress}}
Al implementar un certificado de firma digital, debe agregar el UPN y la dirección de correo electrónico.
Uso extendido de clave: Correo seguro (1.3.6.1.5.5.7.3.4)
Por favor, elija Correo seguro (1.3.6.1.5.5.7.3.4) en Valores predefinidos. Los demás campos se completarán automáticamente.
Umbral de renovación (%): 50
Recomendamos establecer el Umbral de renovación (%) en un valor que garantice que los certificados se renueven al menos 6 meses antes de su vencimiento al emitir certificados de firma S/MIME. Esto se debe a que los correos electrónicos firmados con certificados caducados aparecen con firmas no válidas en Outlook, lo que confunde a los usuarios. Tener un nuevo certificado mucho antes de que caduque el anterior garantiza que solo los correos más antiguos muestren este comportamiento, algo que los usuarios tienen menos probabilidades de revisar. Por ejemplo, si sus certificados de firma son válidos durante un año, debería establecer el Umbral de renovación en al menos el 50 %.
Ejemplo
Después de una sincronización correcta del perfil, debería ver el certificado de usuario para los usos previstos Correo seguro
El certificado estará disponible para uso de Firma digital en, por ejemplo, Outlook. A continuación se muestra un ejemplo del uso
Activar firmas S/MIME en Outlook
Una vez que haya implementado certificados de firma S/MIME en sus equipos cliente, debe configurar Outlook para usar estos certificados antes de enviar correos firmados.
Nuevo Outlook
S/MIME para el nuevo Outlook se puede configurar manualmente.
Outlook clásico
S/MIME para Outlook clásico se puede configurar manualmente o configurarse rápidamente con nuestro script de PowerShell.
Outlook en la Web
S/MIME para Outlook en la Web se puede configurar manualmente o habilitar mediante PowerShell con el siguiente comando:
Se pueden ver comandos adicionales de PowerShell aquí.
Última actualización
¿Te fue útil?