La configuración de NDES falla con un error de punto final duplicado 

El error RPC_S_DUPLICATE_ENDPOINT (error WIN32 1740, ID de evento 34) impide que los Servicios de certificados de Active Directory se reinicien durante la configuración de NDES en Windows Server 2016, generalmente porque un cliente SafeNet Luna HSM no ha liberado su identificador KSP antes de que se reinicie el servicio. La actualización del cliente Luna, normalmente de la versión 10.3.0 a la 10.5.0, elimina el bloqueo y permite que certsvc se reinicie correctamente.

Este error aparece en una ventana específica y estrecha: ya se ha creado una jerarquía PKI de dos niveles, OCSP está implementado, cada CA parece estar configurada correctamente y el script de implementación sigue fallando en una rutina. net stop certsvc && net start certsvc Dado que todo lo anterior funcionó correctamente, es fácil suponer que la configuración de la autoridad de certificación está dañada. No es así. La biblioteca Luna KSP reinició el servicio más rápido de lo que el cliente del módulo de seguridad de hardware pudo liberar su identificador en la sesión anterior, y Windows informa de esa colisión como un punto final RPC duplicado en lugar de un problema de sincronización del HSM.

Esta guía abarca todo el proceso: requisitos previos, cómo confirmar que se trata de este error exacto y no de otro fallo de RPC o NDES, la actualización del cliente Luna que lo soluciona, los pasos de validación posteriores a la corrección, los errores más frecuentes que encuentran los administradores y cómo revertir los cambios de forma segura si la actualización no está disponible de inmediato.

Puntos Clave

• El error RPC_S_DUPLICATE_ENDPOINT (ID de evento 34, error WIN32 1740) que se produce durante el reinicio de un servicio NDES o CA en Windows Server 2016 es un error de sincronización del cliente SafeNet Luna HSM, no un error de configuración de la autoridad de certificación.
• El error es específico de la versión 10.3.0 de Luna Client, donde la biblioteca KSP no libera su identificador al servicio con la suficiente rapidez durante una operación rápida. net stop/net start ciclo.
• La actualización del cliente Luna HSM a la versión 10.5.0 o posterior resuelve el problema de bloqueo y es la solución recomendada, no un cambio en el registro ni una solución alternativa con certutil.
• Validar la solución con una limpieza net stop certsvc && net start certsvc Repita el ciclo y confirme que el ID de evento 34 ya no aparece en el registro de eventos de la Autoridad de Certificación.
• Según la encuesta Trust Pulse de DigiCert, publicada el 2 de julio de 2025, las empresas que dependen del seguimiento manual de certificados y versiones de clientes HSM registraron tiempos de inactividad relacionados con certificados en el 45 % de los casos durante el último año, y el 37.5 % de esas interrupciones fueron causadas específicamente por un certificado caducado. Este es el mismo punto ciego operativo que permite que una versión de cliente HSM no rastreada bloquee una implementación de NDES.

¿A quién debería importarle este error de punto final duplicado?

Este error bloquea el despliegue de NDES en la capa de infraestructura, incluso antes de que se inicie el proceso de inscripción o se configure SCEP. A continuación, se detallan las medidas que cada equipo debe tomar al respecto.

• Administradores de PKI Controla la secuencia de compilación de la CA y de instalación de NDES. Acción: verifica la versión del cliente Luna HSM instalada en cada CA emisora ​​antes de iniciar una implementación de NDES, no después de que falle el reinicio.
• Arquitectos de seguridad Decida qué versiones de cliente HSM están aprobadas para su uso en todo el entorno PKI. Acción: agregue Luna Client 10.5.0 o posterior como la versión mínima documentada para cualquier nueva compilación de CA de Server 2016.
• Equipos de plataforma e identidad Ejecutan los scripts de despliegue y son los primeros en detectar este fallo. Acción: Incluir la comprobación de la versión del cliente Luna en el paso previo a la compilación del script de la CA, antes del reinicio de certsvc.
• Cumplimiento y GRC Realizar un seguimiento para verificar que las versiones del software de CA y HSM estén actualizadas según las directrices de seguridad y soporte del proveedor. Acción: agregar la actualización de la versión del cliente HSM a la lista de verificación de auditoría de la infraestructura PKI junto con la caducidad del certificado.
• CISO Asumir el riesgo general de la infraestructura PKI que depende de software cliente HSM sin parchear o desactualizado. Acción: tratar la desviación de la versión del cliente HSM como un riesgo que se monitorea, no como una simple nota de solución de problemas puntual.

