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 un servidor NDES, un conector de certificados ni una CA local. Su servidor RADIUS confía en la raíz importada de Cloud PKI y verifica 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 mediante certificados. IEEE 802.1X es el estándar de control de acceso basado en puertos que respalda a 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 pueda ser objeto de phishing ni clave compartida que se pueda filtrar. Cada dispositivo conserva su propia clave privada y certificado.

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

• una CA emisora de Servicios de certificados de Active Directory (AD CS)
• un servidor NDES (Servicio de inscripción de dispositivos de red)
• el conector de certificados de Intune
• un proxy inverso o Microsoft Entra application proxy para publicar NDES en internet

Cada uno de ellos requiere parches, copias de seguridad y monitoreo.

Microsoft Cloud PKI reemplaza esa estructura con una autoridad de certificación alojada en su tenant de Intune. Los dispositivos solicitan certificados a través de SCEP (Simple Certificate Enrollment Protocol), y Cloud PKI responde a esas solicitudes directamente. 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 los entornos unidos a Entra ID, esto elimina la última dependencia local en 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 CAs emisoras, y la CA emisora firma los certificados de los dispositivos. Microsoft resguarda las claves de firma de la CA en módulos de seguridad de hardware (HSM), por lo que usted nunca gestiona el material de las claves.

Puede elegir uno de dos anclajes:

• Raíz de Cloud PKI. Microsoft aloja tanto la raíz como la CA emisora en su tenant. Esta es la opción más sencilla para un entorno totalmente nuevo de Entra ID.
• Traiga su propia 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.

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

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

Comparación de Cloud PKI con SCEP con NDES y PKCS

	Cloud PKI (SCEP)	SCEP con NDES	PKCS
Alojamiento 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 localizados	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
Adecuado para entornos exclusivos de Entra ID	Nativo	Funciona, pero mantiene dependencias localizadas	Funciona, pero mantiene dependencias localizadas
Revocación	Revocar en el centro de administración de Intune, publicado 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 licencia	Intune Suite o complemento de 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 la PKI localizada	Entornos con un equipo maduro de AD CS y un plan 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 la implementación de certificados de Intune con SCEP y PKCS cubre a fondo las dos rutas localizadas.

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

Verifique estos seis elementos antes de crear cualquier cosa. Cada uno corresponde a una falla en la sección de solución de problemas a continuación.

• Licenciamiento. Una suscripción a Intune Plan 1 más la Microsoft Intune Suite o el complemento independiente de 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 CA, alcanzar la CRL de Cloud PKI a través de HTTP y mapear identidades de certificados a objetos de Entra ID. Microsoft NPS (Network Policy Server) busca cuentas en Active Directory localizado, por lo que los dispositivos exclusivos de la nube fallarán allí.
• Un certificado de servidor RADIUS. También necesita la raíz y los certificados intermedios que lo emitieron, porque los dispositivos deben validar el servidor.
• Puntos de acceso compatibles con 802.1X. Estos deben transmitir un SSID WPA2-Enterprise o WPA3-Enterprise apuntando a su servidor RADIUS.

Del lado del punto de acceso, cada plataforma principal es compatible 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 de cada proveedor, consulte Configuración de 802.1X en Juniper Mist con RADIUS en la nube.

¿Cómo configurar certificados de Cloud PKI para WiFi?

La siguiente secuencia resume la configuración. Utilice la documentación de Cloud PKI de Microsoft en Microsoft Learn para consultar las pantallas actuales y los pasos campo por campo, ya que el diseño del centro de administración cambia entre versiones.

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

En el centro de administración de Intune, cree una CA raíz en la administración del inquilino. Elija el tamaño de la clave, el período de validez y los EKU, incluida la Autenticación de cliente.

Para BYOCA, omita la raíz. Cree la CA emisora como un tipo BYOCA y exporte su solicitud de firma de certificado. Firme la solicitud en su CA privada utilizando 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 anclada a la raíz del paso 1. Sus EKU deben incluir Autenticación de cliente. Una vez creada, su página de propiedades muestra tres elementos que necesitará más adelante:

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

Paso 3: implemente perfiles de certificados 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, 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 de SCEP pueda completarse 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 apúntelo a Cloud PKI. Estas son las decisiones clave:

• URL del servidor SCEP. Pegue el URI de SCEP de la CA emisora exactamente como se muestra. Deje el texto de marcador de posición sin editar, ya que Intune lo resuelve en el momento de la emisión.
• Certificado raíz. Seleccione el perfil de certificado de confianza para la raíz de Cloud PKI, no para la CA emisora.
• Tipo de certificado. Elija certificados de dispositivo para dispositivos compartidos, como tabletas de recepción o terminales portátiles de tiendas. Elija certificados por persona cuando el personal lleve su propia laptop y desee que la directiva esté vinculada al individuo.
• Nombre del sujeto y nombre alternativo del sujeto (SAN). Incluya un identificador que su servidor RADIUS pueda mapear con Microsoft Entra ID. Por ejemplo, la variable de ID de dispositivo de Entra {{AAD_Device_ID}} o la variable UPN {{UserPrincipalName}}.
• Uso de claves y EKU. Configure Firma digital y Cifrado de claves, con Autenticación de cliente.
• Almacenamiento de claves en Windows. Inscriba en el proveedor de almacenamiento de claves 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: haga 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 los rechazos por "CA desconocida".

