1. Introducción

La Criptografía aplicada y PKI es la disciplina que sostiene casi todo lo que damos por seguro en un sistema conectado: el cifrado de una sesión HTTPS, la firma de un documento, la autenticación mutua entre servicios y la cadena de confianza que hace que tu navegador se fíe de un certificado emitido por una CA pública. Sin embargo, la teoría de los libros de texto choca con la realidad del día a día: claves sin rotar desde hace años, certificados caducados que tiran servicios en producción, y firmas que se validan mal porque nadie revisó el algoritmo de hash. En este artículo te explico la Criptografía aplicada y PKI desde la práctica: conceptos criptográficos que debes dominar, estructura de los certificados X.509, un laboratorio completo con OpenSSL para montar tu propia CA, firmas digitales paso a paso y buenas prácticas de gestión del ciclo de vida de las claves. La Criptografía aplicada y PKI se domina en el terminal, no en los libros, y este texto está pensado para abrirlo junto a una máquina. Todo el contenido es reproducible en una máquina Ubuntu o Debian.

2. Fundamentos criptográficos que debes dominar

Antes de tocar una línea de OpenSSL, conviene fijar los tres bloques sobre los que se asienta toda la Criptografía aplicada y PKI: criptografía simétrica, asimetría y funciones hash. La simétrica (AES-256-GCM, ChaCha20) es rápida y cifra los datos en reposo y en tránsito, pero exige compartir la misma clave por un canal seguro, que es exactamente el problema del huevo y la gallina. La asimétrica (RSA, ECDSA, Ed25519) resuelve ese intercambio con un par de claves: la pública se distribuye libremente y la privada jamás sale del dispositivo de origen. Las funciones hash (SHA-256, SHA-384) garantizan integridad y, combinadas con una clave privada, producen firmas digitales.

La criptografía asimétrica es lenta; por eso los protocolos reales la usan solo para negociar una clave de sesión simétrica y cifran el resto del diálogo con ella. Ese diseño híbrido es el que verás en TLS 1.3, en OpenVPN y en la mayoría de los cifrados de disco. En la Criptografía aplicada y PKI este punto es clave para no caer en errores de diseño: cifrar todas las conexiones con RSA sería inviable, y confiar la confidencialidad solo a la simétrica imposibilita la gestión de claves a escala. Comprender ese reparto de funciones permite leer cualquier diseño basado en Criptografía aplicada y PKI.

Mi recomendación de mínimos para 2026 es: AES-256-GCM para cifrado de datos, SHA-256 o superior para integridad, y curvas elípticas (P-256 o Ed25519) para firmas e intercambio de claves, dejando RSA solo para interoperabilidad heredada. La hoja de referencia de criptografía de la OWASP sobre almacenamiento criptográfico es un resumen ejecutivo excelente para fijar estos mínimos antes de escribir código.

3. Certificados digitales y la infraestructura X.509

Un certificado digital es el documento con el que una Criptografía aplicada y PKI bien diseñada une una identidad a una clave pública. La estructura estándar se define en el RFC 5280: versión, número de serie, algoritmo de firma, emisor, periodo de validez, sujeto, clave pública e extensiones como Subject Alternative Name, uso de clave y restricciones de la CA. Valida tu propia instalación con openssl x509 -in ca.crt -noout -text y verás todos los campos: cada uno de ellos participa en una decisión de confianza.

3.1 Jerarquía de CA y cadenas de confianza

La CA raíz emite certificados intermedios y estos a su vez emiten los certificados de servidor o de usuario; el cliente solo confía en la raíz y valida la cadena verificando cada firma hasta llegar a ella. Esa jerarquía es la razón por la que una CA raíz comprometida fuerza a regenar todo el ecosistema, mientras que una intermedia comprometida se revoca con un impacto mucho menor. En la Criptografía aplicada y PKI corporativa, la separación raíz-intermedios es una de las primeras decisiones de diseño y conviene tomarla antes de emitir el primer certificado.

Otra distinción práctica: certificados para TLS de servidor (clientAuth/serverAuth), certificados de firma de código, certificados de firma de correo (S/MIME) y certificados de firma de documentos. El campo Extended Key Usage limita exactamente qué puede hacer cada certificado, y respetarlo es parte del buen oficio. Un detalle que se repite en las auditorías: certificados emitidos con usos demasiado amplios acaban firmando documentos que no debían o actuando como servidor TLS sin control. Ese control de uso es una asignatura pendiente habitual en la Criptografía aplicada y PKI corporativa.

