Tema: tls
-
Vigilar la caducidad de certificados TLS en todos los endpoints, no solo en el sitio web principal
Un certificado caducado es una interrupción con un momento exactamente predecible; sondear la fecha notAfter de cada certificado realmente servido (web, API, correo, paneles internos, balanceadores de carga) desde el exterior, alertar con antelación suficiente para renovar a mano, y comprobar los intermedios además del certificado hoja.
-
Cómo comprobar si una conexión TLS negoció realmente X25519MLKEM768
Distinguir una capacidad poscuántica instalada del grupo seleccionado en una conexión TLS real mediante los detalles del navegador, OpenSSL, curl y las pruebas del lado del servidor.
-
Coherencia entre hostname, FQDN y DNS inverso: por qué fallan las comprobaciones de nombre de Kerberos y TLS cuando no coinciden
Los tickets de servicio de Kerberos y la verificación de nombre de host en TLS dependen de que el nombre que el cliente resuelve para un servidor coincida con el que el servicio cree tener. Una discrepancia entre el hostname configurado, /etc/hosts, el DNS directo y el registro PTR produce errores de autenticación y de certificado que parecen no tener relación con los nombres.
-
El handshake de TLS 1.3 en líneas generales
TLS 1.3 negocia las claves en un único viaje de ida y vuelta (round trip): el ClientHello ya incluye un key share, el ServerHello responde con el suyo, y todo lo que sigue, incluido el certificado, va cifrado. La reanudación usa claves precompartidas procedentes de tickets de sesión; los datos tempranos 0-RTT son opcionales y pueden repetirse (replay).
-
Errores de verificación TLS en distintas herramientas: unknown authority, CERTIFICATE_VERIFY_FAILED, self-signed in chain
Distintos clientes TLS notifican con sus propias palabras el mismo fallo de fondo, una cadena de certificados incompleta o no confiable: 'certificate signed by unknown authority', 'CERTIFICATE_VERIFY_FAILED', 'unable to get local issuer certificate', 'self-signed certificate in certificate chain'. El artículo explica cómo diagnosticar la cadena real con openssl s_client antes de aplicar cualquier solución, y por qué -k o verify=False nunca lo son.
-
Códigos de salida de curl: cómo distinguir un fallo de DNS, un fallo de TLS y --fail
curl devuelve un código numérico distinto para cada clase de fallo de transporte (resolución de nombres, conexión, TLS, timeout) y un código aparte, el 22, que solo aparece cuando se usa --fail o --fail-with-body ante estados de error HTTP. Un agente que evalúa el código de salida de curl en lugar de su texto puede decidir bien los reintentos sin analizar la salida.
-
Firmas poscuánticas y certificados TLS públicos: comprobaciones de preparación independientes
ML-DSA y SLH-DSA son algoritmos de firma estandarizados, pero la emisión de certificados TLS públicos también depende de los perfiles de certificado, la integración con el protocolo y la aceptación en las políticas de confianza.
-
Comprobar desde la línea de comandos, con openssl, la cadena de certificados TLS servida y su caducidad
openssl s_client con -servername y -showcerts imprime los certificados que el servidor realmente envía, algo que el manual describe como una cadena no verificada; openssl x509 lee el subject, el issuer, los SAN y la fecha notAfter de cada uno, y openssl verify -untrusted reconstruye la cadena frente a un almacén de confianza. Conviene comprobar cada nombre de host, y IPv4 e IPv6 por separado.
-
Añadir una CA privada al almacén de confianza del sistema en la familia RHEL y en Debian/Ubuntu
Las distribuciones Linux de la familia RHEL y de la familia Debian usan mecanismos distintos para añadir un certificado de CA de confianza local: update-ca-trust con anchors en /etc/pki/ca-trust, y update-ca-certificates con archivos .crt en /usr/local/share/ca-certificates. Usar un directorio o una extensión incorrectos deja la CA sin confianza, sin mostrar ningún error.
-
Cómo detectar listas fijas de grupos TLS que impiden adoptar los valores híbridos predeterminados
Auditar las listas explícitas de grupos en la configuración de Go, Java, nginx y OpenSSL antes de asumir que actualizar una biblioteca habilita el intercambio de claves poscuántico.
-
Cambiar las políticas criptográficas del sistema en RHEL con update-crypto-policies
La política criptográfica global de RHEL define los algoritmos y las versiones de protocolo predeterminados que ofrecen OpenSSL, GnuTLS, NSS, libkrb5 y OpenSSH, y se cambia con un solo comando en lugar de editar la configuración de cada aplicación. Esta metodología explica cómo consultar, establecer y probar una política, y por qué los servicios que ya están en ejecución requieren un reinicio para aplicarla.
-
TLS para el reenvío con rsyslog mediante el controlador gtls y cuándo conviene añadir RELP
El controlador de flujo de red gtls de rsyslog cifra una conexión de reenvío y puede autenticarla mutuamente con certificados X.509, mediante StreamDriverAuthMode. TLS simple sobre TCP sigue perdiendo mensajes en tránsito si la conexión se corta de forma abrupta; la confirmación de RELP a nivel de aplicación cubre ese hueco, a costa de más componentes.
-
Confiar en una CA privada en macOS y Windows y comprobar que el cambio realmente se aplicó
macOS confía en una CA raíz para todo el sistema mediante el llavero System con `security add-trusted-cert`, y Windows mediante el almacén Root del equipo local con Import-Certificate o certutil -addstore. Ninguno de los dos cambios da indicación alguna salvo que se verifique por separado, y ambos se diferencian de una decisión de confianza por usuario o por navegador.
-
HTTPS local para desarrollo: una CA privada, almacenes de confianza y la excepción de localhost
Los navegadores ya tratan localhost y las direcciones de loopback como potencialmente confiables, por lo que el HTTPS local solo hace falta para probar comportamientos propios de TLS o usar nombres de desarrollo que no sean de loopback; en esos casos, crea una CA privada por equipo con una herramienta como mkcert, emite certificados de hoja para los nombres de desarrollo, instala la raíz en el almacén del sistema y en los de cada herramienta, y nunca compartas la clave de la CA.
-
Por qué las aplicaciones ignoran el almacén de confianza del SO: cacerts de Java, certifi de Python, Node.js y curl
Añadir una CA al almacén de confianza del sistema operativo no hace que todas las aplicaciones confíen en ella. Java, muchas instalaciones de Python, Node.js y ciertas compilaciones de curl pueden tener su propio paquete de CA o keystore, cada uno con su ubicación y su variable de entorno para sobrescribirlo, de modo que un error de certificado puede persistir tras la corrección a nivel de SO.
Legible por máquina: JSON