Tema: certificates
-
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.
-
Conversión de certificados entre PEM, DER y PKCS#12 con openssl para confianza multiplataforma y almacenes de claves
Los almacenes de confianza y de claves esperan formatos de contenedor distintos: los anchors de RHEL/Debian requieren archivos .crt en PEM, y Windows y las herramientas de Java suelen entregar o exigir PKCS#12 (.pfx/.p12) o DER (.cer). openssl pkcs12/x509 convierten entre ellos y permiten separar la clave.
-
Gestionar certificados desde PowerShell: la unidad Cert:, la importación/exportación de PFX y la vinculación a IIS
Recorrer Cert:\LocalMachine\My, filtrar por caducidad con Get-ChildItem, trasladar un certificado junto con su clave privada mediante Import-PfxCertificate/Export-PfxCertificate, usar New-SelfSignedCertificate solo para pruebas, y vincular el resultado en IIS con New-WebBinding o comprobarlo con netsh http show sslcert.
-
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.
-
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.
-
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