Requisitos previos

Confirme cada uno de estos puntos antes de solucionar un error de punto final duplicado, ya que otros problemas producen un fallo de RPC de apariencia similar:

• Un host Windows Server 2016 (o posterior) que ejecute Servicios de certificados de Active Directory, con la jerarquía de CA ya configurada y OCSP implementado.
• Integración de SafeNet Luna HSM, con acceso administrativo para comprobar y actualizar la versión instalada del cliente Luna.
• Derechos de administrador empresarial o administrador local suficientes para detener e iniciar el certsvc servicio y para ejecutar certutil comandos
• Acceda al Visor de eventos en la fuente Microsoft-Windows-Certification Authority para confirmar el ID de evento y el código de error exactos antes de actuar.
• Se requiere una ventana de mantenimiento, ya que para solucionar esto se necesita una actualización del cliente Luna y al menos un reinicio adicional del servicio CA.

Comprender el error de punto final duplicado

La firma del fallo es lo suficientemente consistente como para que valga la pena compararla exactamente antes de aplicar cualquier solución:

• Fuente: Autoridad de certificación de Microsoft Windows
• Código de error: 0x6cc (WIN32: 1740 RPC_S_DUPLICATE_ENDPOINT)
• ID de evento: 34

El fallo suele aparecer en Server 2016 durante la configuración de PKI. Cada CA está configurada, OCSP se ha implementado correctamente y el script de implementación aún no puede iniciar un reinicio rutinario del servicio. Después de que el script se ejecuta a través de su certutil comandos de configuración, llega a:

net stop certsvc && net start certsvc

La consola muestra una secuencia de inicio y parada de aspecto normal:

El servicio de certificados de Active Directory se está deteniendo.
El servicio de certificados de Active Directory se detuvo correctamente.

Se está iniciando el servicio de certificados de Active Directory.
El servicio de certificados de Active Directory se inició correctamente.

Pero el siguiente intento de reinicio informa:

WIN32: 1740 PUNTO FINAL DUPLICADO DE RPC_S

Los Servicios de certificados de Active Directory no se inician, no pueden inicializar RPC para la CA emisora ​​e informan que el punto final está duplicado. Cuando se agota el tiempo de espera de la configuración y falla la instalación, el error se manifiesta como que RPC no está disponible o que el texto del punto final aparece como duplicado. Este comportamiento es constante en todas las CA del servidor afectado e impide la instalación de NDES.

Causa principal

El error de punto final duplicado se produce porque la biblioteca SafeNet KSP (Key Storage Provider) no libera su identificador del proceso de servicios de certificados antes de que este se reinicie. Este es un problema de sincronización conocido en Luna Client versión 10.3.0: el reinicio del servicio se completa más rápido de lo que la biblioteca KSP puede liberar su sesión anterior, y el registro del punto final RPC entra en conflicto con el que aún se está cerrando, lo que Windows informa como un punto final duplicado en lugar de una condición de carrera.

Paso a paso: Diagnóstico y solución del error de punto final duplicado

Siga estos pasos en orden. No intente actualizar el Cliente Luna hasta que se confirme la firma del error, ya que una causa raíz diferente requiere una solución diferente.

Confirmar la firma de error

1. Abra Visor de sucesos y filtrar por fuente Autoridad de certificación de Microsoft Windows.
2. Confirme que el fallo se registra como ID de evento 34 con código de error 0x6cc (WIN32: 1740 RPC_S_DUPLICATE_ENDPOINT).
3. Reproducir con net stop certsvc && net start certsvc y confirmar que el fallo se produce específicamente al reiniciar, no en la configuración inicial de la CA.

Compruebe la versión instalada del cliente Luna.

1. En la CA afectada, abra el directorio de instalación del cliente Luna o ejecute la utilidad de versión del cliente Luna (normalmente vtl.exe -v o la entrada de desinstalación de LunaClient en Programas y características) para confirmar la versión instalada.
2. Confirme que la versión se lee 10.3.0Si la versión es 10.5.0 o posterior, no se trata del error descrito aquí y se debe investigar otra causa raíz.