4. Laboratorio: montar una PKI con OpenSSL

Nada fija mejor la Criptografía aplicada y PKI que montar tu propia CA en un equipo aislado. El laboratorio siguiente crea la estructura de directorios, genera la CA raíz fuera de línea y emite un certificado de servidor firmado. Empieza por el fichero de configuración de la CA:

[ ca ]
default_ca = jaymon_ca

[ jaymon_ca ]
dir               = ./ca
database          = $dir/index.txt
new_certs_dir     = $dir/newcerts
certificate       = $dir/ca.crt
private_key       = $dir/private/ca.key
serial            = $dir/serial
default_md        = sha256
policy            = policy_loose
default_days      = 825

[ policy_loose ]
countryName             = optional
stateOrProvinceName     = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied

Fig. 1 – openssl.cnf: configuración mínima de una CA con OpenSSL.

Con el fichero en su sitio, generamos los materiales y la raíz. La clave de la CA debe estar cifrada con AES-256 y, idealmente, en un dispositivo sin red:

mkdir -p ~/pki/ca/{newcerts,crl,private}
cd ~/pki/ca
touch index.txt
echo 1000 > serial
openssl genrsa -aes256 -out private/ca.key 4096
openssl req -x509 -new -key private/ca.key -sha256 -days 3650 \
  -out ca.crt -config openssl.cnf \
  -subj "/C=ES/ST=Madrid/O=Jaymon Security/CN=Jaymon Security CA Root"

Fig. 2 – Generación de la clave raíz y autofirma del certificado de la CA.

El comando genrsa pide dos veces la passphrase que protegerá la clave; si la pierdes, no hay recuperación posible. La raíz queda autofirmada por su propia clave privada y es el único certificado del laboratorio que se autofirma. Guarda esta máquina apagada y sin conexión: la Criptografía aplicada y PKI reserva la operación de la raíz para contadas ocasiones al año.

4.1 Emisión de un certificado de servidor

Con la CA operativa, la emisión se hace en dos pasos: el sujeto genera su par de claves y solicitud de firma (CSR), y la CA valida y firma. La clave privada del servidor jamás debe copiarse a la máquina de la CA:

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr \
  -subj "/C=ES/O=Jaymon Security/CN=servidor.jaymonsecurity.es"
openssl ca -config openssl.cnf -in server.csr -out server.crt \
  -days 825 -notext -extensions server_cert
openssl x509 -in server.crt -noout -text | head -30

Fig. 3 – Solicitud de firma y emisión del certificado de servidor.

Fíjate en el flujo: la CA no conoce la clave privada del servidor y el servidor no conoce ni la clave ni la passphrase de la CA. Esa separación de responsabilidades es la base de confianza de toda la Criptografía aplicada y PKI. La salida del último comando debe mostrar el sujeto, el emisor y el periodo de validez; la cadena completa se valida con openssl verify -CAfile ca.crt server.crt.

Si tu objetivo es producción, sustituye esta CA casera por materiales de una entidad certificada (Let’s Encrypt para TLS público o tu KMS corporativo para uso interno) y dedica este laboratorio a entender lo que haces. La documentación oficial de OpenSSL te servirá para sacar el máximo partido a cada parámetro. El laboratorio ya te ha enseñado por qué la profesión separa emisor y sujeto: esa es la huella de una Criptografía aplicada y PKI madura.

5. Firmas digitales: crear y validar en la práctica

Una firma no cifra el contenido: demuestra que el documento llegó íntegro y que una clave privada concreta lo avaló. El flujo es invertir los papeles de la confidencialidad —se cifra un resumen con la clave privada y cualquiera lo descifra con la pública— y sobre esa base se asienta una buena parte de la Criptografía aplicada y PKI. El ejemplo siguiente firma y verifica un documento con la clave del servidor del laboratorio:

echo "Contrato de servicios - Jaymon Security - 2026" > contrato.txt
openssl dgst -sha256 -sign server.key -out contrato.sig contrato.txt
# Extraemos la clave pública y verificamos la firma
openssl pkey -in server.key -pubout -out server_pub.pem
openssl dgst -sha256 -verify server_pub.pem \
  -signature contrato.sig contrato.txt

Fig. 4 – Firma digital de un documento y verificación con la clave pública.