Habilite la comprobación CRL y permita al servidor RADIUS el 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 certificado de la nueva CA emisora.

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

Paso 6: cree 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 servidor de certificados. Ingrese 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?

Los certificados de Cloud PKI se revocan 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), que se encuentra en el punto de distribución HTTP incorporado 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 nueva. Cierre esa ventana de tres maneras:

1. Revoque explícitamente. No confíe 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 (JML).
2. Combine la revocación con comprobaciones de identidad. Si su servicio RADIUS comprueba el estado del dispositivo o de la cuenta de Microsoft Entra ID en cada autenticación, deshabilitar la cuenta bloquea el acceso antes de que se actualice la CRL.
3. Monitoree la recuperación de la CRL. Genere alertas para descargas de CRL fallidas. Un servidor RADIUS que conserva una CRL desactualizada seguirá admitiendo dispositivos revocados o rechazará todos los dispositivos, según su directiva de fallos.

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

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

1. Estado del perfil. Los perfiles de certificado de confianza, SCEP y WiFi reportan un resultado exitoso 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, SAN y EKU de Client Authentication 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 el éxito de EAP-TLS, 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 salir a producción. Es la única comprobación que demuestra que su servidor RADIUS puede alcanzar la CRL.

¿Qué puede salir mal con Cloud PKI EAP-TLS y cómo se soluciona?

Síntoma	Causa probable	Solución
Perfil SCEP atascado 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 importó la raíz en RADIUS	Importe también el certificado de la CA emisora
Todos los dispositivos son rechazados tras la salida a producción	RADIUS no puede alcanzar el punto de distribución de la CRL y falla en modo cerrado	Permita el tráfico HTTP saliente desde RADIUS hacia el host de la CRL
Los dispositivos Android se niegan a conectarse	No se configuró 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 del servidor en el perfil de WiFi no coinciden con el certificado de RADIUS	Corrija los nombres del 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 mapee certificados a objetos de Microsoft Entra ID
El dispositivo revocado aún se conecta	RADIUS conserva una CRL en caché	Combine la revocación con la deshabilitación de la cuenta o del dispositivo en Microsoft Entra ID, y revise el almacenamiento en caché de la CRL
El certificado carece de Client Authentication	La CA emisora se creó sin ese EKU	Cree una nueva CA emisora con Client Authentication y vuelva a vincular el perfil SCEP

Si las fallas se concentran en salas o pisos particulares mientras los mismos dispositivos se autentican en otros lugares, la falla es de cobertura de radio, no de PKI. EAP-TLS intercambia más paquetes que un intercambio de clave precompartida, por lo que una señal débil se manifiesta como tiempos de espera agotados. WiFi Site Surveys: A Practical Planning Guide explica cómo encontrar esas brechas.

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

Base la decisión en lo que ya ejecuta y en lo que planea retirar.

Su situación	Recomendación	Por qué
Flota unida a Microsoft Entra ID, sin AD CS	Cloud PKI con una raíz de Cloud PKI	Sin PKI local que construir o administrar
AD CS en funcionamiento, servidores NDES pendientes de actualización de SO	PKI en la nube con BYOCA	Mantiene su confianza de raíz existente y retira NDES y el conector
Equipo de AD CS con un plan de trabajo 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 ajenos a WiFi
Necesita el mismo par de claves en varios dispositivos, como S/MIME	PKCS para ese caso de uso, PKI en la nube para WiFi	PKCS entrega claves exportables; los certificados WiFi deben permanecer vinculados al dispositivo
Dispositivos con unión híbrida en NPS hoy, migrando a unión con Microsoft Entra ID	PKI en la nube más un servicio RADIUS en la nube	Las búsquedas de NPS dejan de funcionar cuando los dispositivos abandonan Active Directory

Las propiedades reguladas en Atención médica a menudo conservan AD CS para otras cargas de trabajo. Para ellas, BYOCA suele ser la mejor opción, ya que mantiene una sola raíz de confianza en toda la organización. Los operadores ferroviarios que emiten certificados para las tabletas del personal a bordo en Trenes tienden a ajustarse a 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, por mes. Se incluye dentro de Intune Suite o como un complemento independiente, además de Intune Plan 1. Consulte la lista de precios actual de Microsoft, ya que los paquetes cambian.

Compare eso con lo que le cuesta la ruta 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 retorno es menos servidores, ningún extremo 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 ejecutaba 900 laptops y tabletas de recepción unidas a Microsoft Entra ID en un SSID de personal asegurado con una sola clave compartida previamente. Rotar esa clave cada trimestre significaba intervenir cada dispositivo en cada propiedad. Una tableta perdida dejaba la clave expuesta hasta la siguiente rotación.