Actualizar el cliente Luna HSM

1. Descargar la versión de Luna Client 10.5.0 o posterior desde el portal de descargas compatible de Thales/SafeNet, que coincida con la versión que admita el firmware de su dispositivo HSM.
2. Desinstale el cliente 10.3.0 existente o ejecute la actualización in situ compatible con el proveedor, si está disponible para su generación de dispositivo Luna.
3. Instale la nueva versión del cliente y vuelva a registrar el KSP con el host de CA, siguiendo los pasos de registro de cliente estándar de Thales para su partición HSM.

Reiniciar los servicios de certificados y validar.

1. Ejecutar net stop certsvc && net start certsvc de nuevo.
2. Confirme que los informes del servicio se iniciaron correctamente sin ningún error RPC_S_DUPLICATE_ENDPOINT.
3. Proceda con la instalación del rol NDES ahora que el servicio CA subyacente se ha reiniciado correctamente.

Validación de la solución

No considere que el problema se ha resuelto tras un único reinicio exitoso. Confirme todo lo siguiente antes de proceder a la instalación de NDES:

• Ejecutar sc query certsvc y confirmar los informes de servicio RUNNING sin estado pendiente.
• Repetición: net stop certsvc && net start certsvc al menos dos veces consecutivas para confirmar que la solución se mantiene bajo un ciclo de reinicio rápido, ya que esa era la condición desencadenante original.
• Compruebe el Visor de eventos en Microsoft-Windows-Certification Authority y confirme que el ID de evento 34 ya no aparece en los reinicios posteriores.
• Ejecutar certutil -ping contra la CA para confirmar que está respondiendo a las solicitudes RPC normalmente.
• Confirme que la utilidad de versión de Luna Client ahora informa 10.5.0 o posterior, por lo que la solución se puede verificar independientemente de la prueba de reinicio.

Errores comunes y cómo solucionarlos

Estos son los problemas con los que se encuentran con mayor frecuencia los administradores en relación con esta solución, además del error original de punto final duplicado.

RPC_S_DUPLICATE_ENDPOINT persiste después de la actualización.

Si el error persiste tras actualizar el cliente Luna, confirme que la actualización se haya completado correctamente y que la antigua biblioteca KSP 10.3.0 se haya reemplazado por completo, sin dejar registros junto con la nueva versión. Una actualización parcial que deja dos registros KSP activos reproduce el mismo problema de duplicación de puntos finales.

La biblioteca de KSP sigue apareciendo bloqueada.

Si Luna KSP sigue sin liberarse correctamente después de la actualización, compruebe si hay algún servicio de cliente Luna o proceso de controlador bloqueado que mantenga abierta la sesión HSM y reinicie el propio servicio de cliente Luna antes de volver a intentar reiniciar certsvc, en lugar de reiniciar certsvc repetidamente por sí solo.

El servicio CA no se inicia después de la actualización del cliente.

Si certsvc no se inicia y muestra un error diferente inmediatamente después de la actualización del cliente Luna, confirme que el registro de la partición HSM y el certificado del cliente se conservaron tras la actualización. En ocasiones, la reinstalación del cliente puede requerir que se vuelva a registrar con la partición HSM antes de que la CA pueda acceder a sus claves.

La instalación del rol NDES sigue fallando después de que certsvc se reinicie correctamente.

Una vez que certsvc se reinicia sin el error de punto final duplicado, un fallo en la instalación de NDES en este punto es un problema aparte, no una continuación de este error. Revise los requisitos previos específicos de NDES, incluidos los permisos de la cuenta de servicio y la configuración de IIS, independientemente del problema de reinicio de la CA.

Pasos de retroceso

Si la actualización del cliente Luna no puede realizarse de inmediato, por ejemplo, porque el firmware del dispositivo HSM necesita validarse primero, revierta la actualización deliberadamente en lugar de dejar la CA en un estado parcialmente configurado.

