Certificados SSL/TLS — Qué Significan Esas Campos y Fechas de Vencimiento

En algún momento has mirado la pequeña cerradura en el navegador, has clicado en "Ver certificado" y has sido confrontado con una pared de campos que parecen importantes pero que no explican nada: "Nombres alternativos del sujeto", "OCSP", "SHA-256 con encriptación RSA". Cierres el diálogo. El certificado está verde. Eso es suficiente.

Hasta que expire. A medianoche un viernes. En producción.

Este artículo explica lo que realmente contiene un certificado TLS — campo por campo — para que, la próxima vez que tengas que diagnosticar uno, sepas lo que estás leyendo.

Un certificado es simplemente un documento firmado

Quita la ceremonia y un certificado TLS es un documento de texto que contiene algunos hechos — quién posee este dominio, qué clave pública usan, cuándo vence el documento — que ha sido firmado criptográficamente por una autoridad de certificados (CA). La firma de la CA es lo que hace que los navegadores lo confíen. Todo lo demás es anotación.

El formato subyacente se llama X.509. Fue definido en 1988, revisado varias veces y ahora está especificado en RFC 5280. Es por eso que los diálogos de detalles de certificados en navegadores se ven como si hubieran sido diseñados por personas que consideran el año 1988 una época reciente.

Los campos clave, explicados

Aquí tienes un desglose anotado de los campos que verás en un certificado real. Los datos en formato PEM a continuación son representativos (no un certificado en vivo):

Certificate:
  Data:
    Version: 3 (0x2)                          # Always v3 for modern certs
    Serial Number:                             # Unique ID issued by the CA
      04:b3:c2:...(truncated)
    Signature Algorithm: sha256WithRSAEncryption  # Hash + key algorithm used to sign
    Issuer:
      C  = US                                 # Country
      O  = Let's Encrypt                      # Organization (the CA)
      CN = R11                                # Common Name of the issuer
    Validity:
      Not Before: Apr  1 00:00:00 2026 GMT    # Cert isn't valid before this date
      Not After : Jun 30 23:59:59 2026 GMT    # Cert is invalid after this date
    Subject:
      CN = iotools.cloud                      # Domain this cert was issued for
    Subject Public Key Info:
      Public Key Algorithm: rsaEncryption
      Public-Key: (2048 bit)                  # RSA key size
    X509v3 extensions:
      Subject Alternative Names:
        DNS:iotools.cloud                     # All domains this cert covers
        DNS:www.iotools.cloud
      Key Usage: Digital Signature, Key Encipherment
      Extended Key Usage: TLS Web Server Authentication
      Basic Constraints: CA:FALSE             # This is NOT a CA cert
      Authority Key Identifier: ...           # Fingerprint of issuer's key
      Subject Key Identifier: ...             # Fingerprint of this cert's key
      Certificate Policies: ...
        CPS: http://cps.letsencrypt.org
      OCSP: http://r11.o.lencr.org           # Where to check revocation status

Nombre común (CN)

El campo original para especificar qué dominio cubre el certificado. Aún lo verás llenado — CN = example.com — pero los navegadores ya no dependen en gran medida de él. Desde 2000, la extensión de Nombres Alternativos del Sujeto es el campo autorizado para el match de dominios. El CN es ahora prácticamente obsoleto; si existe SAN, los navegadores usan solo SAN.

Nombres alternativos del sujeto (SAN)

Este es la lista real de dominios que protege el certificado. Un solo certificado puede cubrir decenas de nombres — entradas de tipo wildcard (*.example.com), nombres exactos, incluso direcciones IP. Los certificados multidominio (a veces llamados certificados SAN o UCC) son una práctica estándar. La autoridad de certificados los emite según esta lista, y los navegadores comparan el nombre de host que estás visitando con ella.

Una cosa que los wildcards no pueden hacer: cubrir sub-subdominios. *.example.com cubre app.example.com pero no api.v2.example.com. Muchas personas lo descubren de forma difícil.

Periodo de validez

Dos fechas: Antes de que comience y Después de que termine. El certificado es inválido fuera de ese intervalo — antes de la fecha de inicio, después de la fecha de vencimiento. Ambas están en UTC.

Los máximos de duración de los certificados han estado reduciéndose progresivamente. En 2015 el máximo era de 3 años. En 2018 se redujo a 2 años. En 2020, Apple inició unilateralmente la rechazo de certificados más largos de 398 días (aproximadamente 13 meses), obligando a los fabricantes de navegadores y a las autoridades de certificados a seguirlo. Hasta 2026, el CA/Browser Forum ha aprobado un plan para reducirlo a 47 días para 2027.

La argumentación en favor de duraciones más cortas es sólida: si una clave privada ha sido comprometida, un certificado de corta duración limita el alcance del daño. La realidad operativa es que duraciones más cortas ponen más presión en que tus automatizaciones de renovación sean correctas. Los certificados de 90 días de Let’s Encrypt fueron controvertidos en 2015 por la misma razón; ahora se consideran la práctica recomendada y se espera que se realicen renovaciones automatizadas.

Emisor y la cadena de confianza

