Comandos Linux para administrar certificados SSL/TLS

By FrankLinux, production_support, Seguridad

Los certificados SSL/TLS son una parte crítica de prácticamente cualquier infraestructura moderna. Aplicaciones web, APIs, balanceadores, servidores de aplicaciones, proxies y plataformas middleware dependen de ellos para establecer comunicaciones seguras.

En ambientes productivos, un certificado vencido puede provocar desde errores de conexión hasta la caída completa de una integración.

Para un ingeniero de Production Support, Middleware o SysAdmin, saber diagnosticar problemas de certificados desde Linux es una habilidad fundamental.

A continuación veremos algunos de los comandos que más utilizo para investigar y administrar certificados SSL/TLS.

Importante: antes de reemplazar certificados, llaves privadas o keystores en producción, realiza un respaldo y sigue los procedimientos de Change Management de tu organización.

1. Consultar el certificado presentado por un servidor

Uno de los comandos más importantes es:

openssl s_client -connect servidor.example.com:443

Esto establece una conexión TLS y muestra información sobre la negociación y los certificados recibidos.

Para especificar SNI:

openssl s_client \
-connect servidor.example.com:443 \
-servername servidor.example.com

Usar -servername es especialmente importante cuando varios sitios comparten la misma dirección IP.

2. Consultar las fechas de un certificado remoto

Durante troubleshooting normalmente queremos saber rápidamente cuándo vence el certificado.

openssl s_client \
-connect servidor.example.com:443 \
-servername servidor.example.com \
</dev/null 2>/dev/null |
openssl x509 -noout -dates

Obtendremos información similar a:

notBefore=Aug 15 00:00:00 2026 GMT
notAfter=Aug 15 23:59:59 2027 GMT

El campo más importante para revisar la expiración es:

notAfter

3. Revisar Subject, Issuer y fechas

Una variante muy útil para soporte:

openssl s_client \
-connect servidor.example.com:443 \
-servername servidor.example.com \
</dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates

Esto nos permite identificar rápidamente:

  • Subject: para quién fue emitido.
  • Issuer: quién lo emitió.
  • notBefore: desde cuándo es válido.
  • notAfter: cuándo expira.

4. Mostrar toda la información del certificado

Para analizar un certificado almacenado localmente:

openssl x509 -in certificado.pem -text -noout

Aquí podemos revisar información como:

  • Issuer
  • Subject
  • Serial Number
  • Signature Algorithm
  • Public Key
  • Validity
  • Extensions
  • Subject Alternative Names

5. Revisar los Subject Alternative Names (SAN)

Actualmente es fundamental comprobar los SAN del certificado.

openssl x509 \
-in certificado.pem \
-noout \
-ext subjectAltName

Podemos encontrar algo similar a:

X509v3 Subject Alternative Name:
    DNS:api.example.com
    DNS:www.example.com
    DNS:server.example.com

Si el hostname utilizado por la aplicación no aparece entre los nombres válidos del certificado, el cliente puede rechazar la conexión.

6. Consultar cuándo vence un certificado local

openssl x509 -in certificado.pem -noout -enddate

Ejemplo:

notAfter=Aug 15 23:59:59 2027 GMT

7. Comprobar automáticamente si está próximo a vencer

openssl puede comprobar si el certificado seguirá siendo válido después de determinado número de segundos.

Por ejemplo, comprobar los próximos 30 días:

openssl x509 \
-in certificado.pem \
-checkend 2592000 \
-noout

2592000 segundos equivalen aproximadamente a 30 días.

Podemos utilizarlo en scripts:

if openssl x509 -in certificado.pem -checkend 2592000 -noout
then
    echo "Certificado válido por más de 30 días"
else
    echo "WARNING: certificado próximo a expirar"
fi

Este tipo de validación es excelente para automatizar monitoreo.

8. Verificar un certificado con curl

Para probar una URL HTTPS:

curl -v https://servidor.example.com

La opción -v permite observar información relacionada con:

  • conexión TCP;
  • negociación TLS;
  • certificado;
  • hostname;
  • respuesta HTTP.

Para consultar solamente los headers:

curl -I https://servidor.example.com

9. Probar utilizando una CA específica

Cuando trabajamos con certificados internos:

curl \
--cacert ca-certificate.pem \
https://servidor.example.com

Esto es particularmente útil cuando la organización utiliza una Certificate Authority privada.

10. Ignorar temporalmente la validación del certificado

Durante troubleshooting podemos encontrar:

curl -k https://servidor.example.com

o:

curl --insecure https://servidor.example.com