1. Si la actualización del cliente Luna ya se inició pero no se completó, finalice la desinstalación de la instalación parcial de la versión 10.5.0 y reinstale el cliente 10.3.0 que se sabe que funciona, en lugar de dejar un estado mixto.
2. Confirme que certsvc se inicia correctamente en el cliente 10.3.0 revertido, teniendo en cuenta que el error de punto final duplicado volverá en cualquier ciclo de reinicio rápido futuro hasta que el cliente se actualice de nuevo.
3. Evite escribir guiones rápidos y repetitivos. net stop/net start Se realizan ciclos contra certsvc como solución temporal mientras se ejecuta el cliente antiguo, ya que esa es la condición exacta que desencadena el error.
4. Documente la restricción de la versión del firmware del HSM y del cliente Luna para que el siguiente intento de actualización se pueda planificar en lugar de repetir el mismo ciclo de resolución de problemas.

Guía de referencia rápida: Requisitos previos, validación, errores y reversión.

Utilice esta tabla como una lista de verificación práctica desde el diagnóstico inicial hasta la validación.

Requisito previo	Comando / Configuración	Verificación de validación	Error común	Rollback	Propietario
Firma de error confirmada	Compruebe el Visor de eventos para obtener la fuente Autoridad de certificación de Microsoft Windows	ID de evento 34, código de error 0x6cc (WIN32: 1740)	Un error diferente de RPC o CA se confundió con este error.	No es necesario revertir el proceso; este paso solo confirma el diagnóstico.	Administrador de la infraestructura de clave pública (KPI)
Versión del cliente Luna identificada	Ejecute la utilidad de versión del cliente Luna (por ejemplo vtl.exe -v)	La versión es 10.3.0	La versión ya es 10.5.0+, lo que significa que esta no es la causa.	No hay reversión; investigue una causa raíz diferente.	Administrador de la infraestructura de clave pública (KPI)
Luna Client actualizado	Instale Luna Client 10.5.0 o posterior desde el portal del proveedor.	La utilidad de versión informa la versión 10.5.0 o posterior.	La actualización parcial deja dos registros de KSP activos.	Finalizar la desinstalación y reinstalar el cliente 10.3.0 que funciona correctamente.	Equipo de Plataforma/Identidad
certsvc restart valided	net stop certsvc && net start certsvc	Informes de servicio EJECUTÁNDOSE a través de sc query certsvc, sin ID de evento 34	RPC_S_DUPLICATE_ENDPOINT sigue apareciendo	Confirme que la actualización se ha completado correctamente; vuelva a ejecutar el registro del cliente.	Equipo de Plataforma/Identidad
CA responde a RPC	certutil -ping	CA responde sin error RPC	La CA no se inicia después de la actualización del cliente (registro de partición HSM).	Vuelva a registrar el cliente en la partición HSM.	Administrador de PKI, con el equipo de HSM.

Cómo se relaciona esto con la gestión del ciclo de vida de los certificados.

NDES existe para permitir que los dispositivos de red se registren automáticamente para obtener certificados a través de SCEP, lo que lo convierte en una pieza fundamental de la automatización de certificados, no en una tarea de instalación única. Un error en la versión del cliente HSM que bloquea la configuración de NDES tiene el mismo problema de raíz que la mayoría de las interrupciones de PKI: una dependencia de infraestructura que nadie estaba monitoreando hasta que causó una falla. La encuesta Trust Pulse de DigiCert, publicada el 2 de julio de 2025, encontró que el 45 % de las empresas experimentaron tiempo de inactividad relacionado con certificados en el último año, y el 37.5 % de esos incidentes fueron causados ​​específicamente por un certificado caducado, el mismo patrón de una dependencia no monitoreada que emerge como una interrupción se aplica directamente a una versión de cliente HSM no monitoreada.

Las plataformas de gestión del ciclo de vida de los certificados, como CertSecure Manager, aplican esta misma disciplina a los certificados que emite NDES una vez en funcionamiento, realizando un seguimiento de la inscripción, renovación y caducidad de los certificados de dispositivos del mismo modo que lo hacen con los certificados de servidor y de usuario. Si ya está modernizando las operaciones de certificados en otras partes del entorno, vea cómo la modernización de la infraestructura de clave pública (PKI) y la gestión del ciclo de vida de los certificados (CLM) funcionan conjuntamente y cómo una hoja de ruta combinada de PKI y CLM tiene en cuenta las dependencias de la infraestructura, como las versiones de los clientes HSM, y no solo las fechas de caducidad de los certificados.

