Microsoft Cloud PKI para WiFi: despliegue de certificados EAP-TLS con Intune y Microsoft Entra ID

Sí. Microsoft Cloud PKI, la autoridad de certificación alojada en Intune Suite, emite certificados WiFi EAP-TLS a dispositivos gestionados por Intune. Un perfil de certificado SCEP los solicita directamente, por lo que no necesita ningún servidor NDES, conector de certificados ni CA en las instalaciones. Su servidor RADIUS confía en la raíz de Cloud PKI importada y comprueba cada certificado contra la CRL que publica el servicio.

¿Qué hace Microsoft Cloud PKI para la autenticación WiFi?

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) es el método 802.1X en el que ambas partes demuestran su identidad con certificados. IEEE 802.1X es el estándar de control de acceso basado en puertos detrás de WPA2-Enterprise y WPA3-Enterprise. El punto de acceso pasa cada intento de conexión a un servidor RADIUS, el servidor de autenticación que acepta o rechaza el dispositivo. Con EAP-TLS no hay contraseña que pescar mediante phishing ni clave compartida que filtrar. Cada dispositivo conserva su propia clave privada y certificado.

La parte difícil siempre ha sido la PKI (infraestructura de clave pública) que hay detrás. Obtener certificados en dispositivos gestionados por Intune requería tradicionalmente cuatro cosas:

• una CA emisora de Active Directory Certificate Services (AD CS)
• un servidor NDES (Network Device Enrollment Service)
• el Intune Certificate Connector
• un proxy inverso o proxy de aplicaciones de Microsoft Entra ID para publicar NDES en Internet

Cada uno de ellos requiere parches, copias de seguridad y supervisión.

Microsoft Cloud PKI reemplaza esa pila con una autoridad de certificación alojada en su inquilino de Intune. Los dispositivos solicitan certificados a través de SCEP (Simple Certificate Enrollment Protocol) y Cloud PKI responde a esas solicitudes por sí mismo. Valida cada solicitud frente a Intune, firma el certificado y lo devuelve. El dispositivo genera su clave privada de forma local y la clave nunca sale de él.

Para las flotas unidas a Entra ID, esto elimina la última dependencia en las instalaciones de la cadena de certificados. Los dispositivos que nunca han visto un controlador de dominio aún pueden obtener un certificado WiFi.

Cómo funciona la jerarquía de la CA de Cloud PKI

Cloud PKI utiliza una jerarquía de dos niveles. Una CA raíz firma una o más CA emisoras, y la CA emisora firma los certificados de los dispositivos. Microsoft conserva las claves de firma de la CA en módulos de seguridad de hardware (HSM), por lo que usted nunca gestiona material de claves.

Puede elegir uno de estos dos anclajes:

• Cloud PKI root. Microsoft aloja tanto la raíz como la CA emisora en su inquilino. Esta es la opción más sencilla para un entorno nuevo de Entra ID.
• Bring your own CA (BYOCA). Crea una CA emisora de Cloud PKI, descarga su solicitud de firma de certificado y la firma con su CA raíz privada existente, como una raíz de AD CS. Cualquier elemento que ya confíe en esa raíz confiará entonces en la cadena de la nueva CA emisora.

Los usos extendidos de claves (EKU) se configuran al crear cada CA. Los certificados de cliente WiFi necesitan el EKU de autenticación de cliente, por lo que debe incluirse en ambos niveles. Planifique esto con cuidado, ya que los EKU quedan fijos cuando se crea la CA.

Hay un límite importante que debe tenerse en cuenta para el diseño. Cloud PKI emite certificados para dispositivos gestionados por Intune a través de SCEP. No está diseñado para emitir el propio certificado de su servidor RADIUS, por lo que ese certificado suele proceder de una CA pública o de su PKI existente.

Comparativa de Cloud PKI con SCEP con NDES y PKCS

	Cloud PKI (SCEP)	SCEP con NDES	PKCS