⚠️ No debe utilizarse como solución permanente.

Si una conexión solamente funciona con -k, normalmente tenemos que investigar la confianza del certificado, hostname, cadena de certificación u otra causa relacionada con TLS.

11. Descargar el certificado presentado por un servidor

Podemos obtener el certificado y almacenarlo:

openssl s_client \
-connect servidor.example.com:443 \
-servername servidor.example.com \
</dev/null 2>/dev/null |
openssl x509 -outform PEM > servidor.pem

Después podemos analizarlo:

openssl x509 -in servidor.pem -text -noout

12. Obtener la cadena de certificados

Para visualizar los certificados enviados por el servidor:

openssl s_client \
-connect servidor.example.com:443 \
-servername servidor.example.com \
-showcerts

Esto resulta especialmente útil cuando investigamos errores como:

unable to get local issuer certificate

o:

unable to verify the first certificate

Una causa frecuente es que el servidor no esté proporcionando correctamente algún certificado intermedio.

13. Verificar una cadena de confianza

Si tenemos:

server.pem
intermediate.pem
root.pem

podemos construir un bundle:

cat intermediate.pem root.pem > chain.pem

Y comprobar el certificado:

openssl verify \
-CAfile chain.pem \
server.pem

Si todo está correcto veremos:

server.pem: OK

14. Crear una llave privada

Por ejemplo, generar una llave RSA de 2048 bits:

openssl genrsa -out servidor.key 2048

En entornos donde la política de seguridad lo permita, también pueden utilizarse tamaños mayores.

La llave privada debe protegerse cuidadosamente:

chmod 600 servidor.key

Nunca debería enviarse por correo, tickets, chats o repositorios de código.

15. Crear un CSR

Para solicitar un nuevo certificado necesitamos normalmente un Certificate Signing Request (CSR).

openssl req \
-new \
-key servidor.key \
-out servidor.csr

Durante el proceso se solicitarán datos como:

Country
State
Locality
Organization
Organizational Unit
Common Name

El Common Name podría ser:

api.example.com

En infraestructuras actuales también debemos asegurarnos de que los nombres requeridos estén incluidos correctamente como Subject Alternative Names según el proceso de nuestra CA.

16. Revisar un CSR antes de enviarlo

Antes de enviar el CSR al equipo de certificados:

openssl req \
-in servidor.csr \
-text \
-noout

También podemos revisar solamente el subject:

openssl req \
-in servidor.csr \
-noout \
-subject

Esto evita solicitar un certificado con información incorrecta.

17. Verificar que certificado y llave privada correspondan

Este es uno de los problemas clásicos durante una renovación.

Podemos comparar la clave pública derivada de ambos archivos.

Certificado:

openssl x509 \
-in servidor.pem \
-pubkey -noout |
openssl pkey -pubin -outform DER |
openssl sha256

Llave:

openssl pkey \
-in servidor.key \
-pubout -outform DER |
openssl sha256

Los hashes deben ser iguales.

Si son diferentes, esa llave privada no corresponde al certificado.

18. Convertir DER a PEM

Algunas plataformas entregan certificados en formato DER.

openssl x509 \
-inform DER \
-in certificado.cer \
-out certificado.pem

19. Convertir PEM a DER

openssl x509 \
-in certificado.pem \
-outform DER \
-out certificado.der

20. Crear un archivo PKCS#12

Para importar certificado y llave en determinados servidores de aplicaciones podemos necesitar .p12 o .pfx.

openssl pkcs12 \
-export \
-out servidor.p12 \
-inkey servidor.key \
-in servidor.pem

Si necesitamos incluir certificados intermedios:

openssl pkcs12 \
-export \
-out servidor.p12 \
-inkey servidor.key \
-in servidor.pem \
-certfile intermediate.pem

21. Inspeccionar un PKCS#12

openssl pkcs12 \
-in servidor.p12 \
-info \
-noout

Para mostrar certificados sin extraer las llaves:

openssl pkcs12 \
-in servidor.p12 \
-clcerts \
-nokeys

22. Administrar Java Keystores con keytool

En ambientes Java, WebLogic, WebSphere, Tomcat y otras plataformas podemos encontrar Java Keystores.

Listar su contenido:

keytool -list \
-v \
-keystore keystore.jks

Buscar un alias concreto:

keytool -list \
-v \
-keystore keystore.jks \
-alias servidor

23. Importar un certificado en un Java Keystore

keytool -importcert \
-alias servidor \
-file certificado.pem \
-keystore truststore.jks

Antes de aceptar la importación debemos comprobar cuidadosamente:

  • Subject
  • Issuer
  • Serial Number
  • Fingerprint