NDES en entornos PKI de nube, híbridos y multi-CA

Las organizaciones que utilizan NDES en varias CA emisoras, o en una infraestructura PKI híbrida (local y en la nube), se enfrentan al mismo riesgo de incompatibilidad de versiones del cliente HSM en cada CA que utiliza una integración con Luna, no solo en la primera que se implementó. Una discrepancia de versiones detectada tardíamente en una implementación con varias CA implica aplicar la solución posteriormente a todas las CA ya implementadas, en lugar de detectarla una sola vez durante un proceso de compilación estandarizado.

Para las organizaciones que desarrollan o expanden NDES en múltiples CA o regiones, centralizar la gestión de certificados e infraestructura PKI mediante un modelo PKI-as-a-Service elimina la necesidad de validar manualmente las versiones de los clientes HSM, la configuración de CA y los requisitos previos de NDES en cada sitio, y proporciona a cada nueva configuración de CA una base consistente y prevalidada desde la cual comenzar.

Cómo medir el éxito y qué auditar periódicamente

Una solución exitosa no se limita a que “el reinicio haya funcionado una vez”. Realice auditorías periódicas, no solo durante la compilación inicial de NDES:

• Se instaló la versión del cliente Luna HSM en todos los servidores CA y NDES, y se verificó que coincidiera con la versión mínima aprobada actualmente.
• Entradas del Visor de eventos en Microsoft-Windows-Certification Authority para el ID de evento 34 u otros fallos relacionados con RPC, no solo alertas de servicio caído.
• El comportamiento de los servicios de certificados se reinicia después de cualquier actualización del cliente HSM, del firmware o de Windows, no solo en la implementación inicial.
• Tasas de éxito de inscripción en NDES para dispositivos que utilizan SCEP, para detectar un fallo de inscripción silencioso por separado de una interrupción del servicio.
• ¿Qué CA en un entorno multi-CA todavía ejecutan una versión de cliente HSM sin parchear o desactualizada?

Un inventario de activos criptográficos como CBOM Secure extiende esta misma disciplina más allá de las versiones del cliente HSM a cada clave, certificado y algoritmo del entorno, de modo que una dependencia de este tipo nunca se descubre por primera vez durante una implementación fallida.

A largo plazo, la votación del CA/Browser Forum del 11 de abril de 2025 para acortar la validez máxima de los certificados TLS a 200 días, luego a 100 días y finalmente a 47 días para 2029, hace que las rutas de inscripción automatizadas como NDES y SCEP sean más importantes, no menos, ya que la reemisión manual no puede seguir el ritmo de esa cadencia. El NIST finalizó sus tres primeros estándares de criptografía post-cuántica, FIPS 203, FIPS 204 y FIPS 205, el 13 de agosto de 2024, y los proveedores de almacenamiento de claves respaldados por HSM, como Luna KSP, son precisamente la capa que eventualmente deberá admitir nuevos algoritmos PQC. El Centro de Excelencia PQC de Encryption Consulting y una evaluación de preparación para PQC son el lugar adecuado para planificar esa transición para la infraestructura PKI dependiente de HSM.

La opinión de Encryption Consulting

Se trata de un pequeño error con un impacto considerable: una versión del cliente HSM, en un campo específico de una utilidad de versiones que nadie verifica por defecto, bloquea todo el despliegue de NDES y se manifiesta exactamente como un fallo de configuración de CA hasta que alguien conoce el historial de Luna 10.3.0. La solución, una vez identificada, solo lleva unos minutos. La solución definitiva consiste en integrar la actualización de la versión del cliente HSM en la lista de verificación estándar de compilación de CA, de modo que este diagnóstico no tenga que repetirse.

Conclusión

El error RPC_S_DUPLICATE_ENDPOINT durante el reinicio de un servicio NDES o CA en Windows Server 2016 se debe a que SafeNet Luna Client versión 10.3.0 no libera su identificador KSP con la suficiente rapidez durante el reinicio del servicio. La actualización a Luna Client 10.5.0 o posterior soluciona el problema. Valide la solución con un ciclo de reinicio limpio de certsvc y la salida confirmada del Visor de eventos antes de continuar con la instalación de NDES.

Si necesita ayuda con su entorno PKI, no dude en enviarnos un correo electrónico a [email protected].