Alojamientos de CA	Alojado por Microsoft en su inquilino de Intune	Su AD CS o CA de terceros	Su AD CS o CA de terceros
Servidores en la sede local	Ninguno	CA emisora, servidor NDES, host del conector	CA emisora, host del conector
Componente publicado en Internet	Ninguno	NDES, a través de proxy inverso o proxy de aplicaciones	Ninguno
Dónde se genera la clave privada	En el dispositivo	En el dispositivo	En el lado de la CA, entregada al dispositivo como PFX
Adecuación para entornos exclusivos de Entra ID	Nativa	Funciona, pero mantiene dependencias locales	Funciona, pero mantiene dependencias locales
Revocación	Revocación en el centro de administración de Intune, publicada por CRL	A través del conector y la CRL de su CA	A través del conector y la CRL de su CA
Modelo de licencias	Intune Suite o complemento Cloud PKI, por usuario	Licencias de Windows Server más Intune	Licencias de Windows Server más Intune
A quién se adapta	Entornos centrados en la nube que retiran su PKI local	Entornos con un equipo maduro de AD CS y una hoja de ruta de CA a largo plazo	Casos que necesitan la misma clave en más de una plataforma, como S/MIME

Nuestra guía independiente sobre el despliegue de certificados de Intune con SCEP y PKCS aborda en profundidad las dos rutas locales.

¿Qué necesita antes de desplegar Cloud PKI para EAP-TLS?

Compruebe estos seis elementos antes de crear nada. Cada uno corresponde a un fallo en la sección de resolución de problemas siguiente.

• Licencias. Una suscripción a Intune Plan 1 más Microsoft Intune Suite o el complemento independiente Cloud PKI.
• Permisos. El rol de Administrador de Intune, o un rol personalizado con los permisos de Cloud PKI.
• Dispositivos inscritos. Dispositivos Windows, macOS, iOS/iPadOS o Android inscritos en Intune, agrupados en grupos de seguridad de Microsoft Entra ID.
• Un servidor RADIUS compatible con EAP-TLS. Debe permitirle importar certificados de CA, acceder a la CRL de Cloud PKI mediante HTTP y asignar identidades de certificado a objetos de Entra ID. Microsoft NPS (Network Policy Server) busca cuentas en el Active Directory local, por lo que los dispositivos exclusivamente en la nube fallarán ahí.
• Un certificado de servidor RADIUS. También necesita la raíz y los certificados intermedios que lo emitieron, ya que los dispositivos deben validar el servidor.
• Puntos de acceso compatibles con 802.1X. Deben emitir un SSID WPA2-Enterprise o WPA3-Enterprise que apunte a su servidor RADIUS.

Por parte del punto de acceso, la gran mayoría de plataformas son compatibles con 802.1X. Esto incluye Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Para ver una guía paso a paso específica para cada fabricante, consulte Configuración de 802.1X en Juniper Mist con RADIUS en la nube.

¿Cómo se configuran los certificados de PKI en la nube para WiFi?

La siguiente secuencia resume la configuración. Utilice la documentación de PKI en la nube de Microsoft disponible en Microsoft Learn para consultar las pantallas actuales y los pasos detallados de cada campo, ya que el diseño del centro de administración varía entre versiones.

Paso 1: cree la CA raíz o aporte la suya propia

En el centro de administración de Intune, cree una CA raíz dentro de la administración del inquilino. Seleccione el tamaño de clave, el periodo de validez y los EKU, incluida la autenticación de cliente.

Para el modelo BYOCA, omita la raíz. Cree la CA emisora como tipo BYOCA y exporte su solicitud de firma de certificado. Firme la solicitud en su CA privada mediante una plantilla que incluya autenticación de cliente y, a continuación, cargue el certificado firmado y su cadena.

Paso 2: cree la CA emisora

Cree una CA emisora vinculada a la raíz del paso 1. Sus EKU deben incluir autenticación de cliente. Una vez creada, la página de propiedades mostrará tres elementos que necesitará más adelante:

• el URI de SCEP
• la descarga del certificado de la CA
• el punto de distribución de la CRL

Paso 3: implemente perfiles de certificado de confianza

Descargue los certificados de la CA raíz y de la CA emisora. Cree un perfil de certificado de confianza para cada uno de ellos por plataforma. Asígnelos a los mismos grupos que recibirán los perfiles de SCEP y WiFi.

Los dispositivos necesitan esta cadena antes de que el perfil SCEP pueda ejecutarse con éxito. Cree un perfil de certificado de confianza adicional para la CA que emitió el certificado de su servidor RADIUS si los dispositivos aún no confían en ella.

Paso 4: cree el perfil de certificado SCEP

Cree un perfil de certificado SCEP por plataforma y vincúlelo a la PKI en la nube. Estas son las decisiones clave:

• URL del servidor SCEP. Pegue la URI de SCEP de la CA emisora exactamente como se muestra. Deje el texto del marcadores de posición sin editar, ya que Intune lo resuelve durante la emisión.
• Certificado raíz. Seleccione el perfil de certificado de confianza correspondiente a la raíz de la PKI en la nube, no a la CA emisora.
• Tipo de certificado. Elija certificados de dispositivo para equipos compartidos, como tabletas de recepción o terminales de tienda. Elija certificados por persona cuando el personal lleve su propio portátil y desee asociar la directiva al usuario individual.
• Sujeto y nombre alternativo del sujeto (SAN). Incluya un identificador que su servidor RADIUS pueda vincular con Microsoft Entra ID. Algunos ejemplos son la variable de ID de dispositivo de Entra {{AAD_Device_ID}} o la variable UPN {{UserPrincipalName}}.
• Uso de clave y EKU. Establezca firma digital y cifrado de clave, junto con autenticación de cliente.
• Almacenamiento de claves en Windows. Inscriba en el proveedor de almacenamiento de claves del TPM (Trusted Platform Module), para que la clave privada quede vinculada al hardware y no se pueda exportar.
• Umbral de renovación. Establezca el porcentaje de vida útil restante en el que Intune renueva, para que los certificados nunca caduquen sin darse cuenta.

Paso 5: hacer que el servidor RADIUS confíe en Cloud PKI

Importe los certificados de la CA raíz y de la CA emisora de Cloud PKI en el almacén de CA de confianza de su servidor RADIUS. Importar solo la raíz es la causa más común de rechazos por "CA desconocida".

Habilite la comprobación CRL y permita que el servidor RADIUS tenga acceso HTTP saliente al punto de distribución CRL que figura en cada certificado. Con BYOCA, es posible que el servidor RADIUS ya confíe en su raíz, por lo que solo añadirá el nuevo certificado de la CA emisora.

Si el RADIUS en la nube de Purple autentica su WiFi de empleados, su equipo de cuenta de Purple le confirmará cómo se carga la cadena de Cloud PKI para su entorno.

Paso 6: crear el perfil de WiFi

Cree un perfil de WiFi en Intune con seguridad empresarial y EAP-TLS como tipo de EAP. Configure tres campos:

• Certificado de autenticación de cliente. Seleccione el perfil SCEP del paso 4.
• Certificados raíz para la validación del servidor. Seleccione el perfil de certificado de confianza para la raíz emisora de su servidor RADIUS.
• Nombres de servidores de certificados. Introduzca nombres que coincidan exactamente con el certificado del servidor RADIUS.

Asigne el perfil a los mismos grupos que los perfiles SCEP y de certificado de confianza.

¿Cómo funciona la revocación con Cloud PKI?

Puede revocar los certificados de Cloud PKI desde la CA emisora en el centro de administración de Intune. Abra la lista de certificados emitidos, seleccione el certificado del dispositivo y revóquelo. A continuación, Cloud PKI publica el cambio en su CRL (lista de revocación de certificados), situada en el punto de distribución HTTP integrado en cada certificado que emite.

Su servidor RADIUS aplica la revocación, no Intune. Descarga la CRL y rechaza cualquier certificado cuyo número de serie aparezca en ella.

La mayoría de los servidores RADIUS almacenan en caché una CRL hasta la hora de su próxima actualización. Por lo tanto, un dispositivo revocado puede seguir conectándose hasta que el servidor RADIUS obtenga una lista actualizada. Reduzca esa ventana de tres formas:

1. Revoque de forma explícita. No confíe únicamente en eliminar la asignación de un perfil o borrar el registro de un dispositivo. Revoque el certificado en sí como parte de su proceso de altas, cambios y bajas de personal.
2. Combine la revocación con verificaciones de identidad. Si su servicio RADIUS comprueba el estado del dispositivo o la cuenta de Microsoft Entra ID en cada autenticación, deshabilitar la cuenta bloquea el acceso antes de que se actualice la CRL.
3. Supervise la obtención de la CRL. Genere alertas si se producen fallos al descargar la CRL. Un servidor RADIUS que contenga una CRL desactualizada seguirá admitiendo dispositivos revocados o rechazará todos los dispositivos, según su directiva de fallos.

¿Cómo comprobar que la autenticación WiFi con Cloud PKI funciona?

Realice una prueba piloto con un grupo de control de cinco a 10 dispositivos en cada plataforma compatible. Confirme cinco aspectos:

1. Estado del perfil. Los perfiles de certificado de confianza, SCEP y WiFi notifican un estado correcto en los informes de configuración de dispositivos de Intune.
2. Certificado en el dispositivo. En Windows, el certificado aparece en el almacén personal con el asunto, el SAN y el EKU de Autenticación de cliente esperados. Su cadena debe construirse hasta la raíz de Cloud PKI.
3. Registro de emisión. El certificado aparece en la lista de certificados emitidos de la CA emisora en el centro de administración de Intune.
4. Registros de RADIUS. El registro de autenticación muestra que EAP-TLS se ha completado con éxito, la identidad esperada y una cadena válida.
5. Prueba de revocación. Revoque un certificado de prueba. Una vez que el servidor RADIUS obtenga la nueva CRL, confirme que el dispositivo sea rechazado.

Ejecute la prueba de revocación antes de pasar a producción. Es la única comprobación que demuestra que su servidor RADIUS puede acceder a la CRL.

¿Qué suele fallar con Cloud PKI EAP-TLS y cómo solucionarlo?

Síntoma	Causa probable	Solución
Perfil SCEP bloqueado en error o pendiente	Los perfiles de certificado de confianza no están asignados al mismo grupo, o el perfil SCEP hace referencia a la CA emisora en lugar de a la raíz	Asigne los perfiles de confianza raíz y emisor a los mismos grupos, y seleccione la raíz en el perfil SCEP
Certificado emitido, RADIUS rechaza con "CA desconocida"	Solo se ha importado la raíz en RADIUS	Importe también el certificado de la CA emisora
Todos los dispositivos son rechazados tras la puesta en marcha	RADIUS no puede acceder al punto de distribución de la CRL y se bloquea por seguridad	Permita el tráfico HTTP saliente desde RADIUS hacia el host de la CRL
Los dispositivos Android se niegan a conectarse	No se ha configurado la validación del servidor; Android 11 y versiones posteriores la requieren	Despliegue la raíz del servidor RADIUS como un perfil de confianza y configure los nombres del servidor de certificados
Windows solicita al personal que confíe en el servidor	Los nombres de servidor en el perfil WiFi no coinciden con el certificado de RADIUS	Corrija los nombres de servidor para que coincidan exactamente con el certificado
NPS rechaza los dispositivos unidos a Microsoft Entra ID	NPS busca una cuenta de Active Directory local que no existe	Utilice un servicio RADIUS que vincule certificados con objetos de Microsoft Entra ID
El dispositivo revocado se sigue conectando	RADIUS conserva una CRL en caché	Combine la revocación con la deshabilitación de la cuenta o dispositivo en Microsoft Entra ID, y revise el almacenamiento en caché de la CRL
El certificado carece de Autenticación de cliente	La CA emisora se creó sin ese EKU	Cree una nueva CA emisora con Autenticación de cliente y vuelva a vincular el perfil SCEP

Si los fallos se concentran en salas o plantas concretas mientras los mismos dispositivos se autentican correctamente en otros lugares, el problema radica en la cobertura de radio, no en la PKI. EAP-TLS intercambia más paquetes que un proceso de negociación mediante clave compartida (PSK), por lo que las señales débiles se traducen en tiempos de espera agotados. WiFi Site Surveys: A Practical Planning Guide explica cómo identificar esas brechas.

Cloud PKI o SCEP con NDES: ¿cuál debería elegir?

Base la decisión en lo que ya esté utilizando y en lo que planee retirar.

Su situación	Recomendación	Motivo
Flota unida a Microsoft Entra ID, sin AD CS	Cloud PKI con una raíz de Cloud PKI	Sin necesidad de implementar ni administrar una PKI local
AD CS activo, servidores NDES pendientes de actualización de SO	PKI en la nube con BYOCA	Mantiene su confianza raíz existente y retira NDES y el conector
Equipo de AD CS con una hoja de ruta de CA a largo plazo y otras plantillas de certificados	SCEP con NDES, revisar en la próxima actualización de servidores	La inversión existente ya cubre casos de uso que no son de WiFi
Necesidad del mismo par de claves en varios dispositivos, como S/MIME	PKCS para ese caso de uso, PKI en la nube para WiFi	PKCS ofrece claves exportables; los certificados WiFi deben permanecer vinculados al dispositivo
Dispositivos con unión híbrida en NPS hoy, migrando a unión con Entra ID	PKI en la nube más un servicio RADIUS en la nube	Las búsquedas de NPS dejan de funcionar una vez que los dispositivos salen de Active Directory