El Editor los nombres de campo indican la entidad que firmó el certificado. Para la mayoría de los sitios públicos, este es un CA intermedio (como el R11 de Let’s Encrypt), no un CA raíz. Los CAs raíz firman certificados de CAs intermedias; los CAs intermedios firman certificados de entidad final (los que presenta tu servidor). Esta cadena existe porque las claves privadas de los CAs raíz se mantienen fuera de línea en HSMs aislados, y no puedes exponer una clave para firmar millones de certificados por año.

Cuando un navegador valida tu certificado, recorre la cadena: tu certificado → intermedio → raíz. Si la raíz está en el almacén de confianza del navegador, la cadena se valida. Si algún certificado en la cadena está faltando, vencido o firmado con una clave revocada, la validación falla.

Es por eso que la configuración TLS más común incorrecta es olvidar servir el certificado intermedio junto con tu certificado de hoja. Tu navegador podría cachear el intermedio y parecerse bien, mientras que otros clientes — curl, aplicaciones móviles, servidores que hacen llamadas de API — fallan porque no tienen un camino hacia la raíz.

Algoritmo de firma

Dos cosas agrupadas en un solo campo: la función de hash utilizada para digerir los datos del certificado y el algoritmo de clave utilizado para firmar esa digesta. sha256WithRSAEncryption significa hash SHA-256, firma RSA. ecdsa-with-SHA256 significa hash SHA-256, firma ECDSA.

Las firmas SHA-1 fueron descontinuadas por los navegadores en 2017 y ahora causan fallos graves. Las firmas MD5 fueron descontinuadas antes y están prácticamente extinguidas. Si estás ejecutando cualquier sistema que emita certificados SHA-1 internamente, actualiza tu configuración del CA antes de que un navegador lo haga por ti.

Las firmas ECDSA (normalmente P-256 o P-384) producen claves y firmas más pequeñas que RSA para una seguridad equivalente. Una clave EC de 256 bits es aproximadamente equivalente a una clave RSA de 3072 bits. El costo: RSA es más compatible con clientes muy antiguos; ECDSA es más rápido y ligero. Las implementaciones modernas suelen configurar ambas y dejar que la negociación de TLS elija.

Uso de la clave y uso extendido de la clave

Uso de la clave es un bitmás que especifica qué operaciones puede realizar la clave: firmar datos, cifrar datos, firmar otros certificados (solo para CAs). Uso extendido de la clave refina esto para protocolos específicos: TLS Web Server Authentication es lo que permite que el certificado se use para HTTPS. TLS Web Client Authentication es para certificados de clientes en mTLS. Code Signing es para certificados de firma de software.

Si intentas usar un certificado para un propósito fuera de su uso declarado de clave, las implementaciones modernas de TLS lo rechazarán. No puedes tomar un certificado de firma de código y usarlo en un servidor web, incluso si el dominio coincide.

Restricciones básicas: CA:FALSE

Este campo especifica si el certificado puede usarse para firmar otros certificados. CA:FALSE significa que no puede — es un certificado de hoja (de entidad final). CA:TRUE significa que es un certificado de CA, permitido para firmar otros certificados en la cadena.

El pathLenConstraint que a veces aparece junto a esto te dice cuántos CAs intermedios bajo este uno están permitidos. Los CAs raíz suelen establecerlo para limitar la profundidad de la cadena.

OCSP y revocación

La URL del protocolo OCSP (Online Certificate Status Protocol) en el certificado indica a los clientes dónde verificar si el certificado ha sido revocado antes de que expire. La revocación ocurre cuando una clave privada ha sido comprometida o el certificado fue emitido por error.

En la práctica, el control de OCSP en los navegadores tiene una historia complicada. Chrome dejó de hacer verificaciones en línea de OCSP hace años en favor de CRLSets (una lista pre-cargada de certificados revocados de alto valor). Firefox sigue haciendo OCSP pero predetermina un fallo suave, lo que significa que si el servidor OCSP no está disponible, el certificado se trata como válido. El efecto neto: para la mayoría de los certificados, la revocación en el mundo real es algo teórico. Esto es una de las razones para certificados de corta duración — a 47 días, la revocación importa menos porque el certificado vence pronto.

¿Por qué los certificados caducan?

La caducidad no es una fricción burocrática. Es el mecanismo que limita cuánto tiempo permanece válido un credencial comprometido. La alternativa — credenciales permanentes — es cómo terminas con certificados SHA-1 y claves de CA de décadas flotando en producción, lo cual era en gran parte la situación de la industria en 2010.

La compensación es operativa: duraciones más cortas requieren automatización confiable. Si tu renovación depende de un recordatorio de un administrador de sistemas, eventualmente caducarás en producción. La respuesta correcta es la renovación automatizada mediante ACME (el protocolo de Let’s Encrypt) o a través de la API de tu CA, con monitoreo que avise varias semanas antes de la caducidad en lugar de la noche en que muere.

Cómo leer un certificado sin usar la línea de comandos

La forma estándar de inspeccionar un certificado es openssl x509 -in cert.pem -text -noout, que produce salida formateada para personas que encuentran la lectura de RFC 5280 fácil. Si deseas la misma información en un formato que no requiera memorizar flags de openssl, el Decodificador de Certificados SSL/TLS y Analizador de Certificados X.509 en iotools.cloud ambos toman un certificado en formato PEM y devuelven todos los campos etiquetados y organizados — útil cuando estás diagnosticando un problema de cadena a medianoche y el texto largo de openssl no te ayuda.

También te puede interesar