1. Objetivos de la práctica

Los objetivos que se pretenden alcanzar con esta práctica son los siguientes:

  • Comprender el funcionamiento y la arquitectura básica de una Infraestructura de Clave Pública (PKI).

  • Diferenciar los roles y responsabilidades de la CA raíz, la CA intermedia, el servidor y el cliente.

  • Implementar una PKI funcional en sistemas Linux utilizando OpenSSL.

  • Emitir, validar y revocar certificados digitales, comprendiendo su ciclo de vida completo.

  • Configurar un servicio HTTPS utilizando certificados emitidos por una CA propia.

  • Aplicar principios de bastionado y separación de funciones en el diseño de la infraestructura.

2. Conceptos básicos

2.1 Introducción a la PKI

La Infraestructura de Clave Pública (PKI) es un pilar fundamental en la seguridad de redes y sistemas, ya que permite establecer confianza, autenticidad, integridad, cifrado y no repudio mediante el uso de certificados digitales y criptografía asimétrica.

En entornos profesionales, una PKI no se despliega en una sola máquina, sino que se basa en la separación estricta de roles, el aislamiento de componentes críticos y el principio de mínimo privilegio.

En esta práctica, deberá diseñar e implementar una PKI sobre sistemas Linux, siguiendo criterios de bastionado de sistemas y arquitectura segura.

2.2 Flujo conceptual de una PKI

La siguiente imagen representa de forma esquemática y didáctica, el funcionamiento de una Infraestructura de Clave Pública (PKI) y los roles principales que intervienen en ella.

La imagen muestra que una PKI no es solo una CA, sino un conjunto de roles y procesos que permiten:

  • Emitir certificados.

  • Verificar identidades.

  • Validar el estado de los certificados.

  • Establecer confianza en servicios digitales.

Infraestructura de clave pública (PKI). Imagen obtenida de https://es.wikipedia.org/wiki/Infraestructura_de_clave_p%C3%BAblica[Wikipedia.]
Figura 1. Infraestructura de clave pública (PKI). Imagen obtenida de Wikipedia.

En la imagen podemos distinguir los siguientes procesos:

  1. El usuario genera un par de claves (pública y privada) y solicita un certificado.

  2. La RA (Registration Authority) actúa como intermediaria entre el usuario y la CA:

    • Verifica la identidad del solicitante para evitar la emisión idebida de certificados.

    • Aprueba o rechaza solicitudes de certificados.

    • No firma certificados, solo valida identidades.

  3. La CA (Certification Authority) emite y firma el certificado vinculando una identidad con una clave pública. Es el núcleo de la confianza.

  4. El certificado se usa en servicios, en la imagen se usa en un sitio web para:

    • Establecer conexiones seguras

    • Garantizar autenticidad y cifrado (HTTPS)

  5. La VA (Validation Authority) permite comprobar si el certificado sigue siendo válido.

    • Proporciona mecanismos de revocación (CRL, OCSP).

    • Asegura que los certificados comprometidos o caducados no se usen.

En esta práctica, las funciones de la Autoridad de Registro (RA) y de la Autoridad de Validación (VA) no se implementan como componentes independientes.

Por simplicidad didáctica, estas funciones se asumen implícitamente dentro del rol de la CA intermedia, que valida las solicitudes de certificados, emite certificados y gestiona la revocación mediante CRL.

En entornos reales de producción, la separación entre CA, RA y VA suele ser explícita, especialmente en infraestructuras de gran escala o con requisitos regulatorios estrictos.

2.3 Diferencia entre PKI Pública y Privada

Una Infraestructura de Clave Pública puede clasificarse, según su ámbito de confianza y gestión, en PKI pública o PKI privada. La diferencia entre ambas no es técnica, sino organizativa y de confianza.

PKI pública

En una PKI pública, los certificados digitales son emitidos por Autoridades de Certificación (CA) públicas, como DigiCert o Let’s Encrypt, reconocidas y preinstaladas como confiables en los navegadores web y sistemas operativos.

El usuario final no decide explícitamente en qué CA confiar, la confianza viene determinada por el fabricante del sistema o del navegador.

Características principales:

  • Los certificados son válidos y reconocidos globalmente.

  • Los clientes confían automáticamente en la CA emisora.

  • Está orientada a servicios expuestos a Internet, como sitios web públicos.

  • La gestión de la CA está en manos de un tercero externo.

  • Menor control sobre políticas de emisión, revocación y tiempos de respuesta ante incidentes.

PKI privada

En una PKI privada, la propia organización crea y gestiona su Autoridad Certificadora, definiendo de forma explícita en qué certificados se confía y por qué.

Los certificados solo son considerados válidos en los sistemas donde el certificado raíz de la CA raíz ha sido instalado como ancla de confianza o trust anchor.

Características principales:

  • La confianza es interna y controlada por la organización.

  • Permite definir políticas personalizadas de emisión y revocación.

  • No depende de terceros externos.

  • Requiere una gestión cuidadosa de claves y certificados.

  • Es ideal para:

    • Servicios internos

    • Infraestructuras corporativas

    • VPN, autenticación de usuarios

    • Entornos industriales, IoT o laboratorios

2.4 Niveles de Jerarquía en PKI

Una PKI se organiza normalmente en forma de jerarquía de autoridades certificadoras, con el objetivo de limitar el impacto de un compromiso y mejorar la seguridad y la gestión de certificados. Existen varios niveles de jerarquía, siendo los más comunes:

  • Un nivel (Single-tier):

    Una única CA actúa como Raíz y Emisora. Es muy arriesgado y no recomendado, ya que si la clave privada de la Raíz se ve comprometida, toda la infraestructura cae y todos los certificados deben ser revocados.

    Diagrama de la arquitectura PKI con un nivel. Imagen obtenida de: https://www.thesslstore.com/blog/pki-architecture-fundamentals-of-designing-a-private-pki-system/[The SSL Store.]
    Figura 2. Diagrama de la arquitectura PKI con un nivel. Imagen obtenida de: The SSL Store.

  • Dos niveles (Two-tier):

    Es el estándar recomendado para la mayoría de casos. Consiste en una CA Raíz Offline (desconectada para seguridad) que firma a una CA Emisora Online. La CA Emisora es la que entrega los certificados finales. Si la emisora se ve comprometida, la Raíz sigue segura.

    Este modelo es el más utilizado en entornos empresariales reales, ya que equilibra adecuadamente seguridad, simplicidad operativa y capacidad de respuesta ante incidentes.

    Diagrama de la arquitectura PKI con dos niveles. Imagen obtenida de: https://www.thesslstore.com/blog/pki-architecture-fundamentals-of-designing-a-private-pki-system/[The SSL Store.]
    Figura 3. Diagrama de la arquitectura PKI con dos niveles. Imagen obtenida de: The SSL Store.

  • Tres niveles (Three-tier):

    Añade una CA Intermedia entre la Raíz y la Emisora. Ofrece mayor seguridad y escalabilidad, pero añade complejidad.

    Diagrama de la arquitectura PKI con tres niveles. Imagen obtenida de: https://www.thesslstore.com/blog/pki-architecture-fundamentals-of-designing-a-private-pki-system/[The SSL Store.]
    Figura 4. Diagrama de la arquitectura PKI con tres niveles. Imagen obtenida de: The SSL Store.

2.5 Recursos adicionales

Se recomienda consultar los siguientes recursos de Wikipedia para ampliar los conceptos básicos relacionados con la PKI:

2.6 Importancia de las extensiones X.509

Los certificados X.509 modernos no solo contienen información de identidad, sino también extensiones críticas que definen cómo y para qué puede usarse un certificado.

Algunas extensiones clave son:

  • basicConstraints
    Indica si un certificado puede actuar como Autoridad Certificadora (CA).
    Marcar CA:false en certificados de servidor evita que puedan firmar otros certificados.

  • Key Usage
    Restringe criptográficamente los usos permitidos de la clave (firma, cifrado, etc.).
    Esta extensión suele marcarse como crítica para impedir usos indebidos.

  • Extended Key Usage (EKU)
    Especifica el propósito del certificado, como serverAuth para servidores TLS.

  • Subject Alternative Name (SAN)
    Define los nombres válidos del sujeto del certificado.
    Los navegadores modernos ignoran el campo Common Name (CN) si no existe una extensión SAN válida.

3. Escenario planteado

La empresa ficticia CeliaCorp necesita desplegar una Infraestructura de Clave Pública (PKI) interna con el objetivo de garantizar la autenticidad, confidencialidad e integridad de las comunicaciones entre sus sistemas.

La organización requiere una solución que le permita:

  • Emitir certificados digitales a servicios internos de forma controlada.

  • Evitar la dependencia de autoridades certificadoras públicas.

  • Mantener control total sobre la confianza, la emisión y la revocación de certificados.

  • Poder reaccionar ante incidentes de seguridad, como el compromiso de claves privadas o el uso indebido de certificados.

Para cumplir estos requisitos, CeliaCorp decide implantar una PKI basada en buenas prácticas de bastionado y separación de funciones, definiendo los siguientes componentes y responsabilidades:

  1. Crear una Autoridad Certificadora raíz (Root CA), altamente protegida, sin servicios expuestos y utilizada exclusivamente para crear un certificado raíz como ancla de confianza.

  2. Crear una Autoridad Certificadora intermedia (Intermediate CA), responsable de la emisión y revocación de certificados para servicios internos.

  3. Desplegar un servidor web que utilizará un certificado TLS emitido por la CA intermedia para ofrecer un servicio HTTPS seguro.

  4. Disponer de un cliente que valide correctamente la cadena de confianza completa y compruebe el estado de revocación de los certificados durante la conexión.

  5. Implementar un mecanismo de revocación que permita invalidar certificados antes de su fecha de caducidad y distribuir esta información a los clientes.

4. Arquitectura del laboratorio

4.1 Descripción de la arquitectura PKI

La infraestructura PKI que se implementará en esta práctica se basa en una arquitectura de dos niveles, compuesta por una CA raíz y una CA intermedia.

Esta arquitectura es la más común en entornos empresariales, ya que ofrece un equilibrio adecuado entre seguridad, simplicidad operativa y capacidad de respuesta ante incidentes.

  1. Autoridad Certificadora raíz (Root CA) Es el componente de mayor nivel de confianza dentro de la PKI. Su función principal es emitir y firmar el certificado de la CA intermedia. No emite certificados directamente a servidores ni clientes y no ejecuta servicios de red. Su certificado es el ancla de confianza para toda la infraestructura.

  2. Autoridad Certificadora intermedia (Intermediate CA) Actúa como intermediaria entre la CA raíz y los servicios finales. Es la encargada de emitir y firmar certificados para servidores y servicios internos. Depende de la CA raíz para establecer su legitimidad y debe estar protegida, aunque puede operar de forma online.

  3. Servidor web Es un sistema que ofrece un servicio HTTPS utilizando un certificado digital emitido por la CA intermedia. El servidor no firma certificados, sino que demuestra la posesión de su clave privada durante el establecimiento de la conexión TLS.

  4. Cliente Es el sistema que accede al servicio web. Durante la conexión HTTPS, el cliente verifica la cadena de confianza completa, comprobando que:

    • El certificado del servidor es válido

    • Ha sido emitido por la CA intermedia

    • La CA intermedia está firmada por la CA raíz

    • El certificado raíz es de confianza

4.2 Máquinas virtuales necesarias

El laboratorio estará compuesto por 4 máquinas virtuales Linux, cada una con un rol claramente diferenciado.

Cada máquina representa un componente real de una infraestructura PKI empresarial y está configurada únicamente con el software y los servicios estrictamente necesarios para su función.

Máquina Hostname Rol Función principal Software instalado Puertos abiertos

VM1

root-ca

CA raíz (Root CA)

Firma la CA intermedia y su certificado raíz actúa como ancla de confianza

openssl

22/TCP (SSH)

VM2

intermediate-ca

CA intermedia

Emite certificados para servidores

openssl

22/TCP (SSH)

VM3

web-server

Servidor HTTPS

Ofrece servicio HTTPS usando un certificado PKI

nginx, openssl

22/TCP (SSH), 80/TCP (HTTP), 443/TCP (HTTPS)

VM4

client

Cliente

Verifica la cadena de confianza y consume el servicio

openssl, curl

22/TCP (SSH)

4.3 Diagrama de la arquitectura

En esta práctica, se implementará una PKI con una arquitectura de dos niveles, compuesta por una CA raíz y una CA intermedia.

Diagrama de la arquitectura PKI con dos niveles. Imagen obtenida de: https://www.thesslstore.com/blog/pki-architecture-fundamentals-of-designing-a-private-pki-system/[The SSL Store.]
Figura 5. Diagrama de la arquitectura PKI con dos niveles. Imagen obtenida de: The SSL Store.

4.4 Cadena de confianza

La cadena de confianza en esta PKI se establece de la siguiente forma:

  1. El cliente confía previamente en el certificado de la CA raíz.

  2. La CA raíz certifica la identidad de la CA intermedia.

  3. La CA intermedia certifica la identidad del servidor web.

  4. El cliente, al conectarse al servidor web mediante HTTPS, valida toda la cadena de certificados antes de establecer la conexión segura.

Durante la conexión HTTPS, el servidor web presenta su certificado junto con el certificado de la CA intermedia, formando la cadena de certificados necesaria para que el cliente pueda validar la confianza hasta la CA raíz, donde su certificado raíz actúa como ancla de confianza.

Cadena de confianza en una PKI de dos niveles. Imagen basada en las imágenes de https://www.globalsign.com/es/blog/que-es-cadena-de-confianza[GlobalSign] y https://es.wikipedia.org/wiki/Certificado_ra%C3%ADz[Wikipedia.]
Figura 6. Cadena de confianza en una PKI de dos niveles. Imagen basada en las imágenes de GlobalSign y Wikipedia.

5. Emisión y gestión de certificados

5.1 Políticas de certificación

En una Infraestructura de Clave Pública (PKI), la emisión y gestión de certificados está regulada por las Políticas de Certificación (Certificate Policy, CP), que definen las reglas bajo las cuales una Autoridad Certificadora emite, utiliza y revoca certificados, estableciendo un marco de confianza claro y auditable.

Las políticas de certificación determinan aspectos como quién puede solicitar certificados, para qué usos son válidos, los algoritmos y tamaños de clave permitidos, los periodos de validez y los procedimientos de revocación.

En esta práctica no se implementará una CP formal, pero se asume que los certificados emitidos se destinan exclusivamente a servicios internos, que solo sistemas autorizados pueden solicitarlos y que la revocación forma parte del ciclo de vida normal de la PKI.

5.2 Creación de la CA raíz

En esta fase se desplegará la Autoridad Certificadora raíz (Root CA) y se creará el certificado raíz que actúa como ancla de confianza de toda la PKI y constituye el componente más crítico desde el punto de vista de seguridad.

En la máquina VM1 (root-ca), deberá:

  1. Crear la estructura de directorios de la CA raíz, necesaria para el correcto funcionamiento de OpenSSL como autoridad certificadora. Esta estructura deberá incluir, al menos:

    • Un directorio para los certificados emitidos.

    • Un directorio específico para las claves privadas, con permisos restrictivos.

    • Un directorio para las listas de revocación (CRL).

    • Un directorio para los certificados recién emitidos.

    • Archivos de control que permitan llevar el registro de certificados y la gestión de números de serie.

  2. Generar la clave privada de la CA raíz, utilizando un algoritmo y tamaño de clave robustos, y protegiéndola mediante contraseña y permisos adecuados.

  3. Crear un certificado raíz autofirmado, que servirá como punto inicial de confianza para toda la infraestructura PKI.

En entornos reales de producción, las claves privadas no se almacenan como archivos normales, sino dentro de Módulos de Seguridad Hardware (HSM) o dispositivos criptográficos equivalentes, de forma que no puedan ser extraídas, incluso aunque el sistema sea comprometido.

La correcta protección de estas claves es esencial para mantener la confianza y la seguridad de toda la PKI.

5.3 Creación de la CA intermedia

En esta fase se desplegará la Autoridad Certificadora intermedia (Intermediate CA), responsable de la emisión y revocación de certificados para los servicios internos.

En la máquina VM2 (intermediate-ca):

  1. Crear la estructura de una CA intermedia.

  2. Generar su clave privada.

  3. Crear una CSR (Certificate Signing Request).

  4. Enviar la CSR a la CA raíz.

  5. Recibir y almacenar el certificado firmado.

  6. Preparar la CA intermedia para emitir certificados.

5.4 Emisión de un certificado para un servidor

En esta fase se emitirá un certificado digital para un servidor web, que utilizará dicho certificado para ofrecer un servicio HTTPS seguro.

En la máquina VM3 (web-server):

  1. Generar la clave privada del servidor.

  2. Crear una CSR para el servidor web.

  3. Enviar la CSR a la CA intermedia.

  4. Recibir el certificado firmado.

    El certificado emitido para el servidor web debe incluir extensiones adecuadas para su uso en TLS, como Key Usage y Extended Key Usage, que permitan su utilización para autenticación de servidores web.

  5. Configurar un servicio HTTPS utilizando dicho certificado.

5.5 Validación desde el cliente

Los clientes mantienen un almacén de certificados de confianza (trust store), donde se instalan manualmente las CA raíz en PKI privadas.

Este almacén actúa como punto inicial de confianza durante la validación TLS, permitiendo al cliente verificar la cadena de certificados presentada por el servidor hasta una autoridad en la que confía.

En la máquina VM4 (client):

  1. Instalar el certificado raíz de la PKI.

  2. Conectarse al servidor web mediante HTTPS.

  3. Verificar correctamente la cadena de confianza.

  4. Comprobar que la conexión es segura y válida.

5.6 Pérdida del ancla de confianza

En este ejercicio se analizará el comportamiento del cliente cuando se rompe explícitamente la cadena de confianza de la PKI.

Este ejercicio demuestra que la confianza en una conexión TLS no depende del servidor, sino del almacén de certificados del cliente. Aunque el servidor siga presentando un certificado técnicamente válido y correctamente firmado, sin un ancla de confianza instalada, el cliente no puede establecer una relación de confianza segura.

Para ello, deberá realizar las siguientes acciones en la máquina VM4 (client):

  1. Eliminar el certificado de la CA raíz del almacén de certificados de confianza del sistema.

  2. Intentar acceder de nuevo al servidor web mediante HTTPS.

  3. Observar y documentar el comportamiento del cliente durante la conexión.

Deberá comprobar que al no existir un ancla de confianza, el cliente:

  • No puede validar la cadena de certificados presentada por el servidor.

  • Marca la conexión como no confiable o la rechaza.

  • Impide el establecimiento de una conexión TLS segura.

Este ejercicio demuestra que la confianza no depende del servidor, sino de los certificados de confianza instalados en el cliente, y refuerza el papel crítico de la CA raíz como punto inicial de confianza en una PKI.

6. Revocación de certificados

En una Infraestructura de Clave Pública (PKI) real, la seguridad no termina con la emisión de certificados. Es fundamental poder invalidar certificados antes de su fecha de caducidad cuando se produce un incidente de seguridad.

La revocación es un mecanismo distinto de la caducidad. Un certificado puede ser revocado aunque todavía sea válido temporalmente.

Las causas más habituales de revocación son:

  • Compromiso o sospecha de compromiso de una clave privada

  • Uso indebido del certificado

  • Cambio de rol o retirada de un servicio

  • Error en la emisión del certificado

Para ello, las PKI utilizan mecanismos de revocación, siendo el más básico y extendido la Lista de Revocación de Certificados (CRL, Certificate Revocation List).

En esta práctica, deberá simular el compromiso de la clave privada del servidor web y realizar las siguientes acciones:

  1. Revocar el certificado del servidor web desde la CA intermedia.

  2. Generar una CRL actualizada que incluya el certificado revocado.

  3. Distribuir la CRL al cliente.

  4. Verificar desde el cliente que:

    • El certificado del servidor ya no es válido

    • La conexión HTTPS falla o se marca como no confiable

En esta práctica se utiliza CRL por simplicidad y claridad didáctica, aunque en entornos reales de gran escala se emplean mecanismos como OCSP u OCSP Stapling.

Como ampliación opcional, se propone investigar el funcionamiento de OCSP como alternativa a las CRL.

6.1 Revocación del certificado del servidor

Suponga que el certificado del servidor web ha sido comprometido.

En la máquina VM2 (intermediate-ca), deberá revocar el certificado del servidor web previamente emitido.

6.2 Generación de la CRL

Una vez revocado el certificado, la CA intermedia generará una Lista de Revocación de Certificados (CRL) que contendrá:

  • El número de serie del certificado revocado

  • La fecha de revocación

  • La autoridad emisora de la CRL

6.3 Distribución de la CRL

En este paso deberá:

  • Transferir la CRL generada a la máquina cliente.

  • Asegurarse de que el cliente puede acceder a dicha lista para realizar la validación.

En entornos reales, la CRL se publica normalmente en un servidor HTTP o LDAP.

6.4 Verificación desde el cliente

En la máquina VM4 (client), tiene que comprobar que:

  • El certificado del servidor web ha sido revocado.

  • La validación de la cadena de confianza falla al incluir la comprobación de revocación.

  • El cliente ya no confía en el certificado del servidor.

Deberá aportar evidencias claras de este comportamiento.

7. Solución: emisión y revocación de certificados

A continuación, se describe una posible solución para la implementación de la PKI planteada en esta práctica.

La implementación descrita en esta sección tiene un objetivo exclusivamente didáctico.
En entornos reales de producción, una PKI suele incluir medidas adicionales como:

  • Uso de HSM para proteger claves privadas.

  • CA raíz completamente offline, con procedimientos de arranque controlado.

  • Auditoría y registro de accesos.

  • Publicación automatizada de CRL y/o uso de OCSP.

Estas medidas quedan fuera del alcance de esta práctica, pero son fundamentales en infraestructuras PKI reales.

Parte 1. CA raíz

Los siguientes comandos se ejecutan en la máquina VM1 (root-ca).

Preparar el entorno

sudo apt update               (1)
sudo apt install -y openssl   (2)
mkdir -p ~/pki/root-ca        (3)
cd ~/pki/root-ca              (4)
1 Actualiza la información de los paquetes disponibles en el sistema.
2 Instala OpenSSL, herramienta necesaria para gestionar claves y certificados digitales.
3 Crea el directorio base de la CA raíz donde se almacenará su estructura.
4 Accede al directorio de trabajo de la CA raíz.

Estructura de directorios y archivos necesarios

mkdir certs crl csr newcerts private   (1)
chmod 700 private                      (2)
touch index.txt                        (3)
echo 1000 > serial                     (4)
echo 1000 > crlnumber                  (5)
1 Crea la estructura básica de directorios necesaria para el funcionamiento de la autoridad certificadora.
2 Restringe el acceso al directorio de claves privadas para proteger la clave de la CA.
3 Crea el archivo de registro (index.txt) donde OpenSSL almacenará el estado de los certificados emitidos.
4 Inicializa el número de serie que se asignará al primer certificado emitido por la CA. En este caso, hemos puesto que empieza en 1000.
5 Inicializa el número de serie para la primera CRL que se generará. En este caso, hemos puesto que empieza en 1000.

Después de ejecutar los comandos, la estructura de directorios y archivos debería ser similar a la siguiente.

root-ca/
├── certs/
├── crl/
├── csr/
├── newcerts/
├── private/
├── index.txt
├── serial
└── crlnumber

Creación del archivo de configuración de OpenSSL openssl.cnf para la CA raíz

OpenSSL solo actúa como una Autoridad Certificadora real cuando se utiliza el comando openssl ca junto con un archivo de configuración openssl.cnf. Este archivo define la estructura de la CA, los archivos de control y las políticas de emisión. Sin él, OpenSSL únicamente firma certificados sin gestión ni trazabilidad.

Crea un archivo de configuración openssl.cnf para la CA raíz en la siguiente ruta:

nano ~/pki/root-ca/openssl.cnf

El archivo de configuración debe incluir al menos las siguientes secciones y parámetros:

[ ca ]                                              (1)
default_ca = CA_default                             (2)

[ CA_default ]                                      (3)
dir               = /home/ubuntu/pki/root-ca        (4)
certs             = $dir/certs                      (5)
crl_dir           = $dir/crl                        (6)
new_certs_dir     = $dir/newcerts                   (7)
database          = $dir/index.txt                  (8)
serial            = $dir/serial                     (9)
private_key       = $dir/private/ca.key.pem         (10)
certificate       = $dir/certs/ca.cert.pem          (11)
crlnumber         = $dir/crlnumber                  (12)
default_crl_days  = 30                              (13)

default_md        = sha256                          (14)
policy            = policy_strict                   (15)
email_in_dn       = no                              (16)
copy_extensions   = none                            (17)

[ policy_strict ]                                   (18)
countryName             = match                     (19)
stateOrProvinceName     = match                     (20)
organizationName        = match                     (21)
organizationalUnitName  = optional                  (22)
commonName              = supplied                  (23)

[ v3_root_ca ]                                      (24)
basicConstraints = critical, CA:true                (25)
keyUsage = critical, keyCertSign, cRLSign           (26)
subjectKeyIdentifier = hash                         (27)
1 Sección principal que indica a OpenSSL qué CA usar por defecto.
2 Define CA_default como la configuración activa de la CA.
3 Sección principal de configuración de la Autoridad Certificadora.
4 Directorio base de la CA raíz.
5 Ubicación de los certificados emitidos.
6 Directorio donde se almacenan las listas de revocación (CRL).
7 Directorio para certificados recién emitidos.
8 Base de datos que registra certificados emitidos y revocados.
9 Archivo que controla el número de serie de los certificados.
10 Clave privada de la CA raíz.
11 Certificado público de la CA raíz.
12 Archivo que gestiona el número de serie de las CRL.
13 Periodo de validez por defecto de las CRL (en días).
14 Algoritmo hash por defecto usado en firmas.
15 Política que regula los campos obligatorios del DN.
16 Evita incluir direcciones de correo en el DN.
17 Impide copiar extensiones directamente desde la CSR.
18 Política estricta para validar solicitudes de certificados.
19 El país debe coincidir con el de la CA.
20 La provincia debe coincidir con la de la CA.
21 La organización debe coincidir con la de la CA.
22 La unidad organizativa es opcional.
23 El nombre común debe ser proporcionado por el solicitante.
24 Extensiones X.509 específicas para un certificado de CA raíz.
25 Indica que el certificado es de una CA y marca la extensión como crítica.
26 Permite firmar certificados y listas de revocación.
27 Genera un identificador único basado en la clave pública.

El nombre de la sección v3_root_ca lo hemos decidido nosotros de forma arbitraria. Puede llamarse de cualquier otra forma, siempre que se haga referencia a ella al crear el certificado raíz con el parámetro -extensions v3_root_ca.

Clave privada de la CA raíz

Vamos a generar una clave privada para la CA raíz de 4096 bits protegida con una passphrase.

Utilizaremos el algoritmo RSA con cifrado simétrico AES-256 para proteger la clave privada con una contraseña.

openssl genrsa -aes256 -out private/ca.key.pem 4096

Después de crear la clave, ajustamos los permisos:

chmod 400 private/ca.key.pem

Certificado raíz autofirmado

openssl req -x509 -new -sha256 -days 3650 \   (1)
  -key private/ca.key.pem \                   (2)
  -out certs/ca.cert.pem \                    (3)
  -subj "/C=ES/ST=Almería/L=Almería/O=CeliaCorp/OU=IT/CN=CeliaCorp Root CA"   (4)
1 Genera un certificado autofirmado X.509 para la CA raíz con algoritmo hash SHA-256 y larga validez (3650 días).
2 Utiliza la clave privada de la CA raíz para firmar el certificado.
3 Guarda el certificado raíz resultante en el directorio de certificados de la CA.
4 Define los datos de identidad (DN, distinguished name) de la CA raíz.

Los campos del DN (distinguished name) son:

Campo Nombre completo Descripción breve

C

Country

País donde está registrada la entidad

ST

State or Province

Provincia o estado administrativo

L

Locality

Ciudad o localidad

O

Organization

Organización propietaria del certificado

OU

Organizational Unit

Unidad organizativa dentro de la organización

CN

Common Name

Identificador principal del sujeto del certificado

Ajustamos los permisos del certificado:

chmod 444 certs/ca.cert.pem

Después de completar estos pasos, hemos creado la CA raíz con una estructura adecuada, una clave privada segura y un certificado autofirmado.

Parte 2. CA intermedia

Los siguientes comandos se ejecutan en la máquina VM2 (intermediate-ca).

Preparar entorno

sudo apt update                      (1)
sudo apt install -y openssl          (2)
mkdir -p ~/pki/intermediate-ca       (3)
cd ~/pki/intermediate-ca             (4)
1 Actualiza la información de los paquetes disponibles en el sistema.
2 Instala OpenSSL para la gestión de claves y certificados en la CA intermedia.
3 Crea el directorio base de trabajo de la CA intermedia.
4 Accede al directorio de trabajo de la CA intermedia.

Estructura de la CA intermedia

mkdir certs crl csr newcerts private   (1)
chmod 700 private                      (2)
touch index.txt                        (3)
echo 2000 > serial                     (4)
echo 2000 > crlnumber                  (5)
1 Crea la estructura de directorios necesaria para el funcionamiento de la CA intermedia.
2 Restringe el acceso al directorio de claves privadas para proteger la clave de la CA.
3 Crea el archivo de registro donde OpenSSL almacenará el estado de los certificados emitidos.
4 Inicializa el número de serie que se asignará al primer certificado emitido por la CA intermedia. En este caso, hemos puesto que empieza en 2000.
5 Inicializa el número de serie para la primera CRL que se generará. En este caso, hemos puesto que empieza en 2000.

Creación del archivo de configuración de OpenSSL openssl.cnf para la CA intermedia

Crea un archivo de configuración openssl.cnf para la CA intermedia en la siguiente ruta:

nano ~/pki/intermediate-ca/openssl.cnf

El archivo de configuración debe incluir al menos las siguientes secciones y parámetros:

[ ca ]
default_ca = CA_default

[ CA_default ]
dir               = /home/ubuntu/pki/intermediate-ca
certs             = $dir/certs
crl_dir           = $dir/crl
new_certs_dir     = $dir/newcerts
database          = $dir/index.txt
serial            = $dir/serial
private_key       = $dir/private/intermediate.key.pem
certificate       = $dir/certs/intermediate.cert.pem
crlnumber         = $dir/crlnumber
default_crl_days  = 30

default_md        = sha256
policy            = policy_loose
email_in_dn       = no
copy_extensions   = copy

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

[ server_cert ]                                        (1)
basicConstraints = CA:false                            (2)
keyUsage = critical, digitalSignature, keyEncipherment (3)
extendedKeyUsage = serverAuth                          (4)
subjectKeyIdentifier = hash                            (5)
authorityKeyIdentifier = keyid,issuer                  (6)
1 Define el perfil de extensiones X.509 para certificados de servidor.
2 Indica que el certificado no puede actuar como Autoridad Certificadora.
3 Limita el uso de la clave a firma digital y cifrado de claves, marcándolo como crítico.
4 Autoriza el uso del certificado para autenticación de servidores TLS.
5 Genera un identificador único del certificado basado en la clave pública.
6 Vincula el certificado con la clave y el emisor de la CA que lo ha firmado.

Observe que la última sección, server_cert, es diferente a la de la CA raíz. Esta sección define las extensiones X.509 adecuadas para los certificados de servidor web que emitirá la CA intermedia.

El nombre de la sección server_cert lo hemos decidido nosotros de forma arbitraria. Puede llamarse de cualquier otra forma, siempre que se haga referencia a ella al crear el certificado del servidor web con el parámetro -extensions server_cert.

Clave privada de la CA intermedia

Generamos la clave privada de la CA intermedia utilizando RSA de 4096 bits y la protegemos con cifrado AES-256 mediante una contraseña.

openssl genrsa -aes256 -out private/intermediate.key.pem 4096

Ajustamos los permisos de la clave privada:

chmod 400 private/intermediate.key.pem

CSR de la CA intermedia

openssl req -new -sha256 \                                  (1)
  -key private/intermediate.key.pem \                       (2)
  -out csr/intermediate.csr.pem \                           (3)
  -subj "/C=ES/ST=Almería/L=Almería/O=CeliaCorp/OU=IT/CN=CeliaCorp Intermediate CA"   (4)
1 Genera una solicitud de firma de certificado (CSR) utilizando el algoritmo hash SHA-256.
2 Utiliza la clave privada de la CA intermedia para firmar la solicitud.
3 Guarda la CSR generada en el directorio destinado a solicitudes de certificados.
4 Define los datos de identidad de la CA intermedia que se incluirán en el certificado.

Firmar la CA intermedia en la CA raíz

1) Copiar la CSR a la CA raíz

Copiamos la CSR generada en la CA intermedia (VM2) a la máquina de la CA raíz (VM1).

scp csr/intermediate.csr.pem IP_ROOT_CA:~/pki/root-ca/csr

Tenga en cuenta que tendrá que reemplazar IP_ROOT_CA por la dirección IP o el hostname de la máquina CA raíz (VM1).

2) Firmar la CSR en la CA raíz (VM1)

openssl ca -config openssl.cnf \        (1)
  -extensions v3_root_ca \              (2)
  -days 1825 \                          (3)
  -notext -md sha256 \                  (4)
  -in csr/intermediate.csr.pem \        (5)
  -out certs/intermediate.cert.pem      (6)
1 Ejecuta OpenSSL en modo Autoridad Certificadora utilizando el archivo de configuración indicado.
2 Aplica las extensiones específicas definidas en la sección v3_root_ca del archivo openssl.cnf.
3 Define un periodo de validez de 1825 días (5 años).
4 Omite la salida de texto adicional y utiliza SHA-256 como algoritmo de firma.
5 Indica la CSR de la CA intermedia que va a ser firmada.
6 Genera el certificado firmado y lo almacena en el directorio de certificados de la CA raíz.

Al firmar la CSR, OpenSSL actualizará automáticamente el archivo index.txt y el archivo serial. De esta forma, el certificado que se ha emitido queda registrado, se le asigna un número de serie único y podrá ser gestionado posteriormente (revocado, renovado, etc.).

3) Copiar el certificado firmado en la CA raíz a la CA intermedia

Desde la máquina de la CA intermedia (VM2), copiamos el certificado que se ha firmado en la CA raíz (VM1).