El resultado de la verificación debe ser Verified OK. Cambia una letra del contrato y repite: la firma fallará, demostrando que la integridad del documento está protegida por el hash. En entornos empresariales, las firmas de documentos se apoyan normalmente en formatos como PDF-ASIC o CAdES que añaden sello de tiempo; en todos ellos el motor criptográfico subyacente es el mismo que acabas de ejecutar. Dominar este bucle firmar-verificar es el rito de paso de quien trabaja con Criptografía aplicada y PKI.

5.1 Errores de validación que verás en producción

Cuando una validación falla, la causa suele ser una de estas tres: el certificado está caducado, el nombre del sujeto no coincide con el dominio (mismatch de CN/SAN) o falta la raíz/intermedia en el almacén de confianza. La primera línea de diagnóstico en cualquier sistema es preguntar «¿quién firma a este certificado y confío yo en esa CA?». Entender ese camino de validación es más útil que memorizar parámetros: la Criptografía aplicada y PKI se domina sabiendo leer una cadena de certificados, no ejecutando comandos de memoria.

6. Gestión del ciclo de vida de las claves

La gestión es la parte menos glamurosa y más importante de la Criptografía aplicada y PKI. Una clave sin inventario, sin rotación y sin revocación pierde todo su valor. Sin rutina de gestión, incluso el diseño teórico más sólido de Criptografía aplicada y PKI se derrumba en el primer incidente. La tabla siguiente resume los materiales típicos y sus tamaños recomendados para 2026:

Material	Algoritmo recomendado	Tamaño/clave	Rotación recomendada	Uso habitual
Clave simétrica	AES-256-GCM	256 bits	Anual	Cifrado de datos y sesiones
Firma de servidor	ECDSA P-256 / Ed25519	256 / 256 bits	24-36 meses	TLS, autenticación mutua
Firma de documentos	RSA-3072 / ECDSA	3072 / 256 bits	18-24 meses	Firmas corporativas
Raíz de CA	RSA-4096 o ECDSA	4096 / 384 bits	5-10 años (manualmente)	Inicio de las cadenas de confianza

Tabla 1 – Algoritmos, tamaños y rotación recomendada de los materiales criptográficos.

La revocación merece su propio párrafo porque es donde más falla la operación diaria. Si una clave privada se filtra, el certificado debe revocarse y su estado debe publicarse en una CRL o consultarse por OCSP; los clientes que respetan esas listas rechazarán el material. Publicar el estado a tiempo es la operación más descuidada de la Criptografía aplicada y PKI operativa. En la práctica, el tiempo entre la detección del incidente y la publicación de la revocación es la métrica que mejores auditores premian. Mantén las CRL firmadas con frecuencia diaria y monitoriza el tráfico OCSP para detectar clientes que no consultan el estado del certificado.

En cuanto al almacenamiento, eleva ese portafolio: los HSM y los KMS gestionan las claves sin exponerlas al software de aplicación, y un módulo TPM puede custodiar claves de servidor en hardware. La Criptografía aplicada y PKI corporativa termina en el momento en que una clave se copia a un USB o se pega en un mensaje interno; desde ahí, todo el sistema se degrada. El programa de gestión de claves del NIST (NIST SP 800-57) es la referencia canónica si necesitas profundizar en periodos de validez y usos por algoritmo. La custodia en hardware es el cierre lógico de una Criptografía aplicada y PKI seria.

7. Conclusión

La Criptografía aplicada y PKI no es un tema de laboratorio: es el sistema nervioso de la confianza en tu infraestructura. Con los fundamentos claros, un laboratorio propio de CA con OpenSSL, la práctica de firmar y verificar documentos y una gestión rigurosa del ciclo de vida de las claves, tu equipo deja de depender de tutoriales sueltos y toma decisiones de cifrado con criterio técnico. La Criptografía aplicada y PKI recompensa a quien la trabaja con método.

Resumen accionable: cifra con AES-256-GCM, firma con ECDSA o Ed25519, mantén raíz e intermedios separados, rota con calendario, revoca y publica estado en cuestión de minutos, y custodia las claves en hardware siempre que el presupuesto lo permita. La próxima vez que un certificado caduque un viernes a las 17:00, tu equipo sabrá exactamente qué hacer, cómo auditorar el material y dónde documentarlo.

Artículos relacionados: guía completa para proteger carteras de criptomonedas y ingeniería inversa y programación de keygens.

¿Necesitas ayuda con Criptografía aplicada y PKI?

En Jaymon Security ayudamos a las organizaciones a proteger sus sistemas. Desde auditorías de seguridad hasta implementación de SIEM/SOC, nuestro equipo de expertos diseña soluciones a medida.

Contacta con nosotros para una evaluación gratuita de tu infraestructura.