Certificado X.509 y CSR: qué contienen y para qué

Respuesta corta

Un certificado X.509 versión 3 es el documento digital que une una clave pública con la identidad de su titular. Contiene versión, número de serie, algoritmo de firma, emisor, periodo de validez, titular, clave pública, extensiones opcionales y la firma de la autoridad certificadora. Se codifica en DER o en PEM. La solicitud de firma (CSR) lleva la clave pública y los datos del titular; esa información entra al certificado cuando la autoridad lo firma.

Para qué sirve un certificado en un IED

Cuando una pasarela, un IED o un servidor SCADA se comunican con TLS, cada uno debe demostrar quién es. La prueba es un certificado digital. El estándar que lo define se llama X.509. La serie IEC 62351 lo usa en varias partes: en la 3 para autenticar los extremos de una conexión TCP/IP, en la 8 para llevar los roles de un usuario y en la 9 para gestionar su ciclo de vida. En telecontrol, el caso práctico está en IEC 104 y DNP3 seguros con TLS.

X.509 es un estándar para las estructuras de la infraestructura de clave pública. Se define con ASN.1 (Abstract Syntax Notation One), una notación para describir estructuras de datos, y se codifica con reglas DER o con PEM.

Qué campos tiene un certificado X.509 versión 3

Un certificado es una lista ordenada de campos. Los de la versión 3 son estos.

Campo	Qué contiene	Para qué sirve
Versión	El número de versión del formato	Indica qué campos puede traer
Número de serie	Un identificador asignado por la autoridad	Distingue este certificado de los demás de la misma autoridad; permite revocarlo
Algoritmo de firma	El algoritmo con que la autoridad firmó	El receptor sabe cómo verificar la firma
Emisor	Identidad de la autoridad certificadora	Dice quién respalda el certificado
Validez	Fecha de inicio (Not Before) y de fin (Not After)	Fuera de ese intervalo, el certificado no se acepta
Titular	Identidad del equipo o persona (Subject)	Dice a quién pertenece la clave
Clave pública del titular	El algoritmo de la clave y la clave misma	Es lo que el otro extremo usa para verificar al titular
Identificadores únicos del emisor y del titular	Campos opcionales	Distinguen entidades con el mismo nombre
Extensiones	Campos opcionales adicionales	Por ejemplo, el uso permitido de la clave
Algoritmo y firma del certificado	La firma digital de la autoridad	Garantiza que nadie modificó los campos anteriores

Dos campos merecen atención en la práctica:

Validez. Un certificado vencido, o que aún no entra en vigor según el reloj del equipo, se rechaza. Por eso la hora correcta de los equipos es parte de la seguridad.
Firma. Todo el contenido anterior queda firmado. Si alguien cambia un solo campo, la firma deja de coincidir y el receptor lo detecta.

Formatos DER y PEM

El mismo certificado puede guardarse de dos maneras:

DER (Distinguished Encoding Rules): codificación binaria. Es la forma compacta que muchos equipos esperan al cargar un certificado.
PEM (Privacy Enhanced Mail): representación en texto. Se reconoce porque el contenido va entre líneas de inicio y fin, y se puede abrir en un editor de texto o enviar por correo.

Si un IED rechaza un archivo de certificado, uno de los motivos más frecuentes es el formato: el equipo espera DER y se le entrega PEM, o al revés. La conversión no cambia el certificado.

Qué es una solicitud de firma de certificado (CSR)

Un certificado se obtiene de una autoridad certificadora (CA). Para pedirlo, el equipo genera una CSR (Certificate Signing Request), que consiste en:

La clave pública de un par de claves.
Información adicional sobre quien pide el certificado.

Cuando la CA firma la solicitud, esa información se inserta en el certificado. La CSR no tiene valor por sí sola: es la petición, no la respuesta.

El nombre distinguido

La información de la solicitud se organiza en un nombre distinguido (Distinguished Name, DN). Incluye:

El nombre común (Common Name, CN). Cuando se certifica un servidor, es su nombre de dominio completo (FQDN, Fully Qualified Domain Name).
Datos de la organización: nombre, unidad, ciudad y país.

Un error frecuente es que el nombre común no coincida con el nombre con que otros equipos llaman al servidor. En ese caso, el cliente rechaza el certificado aunque esté bien firmado.

De la solicitud al certificado instalado

El equipo genera el par de claves. La privada se queda en el equipo; la pública va en la solicitud
Se arma la CSR con el nombre distinguido. Clave pública, nombre común y datos de la organización
La CA valida y firma. La información de la solicitud pasa al certificado, junto con emisor, validez y número de serie
El certificado vuelve al equipo. Se instala en DER o PEM y se presenta en cada conexión TLS

Certificados firmados por una CA y autofirmados

Existe una alternativa a pedir la firma de una autoridad: crear un certificado autofirmado (self-signed), firmado con la propia clave privada del equipo. Cifra de la misma manera que uno emitido por una CA. La diferencia es la confianza: nadie más garantiza la identidad del titular, y el navegador muestra una advertencia de que el certificado no es confiable.

Los certificados autofirmados se usan en servidores no públicos o de pruebas. En producción, cuando cliente y servidor se autentican con certificado como pide IEC 62351-3, deben emitirlos una CA confiable, como explica la parte 9 de la serie. El orden de pasos para generar la cadena de certificados de un enlace con TLS está en Certificados X.509 para ICCP e IEC 104.

Qué revisar antes de cargar un certificado en un equipo

Que las fechas de validez cubran el periodo de servicio previsto, y que el equipo tenga la hora correcta.
Que el nombre común coincida con el nombre o la dirección con que se contactará al equipo.
Que el emisor sea una autoridad que el otro extremo tiene cargada como confiable.
Que el formato (DER o PEM) sea el que el equipo acepta.
Que la clave privada esté protegida y no se haya copiado a otros equipos.
Que exista un plan de renovación antes del vencimiento.

Las definiciones de los términos de este tema, como autoridad certificadora, texto cifrado o certificado, están en el glosario de IEC 62351-2.

¿Necesita preparar los certificados de sus equipos?

Nuestro equipo define y configura la seguridad de relés, pasarelas y sistemas SCADA, incluida la carga de certificados y la verificación de que los enlaces seguros quedan operativos. Conozca nuestro servicio de ciberseguridad de subestaciones y plantas o cuéntenos su caso por contacto.

Guías relacionadas

Referencias

Recomendación UIT-T X.509, Public-key and attribute certificate frameworks.
IEC 62351-3 y IEC 62351-9, seguridad de comunicaciones y gestión de claves en sistemas de potencia.
IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile.

Preguntas frecuentes

¿Qué diferencia hay entre los formatos DER y PEM?

Ambos codifican el mismo certificado. DER es la codificación binaria definida por las reglas de codificación distinguida de ASN.1. PEM es una representación de texto con cabeceras de inicio y fin, que se puede copiar y pegar. El contenido del certificado es el mismo; lo que cambia es cómo se escribe. Cada equipo acepta uno o ambos formatos.

¿Qué lleva una solicitud de firma de certificado (CSR)?

La clave pública de un par de claves y datos adicionales sobre el titular, como el nombre común y la organización. La clave privada no viaja: se queda en el equipo que generó la solicitud. La autoridad certificadora toma esos datos, los inserta en el certificado y lo firma.

¿Un certificado firmado por el propio equipo sirve en una subestación?

Cifra igual que uno firmado por una autoridad certificadora, pero nadie externo puede comprobar la identidad del titular. Por eso se limita a servidores no públicos o de pruebas. En producción, con autenticación mutua entre equipos, lo habitual es que los certificados los firme una autoridad en la que ambos extremos confían.