scp IP_ROOT_CA:~/pki/root-ca/certs/intermediate.cert.pem certs/

Tenga en cuenta que tendrá que reemplazar IP_ROOT_CA por la dirección IP o el hostname de la máquina CA raíz (VM1).

Ajustamos los permisos del certificado:

chmod 444 certs/intermediate.cert.pem

Parte 3. Servidor Web

Los siguientes comandos se ejecutan en la máquina VM3.

Preparar el servidor web

sudo apt update                       (1)
sudo apt install -y nginx openssl     (2)
1 Actualiza la información de los paquetes disponibles en el sistema.
2 Instala Nginx como servidor web y OpenSSL para la gestión de certificados TLS.

Clave privada del servidor

mkdir -p ~/pki/web                     (1)
cd ~/pki/web                           (2)
openssl genrsa -out web.key.pem 4096   (3)
chmod 400 web.key.pem                  (4)
1 Crea el directorio de trabajo donde se almacenarán la clave y los certificados del servidor web.
2 Accede al directorio de trabajo del servidor web.
3 Genera la clave privada del servidor web utilizando RSA de 4096 bits.
4 Restringe los permisos de la clave privada para evitar accesos no autorizados.

CSR del servidor web

openssl req -new -key web.key.pem \                                     (1)
  -out web.csr.pem \                                                    (2)
  -subj "/C=ES/ST=Almería/L=Almería/O=CeliaCorp/OU=Web/CN=web-server" \ (3)
  -addext "subjectAltName=DNS:web-server"                               (4)
1 Genera una solicitud de firma de certificado (CSR) utilizando la clave privada del servidor web.
2 Guarda la CSR del servidor web para su posterior firma por la CA intermedia.
3 Define los datos de identidad del servidor web que se incluirán en el certificado.
4 Añade una extensión subjectAltName para incluir el nombre alternativo del sujeto (SAN), necesario para certificados TLS modernos.

Los navegadores modernos requieren que el nombre del servidor esté presente en la extensión Subject Alternative Name (SAN). El uso exclusivo del Common Name (CN) ya no es suficiente para certificados TLS web.

Firmar el certificado del servidor web en la CA intermedia

1) Copiar la CSR a la CA intermedia

Desde el servidor web (VM3), copiamos la CSR generada a la máquina de la CA intermedia (VM2).

scp web.csr.pem IP_INTERMEDIATE_CA:~/pki/intermediate-ca/csr/

Tenga en cuenta que tendrá que reemplazar IP_INTERMEDIATE_CA por la dirección IP o el hostname de la máquina CA intermedia (VM2).

2) Firmar la CSR en la CA intermedia (VM2)

openssl ca -config openssl.cnf \             (1)
  -extensions server_cert \                  (2)
  -days 365 \                                (3)
  -notext -md sha256 \                       (4)
  -in csr/web.csr.pem \                      (5)
  -out certs/web.cert.pem                    (6)
1 Utiliza el motor de Autoridad Certificadora definido en el archivo openssl.cnf.
2 Aplica las extensiones específicas definidas en la sección server_cert del archivo openssl.cnf.
3 Define un periodo de validez de 365 días (1 año).
4 Firma el certificado usando SHA-256 y evita mostrar el contenido completo por pantalla.
5 Especifica la CSR del servidor web que va a ser firmada.
6 Genera el certificado final del servidor y lo almacena en el directorio de certificados.

Al firmar la CSR, OpenSSL actualizará automáticamente el archivo index.txt y el archivo serial. De esta forma, el certificado que se ha emitido queda registrado, se le asigna un número de serie único y podrá ser gestionado posteriormente (revocado, renovado, etc.).

3) Copiar el certificado firmado en el servidor web

Desde el servidor web (VM3), copiamos el certificado que se ha firmado en la CA intermedia (VM2).

scp IP_INTERMEDIATE_CA:~/pki/intermediate-ca/certs/web.cert.pem ~/pki/web

Tenga en cuenta que tendrá que reemplazar IP_INTERMEDIATE_CA por la dirección IP o el hostname de la máquina CA intermedia (VM2).

Crear la cadena de certificados

Durante el handshake TLS entre cliente y servidor, el servidor web debe presentar su certificado junto con el certificado de la CA intermedia, formando la cadena de certificados necesaria para que el cliente pueda validar la confianza hasta la CA raíz.

En este paso vamos a crear dicha cadena de certificados. En primer lugar, vamos a copiar el certificado de la CA intermedia al servidor web.

scp IP_INTERMEDIATE_CA:~/pki/intermediate-ca/certs/intermediate.cert.pem ~/pki/web

Tenga en cuenta que tendrá que reemplazar IP_INTERMEDIATE_CA por la dirección IP o el hostname de la máquina CA intermedia (VM2).

Ahora, creamos la cadena de certificados uniendo el certificado del servidor web y el de la CA intermedia para que el cliente pueda validar la confianza hasta la CA raíz.

cat web.cert.pem intermediate.cert.pem > web.fullchain.pem

Configuración del servidor web Nginx

sudo cp web.key.pem /etc/ssl/private/        (1)
sudo cp web.fullchain.pem /etc/ssl/certs/    (2)
1 Copia la clave privada del servidor web al directorio del sistema destinado a claves TLS.
2 Copia la cadena de certificados al directorio del sistema destinado a certificados TLS.

Editamos el archivo de configuración del sitio web por defecto de Nginx:

sudo nano /etc/nginx/sites-available/default

El archivo debe quedar así:

server {
    listen 80;                                            (1)
    server_name _;                                        (2)
    return 301 https://$host$request_uri;                 (3)
}

server {
    listen 443 ssl;                                       (4)

    ssl_certificate /etc/ssl/certs/web.fullchain.pem;     (5)
    ssl_certificate_key /etc/ssl/private/web.key.pem;     (6)

    root /var/www/html;                                   (7)
    index index.html index.htm;                           (8)
}
1 Configura Nginx para escuchar conexiones HTTP en el puerto 80.
2 Define el nombre del servidor; _ actúa como comodín por defecto.
3 Redirige permanentemente (301) todas las peticiones HTTP a HTTPS manteniendo la URL original.
4 Configura Nginx para aceptar conexiones HTTPS en el puerto 443.
5 Especifica la cadena de certificados que el servidor presenta al cliente durante el handshake TLS.
6 Indica la clave privada asociada al certificado del servidor.
7 Define el directorio raíz desde el que se servirán los contenidos web.
8 Establece la prioridad de los archivos index por defecto.

Comprobamos que la configuración de Nginx es correcta con el siguiente comando:

sudo nginx -t

Si la configuración es correcta, reiniciamos el servicio de Nginx para aplicar los cambios:

sudo systemctl restart nginx

Creamos una página web de prueba

Creamos un archivo index.html sencillo para verificar que el servidor web funciona correctamente.

echo "<h1>Servidor Web Seguro con PKI</h1>" | sudo tee /var/www/html/index.html

Parte 4. Cliente

Copiar el certificado de la CA raíz

Copiamos el certificado de la CA raíz desde la máquina de la CA raíz (VM1) a la máquina cliente (VM4).