24. Listar rápidamente certificados de un keystore

keytool -list -keystore truststore.jks

También podemos buscar información:

keytool -list -v \
-keystore truststore.jks |
grep -Ei "Alias|Owner|Issuer|Valid"

Muy útil cuando un truststore contiene decenas o cientos de certificados.

25. Revisar protocolos TLS

Podemos probar versiones concretas de TLS.

TLS 1.2:

openssl s_client \
-connect servidor.example.com:443 \
-servername servidor.example.com \
-tls1_2

TLS 1.3:

openssl s_client \
-connect servidor.example.com:443 \
-servername servidor.example.com \
-tls1_3

Esto puede ayudar cuando una aplicación antigua deja de conectarse después de que un servidor deshabilita protocolos obsoletos.

Escenario real: una API dejó de funcionar después de renovar el certificado

Supongamos que recibimos:

“La aplicación no puede conectarse al API después del cambio de certificado.”

Antes de reiniciar servicios podemos investigar.

1. Verificar conectividad

nc -vz api.example.com 443

2. Revisar el certificado remoto

openssl s_client \
-connect api.example.com:443 \
-servername api.example.com

3. Revisar fechas, issuer y subject

openssl s_client \
-connect api.example.com:443 \
-servername api.example.com \
</dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates

4. Revisar la cadena

openssl s_client \
-connect api.example.com:443 \
-servername api.example.com \
-showcerts

5. Probar desde el mismo servidor de aplicación

curl -v https://api.example.com

6. Revisar el truststore Java

keytool -list -v \
-keystore truststore.jks

Con estas pruebas podemos comenzar a determinar si tenemos un problema de:

certificado → cadena → truststore → hostname → protocolo TLS → conectividad → configuración de la aplicación.

SSL/TLS Cheat Sheet para Production Support

CERTIFICADO REMOTO
openssl s_client -connect host:443 -servername host

FECHA DE EXPIRACIÓN
openssl x509 -in cert.pem -noout -dates

INFORMACIÓN COMPLETA
openssl x509 -in cert.pem -text -noout

SUBJECT / ISSUER
openssl x509 -in cert.pem -noout -subject -issuer

SAN
openssl x509 -in cert.pem -noout -ext subjectAltName

VALIDAR PRÓXIMOS 30 DÍAS
openssl x509 -in cert.pem -checkend 2592000 -noout

CADENA
openssl s_client -connect host:443 -servername host -showcerts

VALIDAR CERTIFICADO
openssl verify -CAfile chain.pem server.pem

HTTPS
curl -v https://host

CA ESPECÍFICA
curl --cacert ca.pem https://host

CSR
openssl req -new -key server.key -out server.csr

REVISAR CSR
openssl req -in server.csr -text -noout

PKCS#12
openssl pkcs12 -export -out server.p12 \
-inkey server.key -in server.pem

JAVA KEYSTORE
keytool -list -v -keystore keystore.jks

TLS 1.2
openssl s_client -connect host:443 -tls1_2

TLS 1.3
openssl s_client -connect host:443 -tls1_3

Buenas prácticas en producción

La administración de certificados no consiste únicamente en reemplazarlos antes de que expiren. En un entorno productivo debemos considerar todo el ciclo de vida:

Inventario → monitoreo → renovación → respaldo → instalación → validación → rollback → documentación.

Nunca reemplaces directamente un keystore productivo sin contar con un respaldo y un procedimiento de rollback.

Protege las llaves privadas y limita sus permisos.

Valida el certificado, SAN y cadena antes de realizar el cambio.

Después de instalarlo, prueba la conexión desde el mismo servidor donde se ejecuta la aplicación, no solamente desde tu laptop.

Y, sobre todo, automatiza el monitoreo de expiración. Un certificado vencido es uno de los incidentes más fáciles de prevenir.

Conclusión

En Production Support, openssl, curl y keytool son herramientas esenciales para diagnosticar problemas SSL/TLS.

Cuando una aplicación reporta un error de conexión segura, evita asumir inmediatamente que “el certificado está mal”.

Investiga sistemáticamente:

¿Hay conectividad? → ¿Qué certificado entrega el servidor? → ¿Está vigente? → ¿El hostname coincide? → ¿La cadena está completa? → ¿La CA es confiable? → ¿El truststore contiene la CA necesaria? → ¿Cliente y servidor soportan protocolos compatibles?

Dominar estos comandos puede convertir un incidente SSL/TLS de varias horas en un diagnóstico de pocos minutos.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *