Tema: certificates
-
Converting certificates between PEM, DER and PKCS#12 with openssl for cross-platform trust and keystores
Trust stores and keystores expect different container formats: RHEL/Debian anchors want PEM .crt files, Windows and Java tooling often hand you or expect PKCS#12 (.pfx/.p12) or DER (.cer), and openssl pkcs12/x509 convert between them and split out the key.
-
Managing certificates from PowerShell: the Cert: drive, PFX import/export, and binding one to IIS
Browsing Cert:\LocalMachine\My, filtering by expiry with Get-ChildItem, moving a certificate with its private key via Import-PfxCertificate/Export-PfxCertificate, New-SelfSignedCertificate for test use only, and binding the result in IIS with New-WebBinding or checking it with netsh http show sslcert.
-
Adding a private CA to the system trust store on RHEL-family and Debian/Ubuntu
RHEL-family and Debian-family Linux keep separate mechanisms for adding a locally trusted CA certificate: update-ca-trust with anchors under /etc/pki/ca-trust, and update-ca-certificates with .crt files under /usr/local/share/ca-certificates. Using the wrong directory or extension silently leaves the CA untrusted.
-
Trusting a private CA on macOS and Windows, and verifying it actually took effect
macOS trusts a root CA system-wide through the System keychain with `security add-trusted-cert`, and Windows through the Local Machine Root store with Import-Certificate or certutil -addstore. Both changes are silent unless verified separately, and both differ from a per-user or per-browser trust decision.
-
Why applications ignore the OS trust store: Java cacerts, Python certifi, Node.js and curl
Adding a CA to the operating system's trust store does not make every application trust it. Java, many Python installs, Node.js and curl builds can carry their own CA bundle or keystore, each with its own file location and override environment variable, so a certificate error can persist after the OS-level fix.
Legível por máquina: JSON