Lo que se hizo. El equipo de TI creó una raíz de PKI en la nube y una CA de emisión, luego emitió certificados de dispositivo respaldados por TPM a través de SCEP. Un servicio RADIUS en la nube validó la cadena y verificó la CRL. El grupo ejecutó un SSID EAP-TLS junto con el antiguo para la prueba piloto, migró las propiedades por fases y luego desactivó la red de clave compartida previamente.

Resultado. El cálculo del escenario es sencillo:

• Los secretos compartidos en la red del personal bajan de uno a cero.
• La rotación trimestral de claves en 30 propiedades se detiene por completo.
• Una tableta perdida se convierte en una revocación de certificado en lugar de 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 retail emitió certificados WiFi a 4,000 terminales portátiles y laptops de tienda 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 renovar su sistema operativo y NDES se publicaba 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 raíz existente de AD CS. El servidor RADIUS ya confiaba en esa raíz, por lo que solo se importó el nuevo certificado de la CA emisora. Los perfiles SCEP se migraron a Cloud PKI, un grupo de tiendas a la vez. Los certificados existentes permanecieron válidos hasta su renovación, lo que conservó la opción de reversión.

Resultado. La cadena retiró tres servidores: dos NDES y un host del conector. También eliminó el extremo NDES publicado en Internet. No se necesitó volver a configurar la confianza de la raíz en RADIUS ni en ningún dispositivo. La raíz de AD CS se mantuvo en su lugar para otras cargas de trabajo.

Dónde encaja Purple

Purple Staff WiFi utiliza Redes Basadas en Identidad con RADIUS en la nube, conectado a Microsoft Entra ID, Okta o Google Workspace. Purple es independiente del hardware en Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Por qué su próxima actualización de WiFi no necesita hardware nuevo explica por qué migrar al acceso de personal basado en certificados raras veces implica reemplazar los puntos de acceso.

Purple opera 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 separadas: Staff WiFi basado en certificados para los dispositivos que usted administra, y Guest WiFi para todos los demás.

Preguntas frecuentes

¿Puede Microsoft Cloud PKI emitir certificados WiFi?

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

¿Aún necesito NDES con Cloud PKI?

No. Cloud PKI responde a las solicitudes SCEP por sí mismo, por lo que no necesita un servidor NDES, ni Intune Certificate Connector, ni un reverse proxy que publique NDES en Internet. El perfil SCEP en Intune apunta directamente a la URI de SCEP que se muestra en su CA emisora de Cloud PKI. Si utiliza la opción de aportar su propia CA, su raíz privada firma la CA emisora de Cloud PKI una sola vez. Después de eso, el registro de dispositivos nunca toca sus servidores locales.

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

Usted importa los certificados de la entidad de certificación (CA) raíz y emisora 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 en cada certificado para que pueda verificar la revocación. Para los dispositivos unidos a Entra ID, debe mapear las identidades de los certificados a Entra ID en lugar de Active Directory en las instalaciones.

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

Usted revoca un certificado de la CA emisora en el centro de administración de Intune y Cloud PKI publica el cambio en su CRL. Su servidor RADIUS descarga esa CRL y rechaza los certificados revocados. Debido a que los servidores RADIUS almacenan en caché las CRL, un dispositivo revocado puede conectarse hasta la siguiente actualización. Cierre esa brecha desactivando también la cuenta de Entra ID o el dispositivo, siempre que su servicio RADIUS verifique el estado de la identidad en cada autenticación.

¿Debo elegir Cloud PKI o SCEP con NDES?

Elija Cloud PKI si administra un parque de dispositivos unidos a Entra ID o si planea retirar los servidores PKI en las instalaciones. Elimina la CA emisora, 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 sus servidores NDES requieren una actualización, Cloud PKI con BYOCA mantiene su confianza raíz existente y aun así retira NDES.

¿Cómo se licencian los servicios de Microsoft Cloud PKI?

Cloud PKI se licencia por usuario, por mes, además 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 presupuestar, ya que los paquetes cambian. Compare el costo de la licencia con el esfuerzo de licencias de Windows Server, máquinas virtuales, publicación de proxies y parches que requiere un entorno de AD CS, NDES y conectores.

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

Sí, a través de la opción bring-your-own-CA. Usted crea una CA emisora 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 debe agregar el certificado de la CA emisora. Puede migrar los perfiles SCEP grupo por grupo mientras los certificados existentes siguen siendo válidos hasta su renovación.

¿Cloud PKI funciona con mis puntos de acceso existentes?

Sí, siempre que sus puntos de acceso admitan 802.1X con WPA2-Enterprise o WPA3-Enterprise. Cloud PKI solo afecta a los certificados en 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 y Fortinet son compatibles. Staff WiFi de Purple funciona en las ocho plataformas como una superposición en la nube independiente del hardware.