scp IP_ROOT_CA:~/pki/root-ca/certs/ca.cert.pem ~/

Tenga en cuenta que tendrá que reemplazar IP_ROOT_CA por la dirección IP o el hostname de la máquina CA raíz (VM1).

Instalar el certificado de la CA raíz

sudo cp ca.cert.pem /usr/local/share/ca-certificates/celiacorp-root.crt   (1)
sudo update-ca-certificates                                               (2)
1 Copia el certificado de la CA raíz al almacén de certificados de confianza del sistema.
2 Actualiza el almacén de certificados para que el sistema confíe en la CA raíz.

Validar la conexión TLS al servidor web

curl https://web-server                         (1)
1 Realiza una petición HTTPS al servidor web para comprobar que la conexión TLS es válida y confiable.

También podemos utilizar la opción -v (verbose) para obtener más detalles sobre la conexión TLS.

curl -v https://web-server

Si todo está bien configurado, el comando curl -v nos debería dar una respuesta similar a esta:

* Host web-server:443 was resolved.                                           (1)
* IPv6: (none)                                                                (2)
* IPv4: 172.16.10.107                                                         (3)
*   Trying 172.16.10.107:443...                                               (4)
* Connected to web-server (172.16.10.107) port 443                            (5)
* ALPN: curl offers h2,http/1.1                                               (6)
* TLSv1.3 (OUT), TLS handshake, Client hello (1):                             (7)
*  CAfile: /etc/ssl/certs/ca-certificates.crt                                 (8)
*  CApath: /etc/ssl/certs                                                     (9)
* TLSv1.3 (IN), TLS handshake, Server hello (2):                              (10)
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):                      (11)
* TLSv1.3 (IN), TLS handshake, Certificate (11):                              (12)
* TLSv1.3 (IN), TLS handshake, CERT verify (15):                              (13)
* TLSv1.3 (IN), TLS handshake, Finished (20):                                 (14)
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):                   (15)
* TLSv1.3 (OUT), TLS handshake, Finished (20):                                (16)
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS (17)
* ALPN: server accepted http/1.1                                              (18)
* Server certificate:                                                         (19)
*  subject: C=ES; ST=Almería; O=CeliaCorp; OU=Web; CN=web-server              (20)
*  start date: Jan 18 22:08:30 2026 GMT                                       (21)
*  expire date: Jan 18 22:08:30 2027 GMT                                      (22)
*  subjectAltName: host "web-server" matched cert's "web-server"              (23)
*  issuer: C=ES; ST=Almería; O=CeliaCorp; OU=IT; CN=CeliaCorp Intermediate CA (24)
*  SSL certificate verify ok.                                                 (25)
*   Certificate level 0: RSA, certificado del servidor                        (26)
*   Certificate level 1: RSA, CA intermedia                                   (27)
*   Certificate level 2: RSA, CA raíz                                         (28)
* using HTTP/1.x                                                              (29)
> GET / HTTP/1.1                                                              (30)
> Host: web-server                                                            (31)
> User-Agent: curl/8.5.0                                                      (32)
> Accept: */*                                                                 (33)
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):                         (34)
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):                         (35)
* old SSL session ID is stale, removing                                       (36)
< HTTP/1.1 200 OK                                                             (37)
< Server: nginx/1.24.0 (Ubuntu)                                               (38)
< Date: Mon, 19 Jan 2026 08:30:22 GMT                                         (39)
< Content-Type: text/html                                                     (40)
< Content-Length: 37                                                          (41)
<h1>Servidor Web Seguro con PKI</h1>                                          (42)
* Connection #0 to host web-server left intact                                (43)
1 Resolución del nombre del servidor y puerto HTTPS.
2 No hay conectividad IPv6 disponible.
3 Dirección IPv4 resuelta para el servidor.
4 Inicio de la conexión TCP al puerto 443.
5 Conexión TCP establecida correctamente.
6 Protocolos de aplicación ofrecidos mediante ALPN (Application-Layer Protocol Negotiation).
7 Envío del ClientHello e inicio del handshake TLS.
8 Archivo de certificados raíz de confianza del sistema.
9 Directorio donde se almacenan las CAs confiables.
10 Respuesta del servidor aceptando la negociación TLS.
11 Envío de extensiones TLS cifradas.
12 Envío de la cadena de certificados del servidor.
13 Verificación criptográfica del certificado del servidor.
14 Finalización del handshake por parte del servidor.
15 Cambio a comunicación cifrada.
16 Confirmación final del handshake por el cliente.
17 Parámetros criptográficos negociados para la sesión TLS.
18 Protocolo HTTP seleccionado por el servidor.
19 Inicio de la información del certificado del servidor.
20 Identidad (DN) del certificado del servidor.
21 Fecha de inicio de validez del certificado.
22 Fecha de expiración del certificado.
23 Coincidencia del nombre del servidor con el SAN (Subject Alternative Name).
24 Autoridad certificadora que emitió el certificado.
25 La cadena de confianza ha sido validada correctamente.
26 Certificado del servidor web.
27 Certificado de la CA intermedia.
28 Certificado de la CA raíz (ancla de confianza).
29 Uso del protocolo HTTP/1.x sobre TLS.
30 Petición HTTP GET al recurso raíz.
31 Cabecera Host enviada por el cliente.
32 Identificación del cliente curl.
33 Tipos de contenido aceptados.
34 Ticket TLS para reanudación de sesión.
35 Segundo ticket TLS enviado por el servidor.
36 Eliminación de una sesión TLS antigua.
37 Respuesta HTTP correcta del servidor.
38 Software del servidor web.
39 Fecha y hora de la respuesta.
40 Tipo de contenido devuelto.
41 Tamaño del contenido.
42 Contenido HTML servido por el servidor.
43 La conexión se mantiene abierta (keep-alive).

Comprobar la cadena de certificados

Para analizar el certificado presentado por el servidor y verificar que la cadena de confianza es correcta, se puede utilizar la herramienta openssl s_client.

openssl s_client -connect web-server:443        (1)
1 Establece una conexión TLS y muestra los detalles del certificado y de la cadena de confianza presentada por el servidor.

Opcionalmente, puede añadirse la opción -showcerts para visualizar todos los certificados enviados por el servidor durante el handshake TLS:

openssl s_client -connect web-server:443 -showcerts

Este comando es útil para diagnosticar problemas de confianza, como certificados intermedios ausentes, errores de validación o configuraciones incorrectas del servidor HTTPS.

Parte 5. Revocación de certificados

En esta sección se realizan las acciones necesarias para revocar el certificado del servidor web.

Revocar el certificado del servidor

Desde la máquina de la CA intermedia (VM2), ejecutamos el siguiente comando para revocar el certificado del servidor web:

openssl ca -config openssl.cnf \              (1)
  -revoke certs/web.cert.pem \                (2)
  -keyfile private/intermediate.key.pem \     (3)
  -cert certs/intermediate.cert.pem           (4)
1 Ejecuta OpenSSL en modo Autoridad Certificadora definido en el archivo openssl.cnf.
2 Revoca el certificado del servidor web emitido previamente por la CA intermedia.
3 Utiliza la clave privada de la CA intermedia para autorizar la revocación.
4 Indica el certificado de la CA intermedia que actúa como autoridad emisora.

Generar CRL

openssl ca -config openssl.cnf \              (1)
  -gencrl \                                   (2)
  -keyfile private/intermediate.key.pem \     (3)
  -cert certs/intermediate.cert.pem \         (4)
  -out crl/intermediate.crl.pem               (5)
1 Ejecuta OpenSSL en modo Autoridad Certificadora definido en el archivo openssl.cnf.
2 Genera una lista de revocación de certificados (CRL) a partir del registro de la CA.
3 Utiliza la clave privada de la CA intermedia para firmar la CRL.
4 Especifica el certificado de la CA intermedia que actúa como emisora de la CRL.
5 Guarda la CRL generada en el directorio destinado a listas de revocación.

Enviar la CRL al cliente

Copiamos la lista de revocación (CRL) de la CA intermedia a la máquina cliente para su validación local.

scp IP_CA_INTERMEDIA:crl/intermediate.crl.pem .

Comprobar la revocación en el cliente

Es importante destacar que la revocación de certificados no se comprueba automáticamente en todas las conexiones TLS.
Herramientas como curl u openssl s_client, así como muchos navegadores, no verifican listas CRL locales por defecto, salvo que se indique explícitamente.

En esta práctica, la comprobación de revocación se realiza de forma manual y controlada mediante openssl verify -crl_check, con fines didácticos, para evidenciar el impacto de un certificado revocado dentro de la PKI.

openssl verify -crl_check \          (1)
  -CAfile ca.cert.pem \              (2)
  -CRLfile intermediate.crl.pem \    (3)
  web.cert.pem                       (4)
1 Fuerza la comprobación del estado de revocación del certificado durante la verificación.
2 Indica el certificado de la CA raíz utilizado como ancla de confianza.
3 Especifica la lista de revocación (CRL) emitida por la CA intermedia.
4 Certificado del servidor web que se desea validar.

Parte 6. Pérdida del ancla de confianza

sudo rm /usr/local/share/ca-certificates/celiacorp-root.crt   (1)
sudo update-ca-certificates                                   (2)
1 Elimina el certificado de la CA raíz del almacén de certificados de confianza del sistema.
2 Actualiza el almacén de certificados para que el sistema deje de confiar en la PKI interna.

Intentamos acceder al servidor HTTPS sin disponer de un ancla de confianza, provocando el fallo de validación TLS.

curl https://web-server

8. Ampliación de la práctica

En esta sección se describen los pasos necesarios para ampliar la PKI creada en esta práctica y habilitar la autenticación mutua TLS (mTLS) entre el cliente y el servidor web.

En esta ampliación se implementa autenticación mutua TLS, de forma que:

  • El servidor web se autentica frente al cliente mediante su certificado TLS, como en HTTPS tradicional.

  • El cliente TLS presenta un certificado personal, que representa la identidad de un usuario o servicio, autenticándose frente al servidor.

De este modo, ambas partes verifican criptográficamente su identidad antes de establecer la conexión segura.

Los pasos que se seguirán son los siguientes:

  1. La CA intermedia emite un certificado de usuario, destinado exclusivamente a autenticación de cliente.

  2. Dicho certificado se empaqueta en formato PKCS#12, incluyendo:

    • Certificado del usuario

    • Clave privada asociada

    • (Opcionalmente) certificados intermedios

  1. El usuario instala el certificado en su navegador o lo utiliza explícitamente con herramientas como curl.

  2. Se configura el servidor web para exigir autenticación de cliente mediante certificados (mTLS).

  3. El usuario inicia una conexión HTTPS con el servidor web utilizando su certificado personal. En este paso, la conexión solo se establece si el certificado del cliente es válido, confiable y no está revocado.

8.1 Autenticación mutua TLS (mTLS)

La autenticación mutua TLS (mTLS) extiende el modelo tradicional de HTTPS, exigiendo que tanto el servidor como el cliente se autentiquen mediante certificados digitales durante el establecimiento de la conexión TLS.

El siguiente diagrama ilustra el funcionamiento general de TLS.

Funcionamiento de TLS. Imagen obtenida de https://www.cloudflare.com/es-es/learning/access-management/what-is-mutual-tls/[Cloudflare].
Figura 7. Funcionamiento de TLS. Imagen obtenida de Cloudflare.

En TLS estándar:

  • El servidor presenta su certificado.

  • El cliente verifica la identidad del servidor.

  • El servidor no autentica al cliente a nivel criptográfico.

A continuación, se muestra un diagrama que ilustra el funcionamiento general de la autenticación mutua TLS (mTLS).

Funcionamiento de mTLS. Imagen obtenida de https://www.cloudflare.com/es-es/learning/access-management/what-is-mutual-tls/[Cloudflare].
Figura 8. Funcionamiento de mTLS. Imagen obtenida de Cloudflare.

En mTLS:

  • El servidor presenta su certificado.

  • El cliente presenta su propio certificado personal.

  • Ambas partes validan:

    • La cadena de confianza

    • La validez temporal

    • El uso permitido del certificado

    • El estado de revocación

Este mecanismo elimina el uso de contraseñas y se basa en identidad criptográfica fuerte, gestionada por una PKI.

mTLS se utiliza habitualmente en:

  • Infraestructuras corporativas internas

  • APIs privadas

  • Arquitecturas de microservicios

  • Entornos de alta seguridad

  • Dispositivos IoT y sistemas industriales

8.2 Componentes y roles

La siguiente tabla resume los componentes implicados en la ampliación de la PKI para habilitar mTLS.

Componente Rol

CA raíz

Ancla de confianza de toda la PKI

CA intermedia

Emite certificados de servidor y de usuario

Servidor web

Exige autenticación de cliente mediante certificados (mTLS)

Usuario

Se autentica mediante un certificado personal y su clave privada

10. Cuestiones teóricas

  1. ¿Por qué la CA raíz debe mantenerse aislada?

  2. ¿Qué impacto tendría la pérdida de la clave privada de la CA raíz?

  3. ¿Qué impacto tendría la exposición de la CA intermedia?

  4. ¿Por qué el servidor web no debe firmar sus propios certificados?

  5. ¿Qué ventajas ofrece una PKI interna frente a una pública?

  6. ¿Por qué la revocación es un elemento crítico en una PKI?

  7. ¿Qué riesgos existirían si no se comprobara la revocación de certificados?

  8. ¿Qué diferencias existen entre una CRL y OCSP?

  9. ¿Qué impacto tiene el tiempo de actualización de una CRL en la seguridad?

11. Entregables

Deberá entregar un documento breve que incluya:

  • Comandos utilizados en cada paso.

  • Configuraciones relevantes.

  • Evidencias (capturas de pantalla y logs) que demuesteren la correcta implementación y funcionamiento de la PKI.

  • Respuestas a las cuestiones teóricas planteadas.

12. Referencias