: Ciberseguridad; 20 Julio 2026

Guía definitiva para implementar una PKI en Linux: certificados digitales, TLS y autenticación segura

Autor: Carlos Monje | Publicado: 20/07/2026

pki linux

Implementar una PKI en Linux permite crear una infraestructura propia de confianza para emitir, administrar, renovar y revocar certificados digitales. Es una base esencial para proteger servicios internos, habilitar TLS, autenticar servidores, validar usuarios, cifrar comunicaciones y aplicar autenticación mutua entre aplicaciones.

Una PKI bien diseñada no consiste solo en generar certificados con OpenSSL. También requiere gobierno, separación de funciones, protección de claves privadas, políticas de emisión, inventario, renovación, revocación, respaldo y monitoreo.

Idea central: la PKI convierte la confianza en infraestructura. Si la CA raíz se protege bien, los certificados emitidos pueden servir para TLS, mTLS, VPN, servicios internos, APIs, correo, dispositivos, Kubernetes y autenticación empresarial.

¿Qué es una PKI?

PKI significa Public Key Infrastructure o infraestructura de clave pública. Es el conjunto de componentes que permite crear, firmar, distribuir, validar y revocar certificados digitales.

En una PKI participan varios elementos: una autoridad certificadora raíz, una o más autoridades intermedias, certificados finales, claves privadas, solicitudes CSR, políticas de certificación, listas de revocación y repositorios de confianza.

Componente	Función
CA raíz	Máxima autoridad de confianza. Debe mantenerse offline y usarse solo para firmar CAs intermedias.
CA intermedia	Emite certificados finales para servidores, usuarios, aplicaciones o dispositivos.
Certificado final	Identifica un servidor, cliente, servicio o usuario.
Clave privada	Elemento secreto que debe protegerse. Si se filtra, la identidad queda comprometida.
CSR	Solicitud de firma de certificado generada por quien necesita un certificado.
CRL / OCSP	Mecanismos para verificar si un certificado fue revocado antes de vencer.

Cuándo conviene crear una PKI interna

Una PKI privada es útil cuando una organización necesita certificados para servicios internos que no deben depender de una CA pública. Por ejemplo: paneles internos, APIs, servidores de bases de datos, Kubernetes, LDAP, VPN, mTLS entre microservicios o autenticación de dispositivos.

Proteger sitios internos con HTTPS.
Aplicar mTLS entre aplicaciones y APIs.
Emitir certificados para VPN, Wi-Fi empresarial o dispositivos.
Autenticar servicios en Kubernetes, contenedores o microservicios.
Evitar certificados autofirmados dispersos y sin control.
Centralizar emisión, renovación, revocación e inventario.
Crear confianza interna sin exponer nombres privados a CAs públicas.

Importante: para sitios públicos en Internet, normalmente conviene usar una CA pública como Let’s Encrypt u otro proveedor confiable. Para servicios internos, una PKI privada bien administrada puede ser más segura y controlable.

Arquitectura recomendada: raíz offline e intermedia online

La arquitectura más recomendable para una PKI empresarial básica es de dos niveles:

Nivel	Recomendación	Uso
CA raíz	Offline, protegida, con clave cifrada y uso muy limitado.	Firmar únicamente CAs intermedias y listas de revocación raíz.
CA intermedia	Online o semionline, con controles de acceso, auditoría y respaldo.	Emitir certificados finales para servidores, usuarios, clientes y servicios.

Esta separación permite proteger la raíz. Si una CA intermedia se compromete, se puede revocar y reemplazar sin perder toda la confianza de la organización.

Paso 1: instalar OpenSSL y preparar el entorno

En Ubuntu, Debian o Linux Mint:

Instalar OpenSSL en Debian, Ubuntu o Linux Mint

sudo apt update
sudo apt install -y openssl ca-certificates

En Fedora, Rocky Linux, AlmaLinux o RHEL:

Instalar OpenSSL en Fedora, Rocky, AlmaLinux o RHEL

