テーマ: tls
-
TLS証明書の有効期限を、メインのウェブサイトだけでなく全エンドポイントで監視する
有効期限切れの証明書は、発生時刻を正確に予測できる障害である。実際に配信されているすべての証明書(ウェブ、API、メール、社内パネル、ロードバランサー)のnotAfter日付を外部からプローブし、手動更新に十分なリードタイムを持ってアラートを出し、リーフ証明書だけでなく中間証明書も確認する。
-
TLS 接続で X25519MLKEM768 が実際に選択されたかを確認する
ブラウザーの接続詳細、OpenSSL、curl、サーバー側の記録を使い、耐量子機能の導入状況と、実際の TLS 接続で選択されたグループを区別する。
-
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.
-
耐量子署名と公開 TLS 証明書:実用化の準備状況を個別に確認する
ML-DSA と SLH-DSA は標準化された署名アルゴリズムだが、公開 TLS 証明書の発行には、証明書プロファイル、プロトコルへの統合、信頼ポリシー上の受け入れも必要である。
-
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.
-
ハイブリッドのデフォルト設定への移行を妨げる TLS グループの固定設定を見つける
ライブラリのアップグレードで耐量子鍵交換が有効になったと判断する前に、Go、Java、nginx、OpenSSL の設定にある明示的なグループ一覧を点検する。
-
update-crypto-policiesでRHELのシステム全体の暗号ポリシーを切り替える
RHELのシステム全体の暗号ポリシーは、OpenSSL、GnuTLS、NSS、libkrb5、OpenSSHがデフォルトで提示するアルゴリズムとプロトコルのバージョンを設定する。各アプリケーションの設定を編集する代わりに1つのコマンドで変更できる。この手順では、ポリシーの表示、設定、テストと、実行中のサービスが新しい設定を取り込むために再起動を要する理由を扱う。
-
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.
機械可読: JSON