Comunicación de Microsoft CA 

Cuando las organizaciones necesitan proteger las comunicaciones digitales, verificar identidades o permitir el acceso seguro a los recursos de red, suelen recurrir a la tecnología de Infraestructura de Clave Pública (PKI). En el núcleo de la PKI se encuentra la Autoridad de Certificación (CA), una entidad de confianza responsable de emitir, gestionar y validar certificados digitales. Estos certificados son credenciales electrónicas que vinculan una clave pública a la identidad de un usuario, ordenador o dispositivo, lo que permite una comunicación segura y cifrada, la autenticación y las firmas digitales. 

Este artículo tiene como objetivo ayudar a los profesionales de TI a diagnosticar y resolver problemas de comunicación de CA, garantizando que los certificados digitales puedan emitirse, validarse y utilizarse de manera confiable para operaciones seguras. 

Microsoft implementa esta tecnología denominada Servicios de Certificados de Active Directory (AD CS). AD CS es un rol de Windows Server que permite a las organizaciones crear y administrar su propia CA interna. AD CS permite la emisión de una amplia gama de tipos de certificados, entre ellos: 

• Certificados de usuario: Se utilizan para la autenticación de usuarios, correo electrónico seguro (S/MIME) y firmas digitales.
• Certificados de máquina (computadora): Habilite la autenticación, el cifrado y las comunicaciones seguras de computadoras y servidores. 
• Certificados de servidor web: Proteja servidores web y aplicaciones mediante encriptación SSL/TLS.
• Certificados de firma de código: Se utilizan para firmar software y scripts para garantizar su integridad y autenticidad.
• Certificados de VPN y acceso remoto: Conexiones remotas seguras a través de VPN y otras tecnologías de acceso remoto. 
• Certificados de dispositivos de red: Autenticar dispositivos como enrutadores, conmutadores y firewalls que pueden no tener cuentas de dominio.
• Certificados de tarjeta inteligente: Habilite la autenticación fuerte para los usuarios a través de tarjetas inteligentes o tokens de hardware.

Los certificados proporcionados por AD CS ayudan a garantizar: 

• Confidencialidad: Sólo los destinatarios previstos podrán leer los datos cifrándolos. 
• Integridad: Firmar digitalmente los datos para evitar su manipulación.  
• Autenticación: Confirmando la identidad de los usuarios, computadoras o dispositivos que acceden a los recursos de la red.

Microsoft implementa esta tecnología a través de Active Directory Certificate Services (AD CS), una función de Windows Server que permite a las organizaciones crear y administrar su propia autoridad de certificación (CA) interna.

Una CA de Microsoft puede configurarse de varias maneras, incluyendo como CA raíz (el ancla de confianza de su organización) o como CA subordinada (que emite certificados bajo la autoridad de la CA raíz). Las CA empresariales se integran con Active Directory, lo que permite la emisión y gestión automatizadas de certificados, mientras que las CA independientes operan de forma independiente y requieren la aprobación manual de las solicitudes de certificado. 

Garantizar una comunicación fiable con su entidad de certificación (CA) de Microsoft es fundamental para cualquier organización que utilice los Servicios de certificados de Active Directory (AD CS) para la emisión segura de certificados, la autenticación o la integración con plataformas de terceros. Supongamos que tiene problemas con las solicitudes de certificados, las renovaciones o los fallos de integración. En ese caso, esta guía paso a paso le ayudará a verificar y resolver sistemáticamente los problemas de comunicación con la CA de Microsoft. En primer lugar, veamos las diferencias entre una CA pública y una MSCA. 

CA de Microsoft frente a CA pública

Para ayudar a comprender el alcance de Microsoft CA, aquí hay una breve comparación con las CA públicas: 

