주제: 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 설정에 명시된 그룹 목록을 점검합니다.
-
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.
기계 판독 가능: JSON