Preguntas frecuentes

¿Cuál es la principal conclusión del error de configuración de NDES con punto final duplicado?

El error RPC_S_DUPLICATE_ENDPOINT durante un reinicio de NDES o CA en Windows Server 2016 es un fallo de sincronización del cliente SafeNet Luna HSM específico de la versión 10.3.0, no una configuración incorrecta de la autoridad de certificación. La actualización del cliente Luna a la versión 10.5.0 o posterior lo soluciona.

¿Por qué es importante esto para los equipos de PKI empresariales?

Sin saber que se trata de un problema de versión del cliente HSM, los equipos pueden perder mucho tiempo solucionando problemas de configuración de CA, ajustes de RPC de red o reglas de firewall que nunca fueron el problema real, lo que retrasa la implementación de NDES de la que pueden depender otros proyectos.

¿Qué riesgos aumentan si este tema se aborda manualmente?

Las versiones manuales y sin seguimiento de los clientes HSM implican que cada nueva compilación de CA corre el riesgo de encontrar este mismo error de forma independiente, sin una comprobación estándar para detectarlo antes de que falle el reinicio, y sin ningún registro de qué CA en un entorno de múltiples CA siguen ejecutando la versión afectada.

¿Qué equipos deberían asumir la responsabilidad de este cambio?

Los administradores de PKI son responsables de la secuencia de compilación de CA y de las comprobaciones de la versión del cliente HSM. Los equipos de plataforma o identidad ejecutan los scripts de implementación y realizan la actualización del cliente. Los arquitectos de seguridad establecen la versión mínima aprobada del cliente HSM. Los responsables de cumplimiento y los CISO realizan un seguimiento de la vigencia de la versión como parte del programa general de gestión de riesgos de PKI.

¿Cómo se relaciona esto con la gestión del ciclo de vida de los certificados?

NDES es la vía de inscripción para los certificados de dispositivos emitidos a través de SCEP, por lo que cualquier retraso en este proceso retrasa la emisión automatizada de certificados. Una vez que NDES está operativo, las herramientas de gestión del ciclo de vida de los certificados, como CertSecure Manager, se encargan de gestionar la renovación y la caducidad de los certificados que emite.

¿Cómo deberían las organizaciones medir el éxito?

El éxito se manifiesta cuando un reinicio de certsvc finaliza sin el ID de evento 34, una utilidad de versión de Luna Client confirma la versión 10.5.0 o posterior, y una instalación de NDES se lleva a cabo sin que se repita el fallo de RPC, verificado con al menos dos ciclos de reinicio consecutivos.

¿Qué se debe auditar o supervisar periódicamente?

Audite la versión del cliente Luna HSM instalada en cada servidor CA y NDES, las entradas del Visor de eventos para el ID de evento 34 u otros fallos de RPC, el comportamiento de reinicio de los servicios de certificados después de las actualizaciones y las tasas de éxito de la inscripción SCEP de NDES.

¿Cómo afecta este tema a las infraestructuras de clave pública (PKI) en la nube, híbridas o con múltiples autoridades de certificación (CA)?

Cada CA en un entorno multi-CA o híbrido que utiliza una integración Luna HSM conlleva el mismo riesgo de versión de forma independiente. Una discrepancia de versión detectada tardíamente en un despliegue multi-CA implica actualizar Luna Client en todas las CA ya desplegadas, en lugar de detectarla una sola vez en una compilación estandarizada.

¿Qué requisitos previos son necesarios antes de la implementación?

Necesitas un servidor Windows Server 2016 o posterior con la jerarquía de CA ya configurada y OCSP implementado, una integración de SafeNet Luna HSM, derechos de administrador para detener e iniciar certsvc y ejecutar certutil, y acceso al Visor de eventos para confirmar la firma de error exacta antes de actuar.

¿Qué errores comunes deben tener en cuenta los administradores?

Esté atento a la persistencia del error RPC_S_DUPLICATE_ENDPOINT después de una actualización incompleta del cliente Luna, una biblioteca KSP que aún aparece bloqueada, fallos de inicio de certsvc debido a un problema de registro de partición HSM justo después de la actualización del cliente y fallos de instalación de roles NDES que no están relacionados una vez que certsvc se reinicia correctamente.