Fecha de la función	Microsoft CA (AD CS)	CA pública (por ejemplo, DigiCert, Let's Encrypt)
Despliegue	Local, gestionado internamente	Basado en la nube, administrado por el proveedor
Alcance de la confianza	Usuarios internos, sistemas y servicios	Confianza pública en todos los navegadores y dispositivos
Modelo de validación	Automatización basada en AD	Validación de dominio (DV), organización (OV) o extendida (EV)
Modelo de costo	Costos de infraestructura y mantenimiento	Tarifa por certificado o suscripción
Ideal para	Aplicaciones internas, servidores, dispositivos, VPN, S/MIME	Sitios web, aplicaciones externas, API
Soporte y SLA	Soporte interno de TI o Microsoft	SLA proporcionados por el proveedor, soporte

Guía paso por paso  

1. Confirme que el servicio CA de Microsoft se esté ejecutando 

Comenzaremos por asegurarnos de que el servicio de la CA esté activo en el servidor. Antes de solucionar cualquier problema relacionado con los certificados, siempre confirme que el servicio de la CA se esté ejecutando en el servidor. Esto es fundamental, ya que si el servicio de la CA se detiene, no se podrán procesar las solicitudes de certificado y cualquier solución de problemas posterior será ineficaz y se perderá un tiempo valioso. Abra una ventana de PowerShell y ejecute: 

Obtener certificado de servicio vc 

El resultado debería indicar que el estado del servicio es "En ejecución". Como alternativa, puede abrir la consola de administración de servicios (services.msc) y comprobar que los "Servicios de certificados de Active Directory" se estén ejecutando. 

Si el servicio se detiene, un reinicio rápido suele resolver el problema. Use el siguiente comando de PowerShell para iniciar o reiniciar el servicio: 

Reiniciar el servicio certsvc

Después de reiniciar el servicio, revise siempre el Visor de eventos de Windows para ver si hay errores o advertencias relacionados con el servicio. Abra el Visor de sucesos buscando eventvwr.msc. Navegar a Registros de aplicaciones y servicios > Microsoft > Windows > Autoridad de certificación.

Revise los eventos recientes en busca de errores, advertencias o mensajes informativos relacionados con el servicio de CA. Preste especial atención a los registros con ID de evento como 58 (problemas con la cadena de certificados), 4886 (solicitudes de certificados) y otras entradas relevantes, ya que pueden proporcionar información sobre problemas subyacentes o confirmar operaciones exitosas. 

2. Verificar la conectividad de la red y los puertos necesarios 

Asegúrese de que puertos necesarios están abiertos a la comunicación de CA. 

Puertos requeridos: 

• TCP 135 – Mapeador de puntos finales RPC
  Se utiliza para la negociación inicial cliente/servidor para la comunicación RPC. 
• TCP 445 – SMB (utilizado para plantillas de certificados y políticas de grupo)
  Es necesario para acceder a las plantillas de certificado (almacenadas en AD), la distribución de GPO y DCOM.
• Puertos RPC dinámicos – TCP 49152–65535 (para Windows Server 2012 y versiones posteriores) 
  Se utiliza después de que RPC Endpoint Mapper asigna un puerto alto para la comunicación.
• TCP 88 – Kerberos (para autenticación de dominio) 
  Maneja la autenticación de dominio cuando un usuario o computadora solicita certificados.

¿Por qué son importantes estos puertos?

• Kerberos (TCP 88): Necesario para que las máquinas unidas al dominio se autentiquen en la CA, especialmente durante la inscripción automática o el acceso a la plantilla de certificado. 
• PYME (TCP 445): El acceso a las plantillas de certificados y políticas de CA almacenadas en Active Directory depende de SMB.
• Puertos RPC/altos (TCP 135 + 49152–65535): Núcleo para llamadas DCOM y RPC utilizadas por certreq, certutil, complementos MMC y al solicitar certificados de forma remota.

Prueba de conectividad mediante PowerShell: 

Conexión de red de prueba - Nombre del equipo -Puerto 135

Una prueba exitosa indica que el puerto está abierto. 

Problemas comunes: 

Firewalls que bloquean los puertos requeridos. Para listar todas las reglas de firewall que pueden afectar las comunicaciones de CA: 

Obtener regla de firewall de red 

La segmentación de la red impide la comunicación. 

Prueba de conectividad usando Telnet (si está instalado): 

Telnet 135
Telnet 445 

Si la pantalla se queda en blanco después de presionar Enter, el puerto está abierto. 
Si dice “No se pudo abrir la conexión”, el puerto está bloqueado. 

3. Pruebe la capacidad de respuesta de CA con Certutil 

Verifique que la CA sea accesible y responda. Si falla, indica que su sistema no puede comunicarse correctamente con la Autoridad de Certificación (CA). Este fallo puede implicar varios problemas subyacentes que se mencionan a continuación: 

Pasos: 

Abra el Símbolo del sistema o PowerShell en un equipo cliente y ejecute el siguiente comando. También se recomienda que... certutil El comando se puede probar tanto desde el cliente como desde el propio servidor CA. 

certutil -config – -ping 

Se le pedirá que seleccione la CA. Una respuesta correcta confirma que se puede contactar con la CA.

Le solicita que seleccione la CA de una lista. Una respuesta correcta confirma que la CA está disponible. 

Comprobación automatizada/con script: 

certutil -config “ \ " -ping 

Reemplazar \ Con la cadena de configuración completa de su CA (p. ej., CA-SERVER\My-Enterprise-CA). Esto ejecuta la comprobación directamente en la CA especificada, lo que la hace ideal para scripts y automatización. 

Problemas comunes: 

• “Servidor RPC no disponible” Los errores indican fallos de comunicación. Un ejemplo de este tipo de error es: 

Si recibe un error de este tipo, es posible que el sistema no pueda acceder a la CA, que esté mal configurada o que esté bloqueada por las políticas de seguridad. 

• Error de resolución de DNS – No se puede resolver el nombre de host de la CA 
• Restricciones del cortafuegos – Los puertos requeridos (por ejemplo, TCP 135 para RPC) están bloqueados 
• El servicio de CA está fuera de línea – El servidor de CA está inactivo o el servicio de Servicios de certificación está detenido 
• Segmentación de red – El enrutamiento o el aislamiento de VLAN impiden la comunicación

Estos problemas impiden que los clientes descubran la CA o se registren en ella. 

4. Verificar los permisos de la cuenta de servicio 

La cuenta utilizada para comunicarse con la CA debe tener permisos específicos en la CA y en las plantillas de certificado. 

Para comprobar los permisos a nivel de CA

1. Abra la autoridad de certificación consola en el servidor CA (certsrv.msc)
2. Haga clic derecho en la CA y seleccione Propiedades 
3. Navegue a la pestaña Seguridad . Puede  
4. Confirme que la cuenta de servicio tiene permiso para Solicitar certificados. 

Para realizar auditorías o scripts más detallados, puede utilizar herramientas como dsacls:

dsacls “CN=Servicios de clave pública,CN=Servicios,CN=Configuración,DC=dominio,DC=com”

Esto es para revisar los permisos delegados en Active Directory usando PowerShell:

Obtener permiso AD - Identidad “Nombre_CA” - Usuario “NombreCuentaServicio”

Estas herramientas ayudan a verificar si a la cuenta de servicio se le han otorgado los derechos necesarios a través de la delegación de AD, especialmente en entornos más grandes o automatizados.

Para comprobar los permisos a nivel de plantilla:

1. Abra la Plantillas de certificado complemento (certtmpl.msc)
2. Haga clic derecho en la plantilla de certificado correspondiente y seleccione Propiedades
3. En la pantalla Seguridad pestaña, confirme que la cuenta tiene Leer, Inscríbase, y, si es necesario, Inscripción automática permisos

Estos permisos deben otorgarse a través de Active Directory y podrían requerir una actualización de la directiva de grupo para su aplicación. Para verificar que se hayan aplicado las directivas de grupo correctas, ejecute lo siguiente en el sistema cliente:

gpresult / r

Este comando muestra la configuración de la política de grupo aplicada y puede ayudar a confirmar si las políticas relacionadas con certificados o de inscripción automática están activas en la máquina.

Tip: Si una plantilla de certificado está publicada, pero una cuenta de servicio no la puede ver ni usar, suele deberse a un problema de permisos a nivel de plantilla. Si ninguna plantilla funciona, empiece por comprobar los permisos a nivel de CA.

Roles típicos que interactúan con el CA:

1. Cuenta de servicio NDES
   Utilizado por el Servicio de inscripción de dispositivos de red para solicitudes de certificados de dispositivos.
   Necesita “Solicitar certificados” en la CA y leer/inscribirse en plantillas. 
2. Inscripción automática de clientes
   Computadoras y usuarios del dominio se inscriben automáticamente para obtener certificados.
   Requerir “Solicitar certificados” en la CA y leer, inscribir (inscribir automáticamente si se utiliza) en las plantillas.
3. Cuentas de aplicación/integración
   Utilizado por aplicaciones/servicios (por ejemplo, SCEP) para la automatización de certificados.
   Necesita “Solicitar certificados” en la CA y leer/inscribirse en plantillas.
4. administradores
   Requiere control total.
   Administrar CA y plantillas.

5. Asegúrese de que las plantillas de certificado estén publicadas y visibles

Si la plantilla de certificado que esperaba no está disponible, es posible que no se publique o que su cuenta no sea visible. Abra la autoridad de certificación (certsrv.msc).

Haga clic derecho en “Plantillas de certificado” y seleccione “Nuevo” > “Plantilla de certificado para emitir”.

Seleccione y publique la plantilla requerida.

Desde un cliente unido a un dominio, puede enumerar todas las plantillas disponibles con el siguiente comando:

certutil -plantilla

Si su plantilla no aparece, verifique los permisos y el estado de publicación en la CA. Es importante tener en cuenta que los retrasos en la replicación en Active Directory pueden afectar la visibilidad de las plantillas nuevas o actualizadas en diferentes dominios o sitios. Los cambios realizados en la CA o en los permisos de la plantilla pueden tardar un tiempo en propagarse y ser visibles para todos los clientes.

Para enumerar todas las plantillas emitidas (publicadas) actualmente por la CA mediante PowerShell:

Obtener plantilla CA

Esto requiere el módulo CertificateServices, que debe ejecutarse en la CA o en una máquina con RSAT (Herramientas de administración de servidor remoto) instalado.

6. Revisar los registros de eventos para detectar errores relacionados con CA

En el servidor CA, abra el Visor de eventos y navegue a la siguiente ubicación:

Registros de aplicaciones y servicios > Microsoft > Windows > CertificateServicesClient

Revise los registros operativos y de depuración para detectar errores como "Acceso denegado", "RPC no disponible", "Plantilla no encontrada" o "Error de inscripción". Estos registros suelen indicar problemas de permisos, fallos de conectividad o configuraciones incorrectas.

Para obtener información completa, revise los registros de eventos tanto en el servidor de la CA como en los equipos cliente. Los registros del lado del cliente pueden revelar problemas en la aplicación de políticas, errores de inscripción o problemas de conectividad que podrían no aparecer en los registros de la CA. Además, si necesita una solución de problemas más avanzada, considere habilitar el registro detallado/de depuración para el componente Servicios de certificados (certsvc) agregando el siguiente valor de registro:

HKLM\SYSTEM\CurrentControlSet\Servicios\CertSvc\Configuración
Valor: Diagnóstico
Tipo: REG_DWORD
Datos: 0x0000ffff

Después de aplicar el cambio, reinicie los Servicios de certificación para activar el registro detallado mediante PowerShell:

Reiniciar-Servicio-Nombre CertSvc

7. Validar la cadena de certificados y la accesibilidad de CRL

Una causa común de problemas de comunicación es una cadena de certificados incompleta o no confiable. Asegúrese de:

• Los certificados raíz e intermedios de la CA se encuentran en los almacenes correspondientes de “Autoridades de certificación raíz de confianza” y “Autoridades de certificación intermedias”.
• Los puntos finales de la lista de revocación de certificados (CRL) son accesibles desde los dispositivos cliente y los servidores de integración.

Puede comprobar los almacenes de certificados utilizando:

certlm.msc

Y verificar la accesibilidad de la CRL con:

certutil -verificar -urlfetch

Reemplazar Con la ruta a su archivo de certificado. Además, para confirmar directamente que los puntos de distribución de CRL (CDP) son accesibles, abra la URL de la CRL en un navegador web o use una herramienta como curl:

rizo -yo http://

Una respuesta HTTP 200 correcta indica que la CRL es accesible. Este paso ayuda a descartar problemas de firewall o DNS que afecten la accesibilidad de la CRL, lo que puede provocar errores de confianza o revocación de certificados durante la validación.

Para analizar el contenido de una CRL descargada, utilice el comando OpenSSL:

openssl crl -in -noout -text

Este comando muestra los metadatos de la CRL, las entradas de revocación y la información del emisor. Ayuda a verificar que la CRL se haya emitido correctamente y esté actualizada.

Impacto técnico de las fallas de CRL o AIA:

Los fallos de acceso a las CRL o URL de AIA pueden interrumpir la validación de certificados, lo que provoca diversos problemas operativos. Estos suelen deberse a problemas de resolución de DNS, bloqueos del firewall, configuraciones incorrectas del proxy HTTP o la falta de configuración de publicación en la CA. A continuación, se presentan las principales manifestaciones técnicas de estos fallos:

1. Errores de validación de la cadena de certificados
   La validación del certificado puede fallar durante la creación de la cadena, lo que genera errores como CERT_E_REVOCATION_FAILURE, CERT_E_CHAINING o CERT_E_UNTRUSTEDROOT. Estos errores indican problemas para acceder a los puntos finales de revocación o AIA.
2. SCEP y fallas de inscripción automática
   Las operaciones de inscripción pueden fallar con códigos de error específicos, como:
   • 0x80092013: Servidor de revocación fuera de línea
   • 0x80094800: Autoridad de certificación no válida
   Estos errores reflejan la imposibilidad de obtener el estado de revocación o información de autoridad.
3. Fallos del protocolo de enlace TLS/SSL
   Los clientes pueden rechazar certificados de servidor durante las negociaciones TLS/SSL debido a cadenas incompletas o URL CRL/AIA no disponibles. Esto puede interrumpir las comunicaciones seguras para servicios como HTTPS, LDAPS o VPN.
4. Indicadores del registro de eventos
   Los registros del Visor de eventos de Windows pueden capturar entradas relevantes en CertificateServicesClient o Schannel, indicando tiempos de espera de verificación de revocación, errores de construcción de cadena o fallas de descarga de las URL de CDP/AIA.
5. Errores de recuperación de OCSP y CRL
   Los intentos de obtener datos de revocación a través de OCSP o CRL pueden fallar debido a:
   • Problemas de resolución de DNS 
   • URL incorrectas o inaccesibles
   • Restricciones del proxy HTTP
   • Publicaciones de CA faltantes o mal configuradas

Estos problemas pueden interrumpir silenciosamente los procesos de validación de confianza a menos que se supervisen activamente.

Lista de verificación para la resolución rápida de problemas

Paso	Comando/Ubicación	Resultado Esperado	Consejos para solucionar problemas
Estado del servicio de CA	Obtener certificado de servicio vc	El servicio está en ejecución	Si no se está ejecutando, revise los registros de eventos de Windows para ver si hay errores. Intente reiniciar el servicio. Asegúrese de que se cumplan las dependencias.
Conectividad portuaria	Conexión de red de prueba - Nombre del equipo -Puerto 135	La conexión es exitosa	Si falla, verifique la configuración del firewall, la conectividad de la red y que RPC (puerto 135) esté abierto entre el cliente y la CA.
CA Ping	certutil -config – -ping	“Ping completado exitosamente.”	Si no tiene éxito, verifique la conectividad de la red, el estado del servicio de CA y la resolución de DNS del servidor de CA.
Visibilidad de la plantilla	certutil -plantilla	La plantilla está listada	Si falta, asegúrese de que la plantilla esté publicada en la CA y de que la replicación de AD esté completa. Compruebe los permisos de la plantilla.
Permisos	certsrv.msc > Seguridad	Se conceden los permisos necesarios	Si faltan permisos, revise y asigne los derechos necesarios a los usuarios/grupos. Compruebe si hay conflictos con las directivas de grupo.
Registros de eventos	Visor de eventos (agrupado por “Red”, “Servicio”, “Permisos”, “Plantillas”)	Sin errores de RPC o permisos	Si hay errores, revise los detalles para encontrar pistas. Filtre los registros para detectar errores relevantes. Aborde los problemas según los códigos de error.

¿Cómo puede ayudar Encryption Consulting?

Consultoría de cifrado ayuda a las organizaciones a proteger y administrar Servicios de certificados de Microsoft Proporcionando una orientación clara sobre cómo solucionar los problemas de comunicación y estableciendo PKI correctamente y automatizar los procesos de certificación con Administrador de CertSecureTrabajamos con nuestros clientes para encontrar la causa exacta de problemas como la configuración del servicio, los permisos de acceso o los errores de red.

CertSecure Manager facilita esta tarea enviando alertas antes de que caduquen los certificados, renovándolos automáticamente para evitar tiempos de inactividad y conectándose con Active Directory para cumplir con las políticas de la empresa sobre el uso de certificados. Registra todos los certificados en un solo lugar, detecta cualquier cambio y gestiona las tareas sin necesidad de trabajo manual constante, ofreciendo una gestión de certificados más automatizada.

Garantiza la correcta integración de la CA con los sistemas empresariales. Ya sea que se trate de una interrupción puntual o de la planificación de una implementación completa de PKI, brindamos el soporte necesario para mantener una infraestructura confiable. obediente, infraestructura de certificados escalable.

Conclusión

Siguiendo estos pasos, podrá diagnosticar y resolver sistemáticamente la mayoría de los problemas de comunicación de las CA de Microsoft. Este enfoque garantiza que su infraestructura de PKI se mantenga robusta, segura e integrada con los flujos de trabajo de gestión de certificados de su organización. La supervisión y auditoría proactivas del estado de las CA y del uso de los certificados ayudan a prevenir interrupciones, detectar anomalías con antelación y respaldar las iniciativas de cumplimiento normativo. Si persisten los problemas, considere contactar con expertos en PKI para obtener asistencia y resolución de problemas avanzada.