Cómo corregir errores de confianza de certificado OPC UA
La conexión falla con un error de certificado - no confiable, inválido, rechazado - aunque ambas aplicaciones estén configuradas, el punto final sea correcto, y ayer hasta pudo haber funcionado. OPC UA autentica en ambas direcciones: el cliente revisa el certificado del servidor y el servidor revisa el del cliente, y cualquiera de los dos lados puede vetar la conexión. Esta página es la secuencia de diagnóstico para esas fallas: establecer qué lado rechaza, encontrar el certificado rechazado, y corregir la confianza, el vencimiento y los desajustes de identidad en el orden en que ocurren de verdad en campo.
Corregir errores de confianza de certificado OPC UA en una línea: Un error de confianza de certificado OPC UA significa que un lado de la conexión no aceptó el certificado de instancia de aplicación del otro. La confianza en OPC UA es mutua y explícita: cada aplicación mantiene una lista de confianza, y un certificado de par ausente de esa lista es rechazado; muchos servidores estacionan el certificado desconocido en un almacén de rechazados donde un administrador puede moverlo a confiables. Más allá de la confianza simple, las conexiones fallan por certificados vencidos, por certificados regenerados tras una reinstalación o cambio de nombre de host que dejó obsoleta la copia confiable vieja, y por desajustes entre el URI de aplicación del certificado y lo que la aplicación realmente reporta.
Primeras revisiones: ¿qué lado está rechazando?
El dato diagnóstico más útil es qué extremo rechazó. Si el cliente reporta que el certificado del servidor no es confiable, la corrección ocurre en la configuración de confianza del cliente. Si la conexión del cliente es rechazada por el servidor - a menudo aflorando como una falla de seguridad genérica del lado del cliente - el registro del servidor dice la verdad, y la corrección ocurre en la lista de confianza del servidor. Revisar ambos registros antes de tocar cualquier almacén evita la hora perdida más común en la puesta en marcha de OPC UA: confiar el certificado correcto en el extremo equivocado.
Recuerde que la confianza debe existir en ambas direcciones antes de que se forme una conexión asegurada. Las instalaciones nuevas fallan en ambas direcciones a la vez, lo cual es normal y esperado: el primer intento de conexión es como cada lado obtiene el certificado del otro para rechazarlo. La secuencia práctica de puesta en marcha es deliberada: intente una conexión, deje que falle, luego apruebe el certificado recién rechazado en cada lado e intente de nuevo.
Listas de confianza y el almacén de rechazados
Cada aplicación OPC UA mantiene un almacén de certificados con una lista de confiables y, en la mayoría de las implementaciones de servidor, un área de rechazados donde los certificados de pares desconocidos se estacionan tras un intento fallido. Ese almacén de rechazados es la superficie de trabajo para la puesta en marcha: el certificado desconocido ya está ahí, y confiarlo es una operación de mover o aprobar en la herramienta de administración del servidor en vez de cualquier transferencia manual de archivos. Si el almacén de rechazados está vacío tras una conexión fallida, el intento probablemente nunca llegó al handshake de seguridad; mire la accesibilidad de red y la selección de punto final en vez de los certificados.
Los certificados autofirmados, que la mayoría de las aplicaciones OPC UA industriales usan por defecto, deben confiarse individualmente en cada par, lo cual es manejable para un puñado de conexiones y penoso a escala. La alternativa es emitir certificados de aplicación desde una autoridad de certificación y confiar la CA una sola vez en cada aplicación; entonces cualquier certificado que la CA emitió se acepta, y las renovaciones dejan de requerir una reafirmación de confianza en todo el sitio. Cuando se usa una CA, recuerde que la aplicación también necesita cualquier certificado intermedio disponible para validar la cadena, y una cadena incompleta produce errores de confianza que se ven idénticos a un certificado faltante.
Vencimiento, regeneración y desajustes de identidad
Los certificados vencen, y las aplicaciones OPC UA rechazan correctamente los vencidos. Una conexión que funcionó por años y falló de la noche a la mañana es la firma clásica del vencimiento, y las fechas de validez del certificado - visibles en cualquier visor de certificados - lo resuelven de inmediato. La falla relacionada es el tiempo mismo: la validación de certificados compara contra el reloj local, así que un dispositivo cuyo reloj está mal por años puede rechazar certificados perfectamente válidos o aceptar vencidos. Los dispositivos embebidos que perdieron su reloj tras un corte de energía son el culpable usual, lo cual hace de la sincronización de tiempo parte del diagnóstico de certificados.
La regeneración es más sutil. Cuando una aplicación se reinstala, se le cambia el nombre de host, o se le renueva el certificado deliberadamente, presenta un certificado nuevo, y cada par que confiaba en el viejo ahora ve una identidad desconocida y lo rechaza. El certificado viejo sentado en el almacén de confiables del par no hace nada; el nuevo debe confiarse. Por último, OPC UA vincula los certificados a la identidad de la aplicación: el URI de aplicación embebido en el certificado debe coincidir con el URI que la aplicación declara en su descripción de aplicación. Las pilas que hacen cumplir la coincidencia rechazan ante un desajuste, que típicamente aparece tras clonar configuraciones entre máquinas o regenerar certificados con herramientas que llenaron el URI distinto. La solución es regenerar el certificado con el URI correcto en vez de relajar la validación.
Cuándo escalar, y hacer la confianza de forma sostenible
Escale al fabricante cuando el certificado esté demostrablemente confiado, sea válido, con cadena completa, con tiempo sincronizado y con URI coincidente, y el handshake aun falle; en ese punto los sospechosos son errores de pila, políticas de seguridad no soportadas entre los dos productos, o corrupción del almacén, todo lo cual necesita detalles del fabricante. Lleve los registros de ambas aplicaciones para un intento fallido y exportaciones de ambos certificados; ese par de archivos suele bastar para que un ingeniero de soporte detecte el desajuste rápido.
La respuesta insostenible es deshabilitar la seguridad para hacer desaparecer el error, lo cual cambia un problema de puesta en marcha por uno permanente. El patrón sostenible para una flota - muchos dispositivos, varios clientes, rotación de personal - es una pequeña CA interna, un inventario de fechas de vencimiento de certificados, y una renovación programada antes del vencimiento en vez de después de la interrupción. Una plataforma de monitoreo como Merobix que conecta a muchos servidores OPC UA se beneficia de exactamente la misma disciplina sobre su propio certificado de cliente: una identidad, confiada deliberadamente en cada servidor, renovada por calendario en vez de en una crisis.
Preguntas frecuentes
¿Por qué OPC UA rechaza mi certificado si ya confié en el servidor?
Porque la confianza es mutua. Confiar el certificado del servidor en el cliente solo satisface la mitad del chequeo del cliente; el servidor verifica de forma independiente el certificado del cliente contra su propia lista de confianza y rechaza los desconocidos. El certificado del cliente típicamente cae en el almacén de rechazados del servidor tras el intento fallido, donde un administrador lo aprueba. Ambas direcciones deben confiarse antes de que se forme la conexión.
¿Por qué una conexión OPC UA que funcionaba empezó de repente a fallar la validación de certificado?
Las causas usuales son el vencimiento y la regeneración. Revise primero las fechas de validez del certificado; las conexiones de larga vida rutinariamente mueren en la fecha de vencimiento que nadie registró. Si las fechas están bien, revise si alguna aplicación se reinstaló, se renombró, o se le renovó el certificado, porque un certificado regenerado es una identidad nueva que el par ya no reconoce. Verifique también los relojes de ambos dispositivos, ya que la validación contra un reloj muy equivocado falla certificados válidos.
¿Es seguro solo usar la política de seguridad None para evitar problemas de certificado?
Solo como un diagnóstico corto y deliberado en una red aislada, para probar que el resto de la configuración funciona mientras corrige la confianza. Correr conexiones de producción sin seguridad quita la firma y el cifrado de mensajes por completo, dejando el enlace abierto a manipulación y escucha, y la guía industrial es consistente en no hacerlo fuera de segmentos plenamente confiables. Corrija la configuración de confianza; no deshabilite el mecanismo que la hace cumplir.
Fuentes y lecturas
Referencias primarias de los organismos de normas y reguladores que definen este tema:
- OPC Unified Architecture - OPC Foundation
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.