Topic: tls
-
Monitoring TLS certificate expiry on every endpoint, not only the main website
An expired certificate is an outage with an exactly predictable time; probe the notAfter date of every certificate actually served (web, API, mail, internal panels, load balancers) from outside, alert with a lead time long enough to renew by hand, and check the intermediates as well as the leaf.
-
Checking whether a TLS connection actually negotiated X25519MLKEM768
Distinguish an installed post-quantum capability from the group selected on a real TLS connection, using browser details, OpenSSL, curl and server-side evidence.
-
Hostname, FQDN and reverse DNS consistency: why Kerberos and TLS name checks break when they disagree
Kerberos service tickets and TLS hostname verification both depend on the name a client resolves for a server matching the name the service believes it has. A mismatch between the configured hostname, /etc/hosts, forward DNS and the PTR record produces authentication and certificate errors that look unrelated to naming.
-
The TLS 1.3 handshake in outline
TLS 1.3 negotiates keys in one round trip: the ClientHello already carries a key share, the ServerHello answers with its own, and everything after it, including the certificate, is encrypted. Resumption uses pre-shared keys from session tickets; 0-RTT early data is optional and replayable.
-
TLS verification errors across tools: unknown authority, CERTIFICATE_VERIFY_FAILED, self-signed in chain
Different TLS clients report the same underlying failure - an incomplete or untrusted certificate chain - in their own wording: 'certificate signed by unknown authority', 'CERTIFICATE_VERIFY_FAILED', 'unable to get local issuer certificate', 'self-signed certificate in certificate chain'. The article shows how to diagnose the actual chain with openssl s_client before reaching for any fix, and why -k or verify=False is never one.
-
curl's exit codes: telling a DNS failure from a TLS failure from --fail
curl returns a distinct numeric code for each class of transport failure (name resolution, connection, TLS, timeout) plus a separate code, 22, that only appears when --fail or --fail-with-body is requested for HTTP error statuses. An agent that greps curl's exit code instead of its text can route retries correctly without parsing output.
-
Post-quantum signatures and public TLS certificates: separate readiness checks
ML-DSA and SLH-DSA are standardized signature algorithms, but public TLS certificate issuance also depends on certificate profiles, protocol integration and trust-policy acceptance.
-
Checking a served TLS certificate chain and its expiry from the command line with openssl
openssl s_client with -servername and -showcerts prints the certificates a server actually sends, which the manual describes as not a verified chain; openssl x509 reads subject, issuer, SANs and the notAfter date of each one, and openssl verify -untrusted rebuilds the chain against a trust store. Check every hostname, and IPv4 and IPv6 separately.
-
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.
-
Finding TLS group pins that prevent applications from adopting hybrid defaults
Audit explicit group lists in Go, Java, nginx and OpenSSL configuration before assuming a library upgrade enables post-quantum key exchange.
-
Switching system-wide crypto policies on RHEL with update-crypto-policies
RHEL's system-wide crypto policy sets the default algorithms and protocol versions OpenSSL, GnuTLS, NSS, libkrb5 and OpenSSH offer, changeable in one command instead of editing every application's config. This methodology covers showing, setting and testing a policy, and why already-running services need a restart to pick it up.
-
TLS for rsyslog forwarding with the gtls driver, and when RELP is worth adding
rsyslog's gtls network stream driver encrypts and can mutually authenticate a forwarding connection with X.509 certificates, configured with StreamDriverAuthMode. Plain TLS over TCP still loses in-flight messages on an unclean disconnect; RELP's application-level acknowledgement is what closes that gap, at the cost of extra moving parts.
-
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.
-
Local HTTPS for development: a private CA, trust stores and the localhost exception
Browsers already treat localhost and loopback addresses as potentially trustworthy, so local HTTPS is needed only for TLS-specific behaviour or non-loopback development names; for those, create a private CA per machine with a tool such as mkcert, issue leaf certificates for development names, install the root in the system and per-tool trust stores, and never share the CA key.
-
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.
Machine-readable: JSON