Filtros
Nivel
Artículos (116)
Wiki/Fundamentos/PKI y Certificados Digitales
Intermedio20 min lectura

PKI y Certificados Digitales

Infraestructura de Clave Pública: CA raíz, X.509, CSR, cadena de confianza, CRL y OCSP

¿Qué es PKI?

La Infraestructura de Clave Pública (PKI) es un conjunto de roles, políticas, hardware, software y procedimientos para crear, gestionar, distribuir, usar, almacenar y revocar certificados digitales. Resuelve el problema fundamental: ¿cómo saber que una clave pública pertenece realmente a quien dice ser?

Sin PKI, cualquiera podría publicar una clave pública como si fuera de tu banco. PKI introduce una tercera parte de confianza (CA) que firma y avala la asociación entre clave pública e identidad.

Componentes de PKI

CA Raíz (Root CA)

La autoridad suprema de confianza. Su certificado viene preinstalado en navegadores y sistemas operativos. Está offline en HSMs aislados. Nunca emite certificados a usuarios directamente.

CA Intermedia (Intermediate CA)

Firmada por la CA raíz; emite certificados a entidades finales. Si se compromete, se revoca sin afectar la CA raíz. DigiCert, Let's Encrypt y similares operan ICA.

Certificado (X.509)

Documento digital que vincula una clave pública con una identidad (dominio, persona, organización). Firmado por una CA. El navegador verifica esta firma para confiar en la clave.

RA — Registration Authority

Verifica la identidad del solicitante antes de pedir al CA que emita el certificado. Separa la verificación de identidad de la firma del certificado.

CRL — Certificate Revocation List

Lista de certificados revocados antes de su expiración. El cliente descarga la lista periódicamente. Puede ser grande y desactualizada.

OCSP — Online Certificate Status Protocol

Alternativa a CRL. El cliente consulta en tiempo real el estado de un certificado. OCSP Stapling: el servidor incluye la respuesta OCSP en el TLS handshake (más eficiente).

Anatomía de un Certificado X.509

$ openssl x509 -in cert.pem -text -noout

Version: 3 (X.509v3)

Serial Number: 04:...:ff

Issuer: C=US, O=Let's Encrypt, CN=R10

Subject: CN=example.com

Validity: Not Before: Apr 1 00:00:00 2026

Not After : Jun 30 23:59:59 2026

Subject Public Key Info: id-ecPublicKey, P-256

X509v3 Subject Alternative Name:

DNS:example.com, DNS:www.example.com

X509v3 Key Usage: Digital Signature

X509v3 Extended Key Usage: TLS Web Server Authentication

Signature Algorithm: sha256WithRSAEncryption

Flujo de Emisión: CSR → Certificado

1

Generar par de claves

openssl ecparam -name prime256v1 -genkey -noout -out key.pem
2

Crear CSR (Certificate Signing Request)

openssl req -new -key key.pem -out request.csr -subj "/CN=example.com"
3

CA verifica identidad y firma

← La CA comprueba que controlas el dominio (DNS-01, HTTP-01 challenge)
4

Obtener certificado firmado

openssl x509 -req -in request.csr -CA ca.pem -CAkey ca-key.pem -out cert.pem -days 90
5

Desplegar en servidor web

ssl_certificate /etc/ssl/cert.pem; ssl_certificate_key /etc/ssl/key.pem;

Tipos de Validación

DV — Domain Validation

Valida solo que controlas el dominio. Emitido en minutos. Let's Encrypt es DV. Muestra candado pero no identidad de empresa.

OV — Organization Validation

Valida dominio + existencia legal de la organización. Proceso manual, 1-3 días. Muestra nombre de empresa en el certificado.

EV — Extended Validation

Validación más rigurosa de identidad corporativa. Antes mostraba barra verde en browsers; hoy sin indicador visual especial en Chrome/Firefox.

Let's Encrypt y Automatización

Let's Encrypt (ISRG, 2015) democratizó los certificados TLS gratuitos mediante el protocolo ACME. Certbot y acme.sh automatizan renovación cada 90 días. La mayoría de proveedores cloud integran esto nativamente.

# Obtener certificado con Certbot (Nginx)

certbot --nginx -d example.com -d www.example.com

# Renovación automática (cron/systemd)

certbot renew --pre-hook "nginx -s stop" --post-hook "nginx"

Ataques contra PKI

CA Compromise

Si una CA es hackeada, puede emitir certificados fraudulentos para cualquier dominio. Caso DigiNotar (2011) con certificados falsos de *.google.com.

Certificate Pinning bypass

Apps que hacen pinning del certificado son resistentes a CAs comprometidas, pero dificultan actualizaciones legítimas y pueden romperse si no se gestiona bien.

BGP hijacking + mis-issuance

Redirigir tráfico BGP para completar un HTTP-01 ACME challenge y obtener un certificado DV para un dominio que no controlas.

Wildcard cert abuse

*.example.com es válido para cualquier subdominio. Si un subdominio se compromete, el certificado wildcard expone todos los subdominios.

Siguiente Paso

Entiende cómo el modelo OSI ubica los controles de seguridad en cada capa de red

Modelo OSI y TCP/IP →