Las entidades reguladas en Sanidad a menudo conservan AD CS para otras cargas de trabajo. Para ellas, BYOCA suele ser la mejor opción, ya que mantiene una única raíz de confianza en toda la organización. Los operadores ferroviarios que emiten certificados a las tabletas del personal a bordo en Trenes suelen optar por la ruta de raíz de PKI en la nube. Esos dispositivos se gestionan desde la nube desde el primer día.

¿Cuánto cuesta la PKI en la nube y qué obtiene a cambio?

Microsoft licencia la PKI en la nube por usuario y mes. Se incluye dentro de Intune Suite o como un complemento independiente, sobre Intune Plan 1. Consulte la lista de precios actual de Microsoft, ya que las ofertas del paquete pueden cambiar.

Compare eso con lo que le cuesta la opción local:

• Licencias de Windows Server y máquinas virtuales para la CA de emisión, NDES y hosts de conectores
• El proxy inverso o proxy de aplicaciones que publica NDES
• Copias de seguridad de la base de datos de la CA
• Aplicación de parches y administración de plantillas de certificados

El beneficio es un menor número de servidores, ningún punto de enlace NDES publicado en Internet y claves vinculadas a dispositivos en cada plataforma que gestione.

Escenario práctico: un grupo hotelero de 30 propiedades

Situación. Un grupo de 30 hoteles utilizaba 900 portátiles y tabletas de recepción unidos a Entra ID en un SSID para el personal protegido con una clave precompartida única. Rotar esa clave cada trimestre implicaba intervenir en cada dispositivo de cada propiedad. La pérdida de una tableta dejaba la clave expuesta hasta la siguiente rotación.

Qué se hizo. El equipo de TI creó una raíz de PKI en la nube y una CA de emisión, y luego emitió certificados de dispositivo respaldados por TPM a través de SCEP. Un servicio RADIUS en la nube validó la cadena y comprobó la CRL. El grupo ejecutó un SSID EAP-TLS junto al antiguo durante la fase piloto, migró las propiedades por fases y luego desactivó la red de clave precompartida.

Resultado. El cálculo de este escenario es sencillo:

• Los secretos compartidos en la red del personal pasan de uno a cero.
• La rotación trimestral de claves en las 30 propiedades se elimina por completo.
• La pérdida de una tableta se convierte en la revocación de un único certificado en lugar de tener que volver a cambiar la clave de 900 dispositivos.
• No se requiere ninguna CA local, servidor NDES ni conector.

Escenario práctico: una cadena minorista de 250 tiendas

Situación. Una cadena de venta al por menor emitió certificados WiFi a 4000 dispositivos de mano y portátiles de tiendas a través de AD CS y dos servidores NDES. El Intune Certificate Connector se ejecutaba en un tercer servidor. Los tres servidores debían sustituir su sistema operativo y NDES se publicó a través de un proxy de aplicaciones.

Lo que se hizo. El equipo creó una CA emisora de Cloud PKI como BYOCA y la firmó con la CA raíz existente de AD CS. Como el servidor RADIUS ya confiaba en esa CA raíz, solo se importó el certificado de la nueva CA emisora. Los perfiles SCEP se migraron a Cloud PKI grupo de tiendas por grupo de tiendas. Los certificados existentes siguieron siendo válidos hasta su renovación, lo que mantuvo la opción de reversión.

Resultado. La cadena retiró tres servidores: dos NDES y un host conector. También eliminó el punto de acceso NDES publicado en internet. No hizo falta volver a configurar la confianza de la CA raíz en RADIUS ni en ningún dispositivo. La CA raíz de AD CS permaneció activa para otras cargas de trabajo.

Dónde encaja Purple

Purple Staff WiFi utiliza redes basadas en la identidad con RADIUS en la nube, conectado a Microsoft Entra ID, Okta o Google Workspace. Purple es independiente del hardware y funciona con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. En Por qué su próxima actualización de WiFi no requiere hardware nuevo se explica por qué migrar al acceso del personal basado en certificados rara vez implica sustituir los puntos de acceso.

Purple se ejecuta en más de 80 000 ubicaciones activas (datos de Purple) con un tiempo de actividad del 99,999 % y cuenta con la certificación ISO 27001. Mantenga al personal y a los visitantes en redes independientes: WiFi para el personal basado en certificados para los dispositivos que usted gestiona, y WiFi para invitados para todos los demás.

Preguntas frecuentes

¿Puede Microsoft Cloud PKI emitir certificados WiFi?