sudo dnf install -y openssl ca-certificates

Crea una estructura segura para la CA raíz:

Estructura de la CA raíz

mkdir -p ~/pki/root-ca/{certs,crl,newcerts,private,csr}
chmod 700 ~/pki/root-ca/private
touch ~/pki/root-ca/index.txt
echo 1000 > ~/pki/root-ca/serial
echo 1000 > ~/pki/root-ca/crlnumber

Paso 2: crear la clave privada de la CA raíz

La clave privada de la CA raíz es el activo más importante de la PKI. Debe estar cifrada, protegida y preferentemente fuera de línea.

Crear clave privada de CA raíz

openssl genrsa -aes256 -out ~/pki/root-ca/private/root-ca.key.pem 4096
chmod 400 ~/pki/root-ca/private/root-ca.key.pem

No pierdas esta clave ni su contraseña. Si se pierde, no podrás firmar nuevas CAs intermedias. Si se filtra, toda la confianza de la PKI queda comprometida.

Paso 3: crear el certificado autofirmado de la CA raíz

Genera el certificado raíz. Este certificado será el ancla de confianza que luego instalarás en servidores, estaciones o navegadores internos.

Crear certificado raíz

openssl req -x509 -new -nodes -sha256 -days 3650 \
-key ~/pki/root-ca/private/root-ca.key.pem \
-out ~/pki/root-ca/certs/root-ca.cert.pem \
-subj "/C=PE/ST=Lima/L=Lima/O=Empresa Demo/OU=PKI/CN=Empresa Demo Root CA"

chmod 444 ~/pki/root-ca/certs/root-ca.cert.pem

Verifica el certificado:

Verificar certificado raíz

openssl x509 -noout -text -in ~/pki/root-ca/certs/root-ca.cert.pem

Paso 4: crear una CA intermedia

La CA intermedia será la encargada de emitir certificados finales. Crea su estructura:

Estructura de CA intermedia

mkdir -p ~/pki/intermediate-ca/{certs,crl,csr,newcerts,private}
chmod 700 ~/pki/intermediate-ca/private
touch ~/pki/intermediate-ca/index.txt
echo 2000 > ~/pki/intermediate-ca/serial
echo 2000 > ~/pki/intermediate-ca/crlnumber

Genera la clave privada de la intermedia:

Clave privada de CA intermedia

openssl genrsa -aes256 -out ~/pki/intermediate-ca/private/intermediate-ca.key.pem 4096
chmod 400 ~/pki/intermediate-ca/private/intermediate-ca.key.pem

Crea la solicitud CSR de la intermedia:

CSR de CA intermedia

openssl req -new -sha256 \
-key ~/pki/intermediate-ca/private/intermediate-ca.key.pem \
-out ~/pki/intermediate-ca/csr/intermediate-ca.csr.pem \
-subj "/C=PE/ST=Lima/L=Lima/O=Empresa Demo/OU=PKI/CN=Empresa Demo Intermediate CA"

Paso 5: firmar la CA intermedia con la CA raíz

Crea un archivo de extensiones para que el certificado intermedio sea reconocido como autoridad certificadora:

Extensiones para CA intermedia

cat > ~/pki/intermediate-ca/intermediate.ext <<'EOF'
basicConstraints = critical, CA:true, pathlen:0
keyUsage = critical, digitalSignature, cRLSign, keyCertSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
EOF

Firma la CSR de la intermedia usando la CA raíz:

Firmar CA intermedia

openssl x509 -req -sha256 -days 1825 \
-in ~/pki/intermediate-ca/csr/intermediate-ca.csr.pem \
-CA ~/pki/root-ca/certs/root-ca.cert.pem \
-CAkey ~/pki/root-ca/private/root-ca.key.pem \
-CAcreateserial \
-out ~/pki/intermediate-ca/certs/intermediate-ca.cert.pem \
-extfile ~/pki/intermediate-ca/intermediate.ext

chmod 444 ~/pki/intermediate-ca/certs/intermediate-ca.cert.pem