Sí. Cloud PKI emite certificados de autenticación de clientes a dispositivos Windows, macOS, iOS/iPadOS y Android gestionados por Intune mediante un perfil de certificado SCEP. Dichos certificados autentican los dispositivos en redes WPA2-Enterprise o WPA3-Enterprise con EAP-TLS. Su CA emisora debe incluir el EKU de autenticación de cliente y su servidor RADIUS debe confiar en la CA raíz y la CA emisora de Cloud PKI. Por lo general, Cloud PKI no emite el certificado propio del servidor RADIUS. Ese certificado proviene de una CA pública o de su PKI existente.

¿Sigue siendo necesario NDES con Cloud PKI?

No. Cloud PKI responde a las solicitudes SCEP por sí mismo, por lo que no necesita ningún servidor NDES, conector de certificados de Intune ni proxy inverso que publique NDES en internet. El perfil SCEP en Intune apunta directamente al URI de SCEP que se muestra en su CA emisora de Cloud PKI. Si utiliza la opción de aportar su propia CA, su CA raíz privada firma la CA emisora de Cloud PKI una sola vez. A partir de ese momento, la inscripción de dispositivos nunca interactúa con sus servidores locales.

¿Cómo confía el servidor RADIUS en los certificados de Cloud PKI?

Debe importar los certificados raíz e CA de emisión de Cloud PKI en el almacén de CA de confianza del servidor RADIUS. Descargue ambos desde el centro de administración de Intune. Importe ambos, ya que importar solo la raíz provoca rechazos por "CA desconocida". El servidor RADIUS también necesita acceso HTTP saliente al punto de distribución de CRL de cada certificado para poder comprobar la revocación. Para los dispositivos unidos a Microsoft Entra ID, debe mapear las identidades de los certificados a Microsoft Entra ID en lugar de Active Directory en local.

¿Cómo funciona la revocación con Cloud PKI?

Puede revocar un certificado desde la CA de emisión en el centro de administración de Intune, y Cloud PKI publicará el cambio en su CRL. Su servidor RADIUS descargará esa CRL y rechazará los certificados revocados. Debido a que los servidores RADIUS guardan las CRL en caché, es posible que un dispositivo revocado se conecte hasta la siguiente actualización. Elimine ese riesgo desactivando también la cuenta o el dispositivo en Microsoft Entra ID, siempre que su servicio RADIUS compruebe el estado de la identidad en cada autenticación.

¿Debería elegir Cloud PKI o SCEP con NDES?

Elija Cloud PKI si gestiona un parque de dispositivos unidos a Microsoft Entra ID o si tiene previsto retirar los servidores PKI en local. Esto elimina la CA de emisión, el NDES y los hosts conectores. Mantenga SCEP con NDES si cuenta con un equipo experimentado en AD CS, una hoja de ruta de CA a largo plazo y otras plantillas de certificados. Si necesita actualizar sus servidores NDES, Cloud PKI con BYOCA le permite mantener su confianza de raíz existente y retirar NDES de todos modos.

¿Cómo se licenciará Microsoft Cloud PKI?

Cloud PKI se licencia por usuario y mes, como complemento de Intune Plan 1. Se incluye como parte de Microsoft Intune Suite o como un complemento independiente de Cloud PKI. Consulte la lista de precios actual de Microsoft antes de elaborar el presupuesto, ya que los paquetes cambian. Compare el coste de la licencia con el gasto de las licencias de Windows Server, las máquinas virtuales, la publicación de proxies y las tareas de parcheo que requiere una infraestructura de AD CS, NDES y conectores.

¿Puedo mantener mi CA raíz en local existente con Cloud PKI?

Sí, a través de la opción «traiga su propia CA» (BYOCA). Crea una CA de emisión de Cloud PKI, exporta su solicitud de firma de certificado y la firma con su CA raíz privada existente, como AD CS. Cualquier elemento que ya confíe en esa raíz, incluidos su servidor RADIUS y sus dispositivos, confiará en la nueva cadena. Solo tendrá que añadir el certificado de la CA de emisión. Puede migrar los perfiles SCEP grupo por grupo mientras los certificados existentes siguen siendo válidos hasta su renovación.

¿Funciona Cloud PKI con mis puntos de acceso actuales?

Sí, siempre que sus puntos de acceso admita 802.1X con WPA2 u WPA3. Cloud PKI solo afecta a los certificados de los dispositivos y a la confianza en su servidor RADIUS. Los puntos de acceso simplemente reenvían la autenticación a RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks y Fortinet son compatibles. La solución Staff WiFi de Purple funciona en las ocho marcas como una superposición en la nube independiente del hardware.