Verifica la cadena:

Verificar certificado intermedio

openssl verify -CAfile ~/pki/root-ca/certs/root-ca.cert.pem \
~/pki/intermediate-ca/certs/intermediate-ca.cert.pem

Crea el archivo de cadena:

Crear cadena de certificados

cat ~/pki/intermediate-ca/certs/intermediate-ca.cert.pem \
~/pki/root-ca/certs/root-ca.cert.pem \
> ~/pki/intermediate-ca/certs/ca-chain.cert.pem

chmod 444 ~/pki/intermediate-ca/certs/ca-chain.cert.pem

Paso 6: emitir un certificado TLS para un servidor

Ahora puedes emitir certificados para servicios internos. Ejemplo: app.interno.local.

Genera la clave privada del servidor:

Clave privada del servidor

mkdir -p ~/pki/issued/app.interno.local
openssl genrsa -out ~/pki/issued/app.interno.local/app.interno.local.key.pem 2048
chmod 400 ~/pki/issued/app.interno.local/app.interno.local.key.pem

Crea la CSR con SAN. En certificados TLS modernos, el nombre DNS debe estar en subjectAltName.

CSR con Subject Alternative Name

openssl req -new -sha256 \
-key ~/pki/issued/app.interno.local/app.interno.local.key.pem \
-out ~/pki/issued/app.interno.local/app.interno.local.csr.pem \
-subj "/C=PE/ST=Lima/L=Lima/O=Empresa Demo/OU=TI/CN=app.interno.local" \
-addext "subjectAltName = DNS:app.interno.local,DNS:www.app.interno.local,IP:192.168.1.50"

Crea extensiones para el certificado de servidor:

Extensiones para TLS de servidor

cat > ~/pki/issued/app.interno.local/server.ext <<'EOF'
basicConstraints = CA:FALSE
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:app.interno.local,DNS:www.app.interno.local,IP:192.168.1.50
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer
EOF

Firma el certificado con la CA intermedia:

Firmar certificado TLS

openssl x509 -req -sha256 -days 397 \
-in ~/pki/issued/app.interno.local/app.interno.local.csr.pem \
-CA ~/pki/intermediate-ca/certs/intermediate-ca.cert.pem \
-CAkey ~/pki/intermediate-ca/private/intermediate-ca.key.pem \
-CAcreateserial \
-out ~/pki/issued/app.interno.local/app.interno.local.cert.pem \
-extfile ~/pki/issued/app.interno.local/server.ext

Verifica el certificado emitido:

Verificar cadena del certificado TLS

openssl verify -CAfile ~/pki/intermediate-ca/certs/ca-chain.cert.pem \
~/pki/issued/app.interno.local/app.interno.local.cert.pem

openssl x509 -noout -text 
-in ~/pki/issued/app.interno.local/app.interno.local.cert.pem

Paso 7: instalar el certificado en Nginx

Copia el certificado, la clave y la cadena al servidor web:

Rutas recomendadas para Nginx

sudo mkdir -p /etc/ssl/empresa-demo/{certs,private}
sudo cp app.interno.local.cert.pem /etc/ssl/empresa-demo/certs/
sudo cp ca-chain.cert.pem /etc/ssl/empresa-demo/certs/
sudo cp app.interno.local.key.pem /etc/ssl/empresa-demo/private/
sudo chmod 600 /etc/ssl/empresa-demo/private/app.interno.local.key.pem

Configura Nginx:

Ejemplo TLS en Nginx

server {
    listen 443 ssl http2;
    server_name app.interno.local;

```
ssl_certificate /etc/ssl/empresa-demo/certs/app.interno.local.cert.pem;
ssl_certificate_key /etc/ssl/empresa-demo/private/app.interno.local.key.pem;
ssl_trusted_certificate /etc/ssl/empresa-demo/certs/ca-chain.cert.pem;

ssl_protocols TLSv1.2 TLSv1.3;

location / {
    proxy_pass http://127.0.0.1:8080;
}
```

}

Prueba y recarga Nginx:

Validar Nginx

sudo nginx -t
sudo systemctl reload nginx

Paso 8: instalar la CA raíz en clientes Linux

Para que los clientes confíen en los certificados internos, instala el certificado raíz en el almacén de confianza del sistema.

En Ubuntu, Debian y Linux Mint:

Confiar en CA raíz en Debian/Ubuntu

sudo cp root-ca.cert.pem /usr/local/share/ca-certificates/empresa-demo-root-ca.crt
sudo update-ca-certificates

En Fedora, Rocky Linux, AlmaLinux o RHEL:

Confiar en CA raíz en RHEL/Fedora

sudo cp root-ca.cert.pem /etc/pki/ca-trust/source/anchors/empresa-demo-root-ca.pem
sudo update-ca-trust

Paso 9: probar TLS desde un cliente

Usa OpenSSL para comprobar la conexión TLS, la cadena y el nombre del servidor:

Probar TLS con OpenSSL

openssl s_client -connect app.interno.local:443 \
-servername app.interno.local \
-CAfile root-ca.cert.pem

También puedes probar con curl:

Probar HTTPS con curl

curl --cacert root-ca.cert.pem https://app.interno.local

Paso 10: habilitar autenticación mutua con mTLS

En TLS tradicional, el cliente valida el certificado del servidor. En mTLS, el servidor también exige un certificado al cliente. Esto es muy útil para APIs internas, microservicios, VPN, paneles administrativos y servicios de alta criticidad.

Ejemplo básico en Nginx:

mTLS en Nginx

server {
    listen 443 ssl http2;
    server_name api.interno.local;

```
ssl_certificate /etc/ssl/empresa-demo/certs/api.interno.local.cert.pem;
ssl_certificate_key /etc/ssl/empresa-demo/private/api.interno.local.key.pem;

ssl_client_certificate /etc/ssl/empresa-demo/certs/ca-chain.cert.pem;
ssl_verify_client on;
ssl_verify_depth 2;

location / {
    proxy_pass http://127.0.0.1:9000;
}
```

}

El cliente debe presentar su certificado y clave:

Consumir API con certificado de cliente

curl --cert cliente.cert.pem --key cliente.key.pem \
--cacert root-ca.cert.pem \
https://api.interno.local

Automatización moderna con step-ca

OpenSSL es excelente para entender cómo funciona una PKI, pero en producción es recomendable automatizar emisión y renovación. Una alternativa open source es step-ca, que permite desplegar una CA privada X.509 y un servidor ACME interno.

Con step-ca, una empresa puede emitir certificados internos usando clientes ACME, facilitar renovaciones y reducir el trabajo manual.

Cuándo usar step-ca: si necesitas emitir certificados para muchos servidores, automatizar renovaciones, usar ACME interno, aplicar mTLS o crear una PKI privada más operativa que una CA manual con OpenSSL.

Ejemplo conceptual de inicialización:

Inicializar una CA con step-ca

step ca init
step ca provisioner add acme --type ACME
step ca certificate app.interno.local app.crt app.key

En una implementación real, step-ca debe ejecutarse como servicio, con permisos restringidos, respaldo seguro, configuración revisada y políticas de emisión claras.

Revocación: qué hacer cuando un certificado ya no debe ser válido

La revocación es esencial cuando una clave privada se filtra, un usuario deja la organización, un servidor se retira o un certificado fue emitido por error.

Con OpenSSL, puedes generar una CRL de ejemplo:

Revocar certificado y generar CRL

openssl ca -config openssl-intermediate.cnf \
-revoke app.interno.local.cert.pem

openssl ca -config openssl-intermediate.cnf 
-gencrl -out intermediate-ca.crl.pem

Consejo práctico: si vas a operar PKI en producción, define desde el inicio cómo publicarás CRL u OCSP. Sin revocación operativa, la PKI queda incompleta.

Políticas recomendadas para una PKI empresarial

Política	Recomendación
CA raíz	Mantener offline, con clave cifrada, respaldo seguro y uso limitado.
CA intermedia	Usar para emitir certificados finales, con auditoría y control de acceso.
Certificados TLS	Usar SAN, EKU serverAuth, expiración limitada y renovación automatizada.
Certificados cliente	Usar EKU clientAuth, identidad clara y revocación inmediata al retiro.
Inventario	Registrar propietario, servicio, vencimiento, uso, huella y estado de revocación.
Respaldo	Respaldar claves CA, certificados, CRL, configuración y base de datos de emisión.

Errores frecuentes al implementar PKI

Usar la CA raíz directamente para emitir certificados de servidores.
Guardar la clave raíz en un servidor conectado a Internet.
No cifrar claves privadas de CA.
Emitir certificados sin SAN.
Crear certificados demasiado largos para servicios comunes.
No tener inventario de certificados emitidos.
No definir revocación ni renovación.
Instalar la CA raíz en equipos sin control.
Usar el mismo certificado para servidor y cliente sin EKU adecuado.
No monitorear fechas de vencimiento.

Checklist final de implementación

Definir alcance de la PKI: TLS, mTLS, VPN, usuarios, dispositivos o servicios.
Crear CA raíz offline y CA intermedia emisora.
Proteger claves privadas con cifrado y permisos restrictivos.
Definir políticas de emisión, renovación y revocación.
Usar SAN, keyUsage y extendedKeyUsage correctos.
Instalar la CA raíz solo en equipos autorizados.
Configurar TLS 1.2 y TLS 1.3 en servicios internos.
Automatizar emisión y renovación cuando el volumen lo justifique.
Registrar todos los certificados en un inventario.
Probar recuperación, revocación y renovación antes de producción.

Preguntas clave

¿Una PKI interna reemplaza a Let’s Encrypt?

No necesariamente. Let’s Encrypt y otras CAs públicas son ideales para servicios públicos en Internet. Una PKI interna es mejor para servicios privados, mTLS, usuarios, dispositivos y redes internas.

¿Por qué no debo usar solo certificados autofirmados?

Porque son difíciles de administrar a escala, no tienen cadena de confianza clara y suelen generar excepciones inseguras en navegadores o clientes.

¿Qué es mTLS?

Es autenticación mutua con certificados. El cliente valida al servidor y el servidor valida al cliente.

¿Qué es SAN?

Subject Alternative Name es la extensión donde se declaran los nombres DNS o direcciones IP para los que un certificado es válido.

¿Qué herramienta conviene: OpenSSL o step-ca?

OpenSSL es excelente para aprendizaje, laboratorios y operaciones manuales. step-ca es más conveniente cuando necesitas automatización, ACME interno, renovación y operación continua.

¿Qué pasa si se compromete la CA raíz?

Es uno de los peores escenarios. Se debe retirar la confianza, crear una nueva PKI, reemplazar certificados y tratar el evento como incidente crítico.

Recomendamos

En resumen

Implementar una PKI en Linux permite pasar de certificados improvisados a una arquitectura formal de confianza digital. La combinación de CA raíz offline, CA intermedia emisora, certificados TLS, mTLS, inventario, revocación y automatización crea una base sólida para proteger servicios internos y comunicaciones empresariales.

OpenSSL permite entender y construir la base manual de la PKI. step-ca ayuda a llevar esa base hacia una operación moderna, automatizada y escalable. La diferencia entre una PKI útil y una PKI peligrosa está en el gobierno: proteger claves, definir políticas, controlar emisión, revocar a tiempo y auditar todo el ciclo de vida.

Conclusión editorial

Una PKI no debe tratarse como un simple generador de certificados. Es una infraestructura crítica de identidad, confianza y seguridad. Bien implementada, permite TLS interno, mTLS, autenticación fuerte y control centralizado. Mal implementada, puede convertirse en una fuente de riesgo. La clave está en diseñarla con separación, automatización y disciplina operativa desde el primer día.

20 Julio 2026

Visto: 42

Rating:

( 0 Rating )