TLS HANDSHAKE
SAFE OPERATING BOUNDARY
NGINX server block·full-chain 경로·protocol 변경은 0600으로 보관한 정확한 이전 config를 nginx -t로 검증한 뒤 reload해 되돌립니다. 인증서 갱신은 임의 삭제하지 않고 CA·Certbot lineage에 보관된 검증된 이전 공개 certificate와 기존 private key를 표준 배포 절차로 다시 참조합니다. private key와 ACME credential은 rollback 증거에 포함하거나 출력하지 않습니다.
BEFORE YOU START
CHECK THE BRANCH
endpoint가 실제로 제공하는 leaf 인증서의 notBefore·notAfter와 UTC 시각을 비교합니다. 파일만 갱신되고 proxy가 이전 인증서를 계속 제공하는 상황을 구분합니다.
leaf 다음 intermediate가 서버에서 제공되는지와 client trust store를 분리합니다. NGINX ssl_certificate에는 leaf가 먼저 오고 intermediate가 뒤따르는 full chain을 사용합니다.
DNS 이름을 -servername과 -verify_hostname에 모두 넣고 각 LB/backend IP에 연결해 비교합니다. IP로만 접속한 결과의 default certificate를 정상 인증서로 오판하지 않습니다.
TLS 1.2와 TLS 1.3을 각각 검증해 client/server 공통 범위를 확인합니다. 문제 해결을 위해 TLS 1.0·1.1이나 인증서 검증 우회를 켜지 않습니다.
FOLLOW THE FLOW
인증 정보나 client certificate를 넣지 않은 공개 health endpoint에서 시작합니다. curl --insecure 또는 -k를 사용하지 않으며 OpenSSL에는 검증 실패 시 중단 옵션을 넣습니다.
date -u '+%Y-%m-%dT%H:%M:%SZ'getent ahosts <DNS_NAME>curl --fail --silent --show-error --output /dev/null --max-time 10 'https://<DNS_NAME>/<APPROVED_HEALTH_PATH>'openssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -verify_hostname '<DNS_NAME>' -verify_return_error -brief </dev/nullcurl과 s_client가 모두 실패하면 인증서·chain·protocol 분기를, 특정 IP/backend에서만 실패하면 SNI routing 또는 배포 불일치를 우선 확인합니다.
endpoint가 제공하는 leaf 공개정보와 30일 만료 임계, 별도 chain 검증을 확인합니다.
인증서는 공개 정보지만 내부 SAN과 topology가 포함될 수 있어 외부 공유 전 마스킹합니다. 이 단계의 s_client pipeline은 불신·만료 인증서에서도 공개 leaf 메타데이터를 수집하기 위해 verify_return_error를 사용하지 않는 진단 전용입니다. 비검증 수집 결과는 절대 정상 판정에 쓰지 않고 1단계의 별도 검증 handshake 결과와 함께 봅니다. private key 파일 내용은 어떤 명령에서도 출력하지 않습니다.
set -o pipefail
openssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -showcerts </dev/null | openssl x509 -noout -subject -issuer -serial -dates -ext subjectAltName -fingerprint -sha256set -o pipefail
openssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -showcerts </dev/null | openssl x509 -checkend 2592000 -nooutopenssl verify -show_chain -CAfile <APPROVED_CA_BUNDLE> -untrusted <INTERMEDIATE_CHAIN_PEM> <LEAF_CERT_PEM>sudo nginx -T 2>&1 | grep -E '^[[:space:]]*(server_name|listen|ssl_certificate|ssl_certificate_key|ssl_protocols)'
sudo stat -Lc '%a %U:%G %n' <PRIVATE_KEY_PATH>SAN에 DNS 이름이 없으면 hostname 문제, notAfter 임박·경과면 갱신 문제, endpoint chain은 실패하지만 leaf 자체 날짜가 정상이라면 intermediate 제공 순서나 client CA bundle 문제입니다.
SNI별 backend와 TLS 1.2·1.3을 동일한 검증 조건으로 비교합니다.
LB 뒤 여러 IP를 하나씩 확인합니다. 신뢰 판정 명령은 -servername과 -verify_hostname을 실제 서비스 DNS 이름으로 유지합니다. 그 다음 별도 비검증 명령으로 공개 leaf fingerprint만 수집할 수 있지만 그 결과를 정상 판정에 사용하지 않습니다.
openssl s_client -connect '<APPROVED_BACKEND_IP>:443' -servername '<DNS_NAME>' -verify_hostname '<DNS_NAME>' -verify_return_error -brief </dev/nullset -o pipefail
openssl s_client -connect '<APPROVED_BACKEND_IP>:443' -servername '<DNS_NAME>' -showcerts </dev/null | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256openssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -verify_hostname '<DNS_NAME>' -verify_return_error -tls1_2 -brief </dev/nullopenssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -verify_hostname '<DNS_NAME>' -verify_return_error -tls1_3 -brief </dev/nullopenssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -verify_hostname '<DNS_NAME>' -verify_return_error -alpn 'h2,http/1.1' -brief </dev/nullinstall -d -m 0700 <APPROVED_EVIDENCE_DIR>
umask 077
if sudo test -f <NGINX_TLS_CONFIG>; then sudo cp --archive --no-clobber <NGINX_TLS_CONFIG> <APPROVED_EVIDENCE_DIR>/nginx-tls.before.conf; fi
if sudo test -f <APPROVED_EVIDENCE_DIR>/nginx-tls.before.conf; then sudo chmod 0600 <APPROVED_EVIDENCE_DIR>/nginx-tls.before.conf; fibackend별 fingerprint가 다르면 배포 불일치, DNS name handshake와 고정 IP+SNI 결과가 다르면 LB routing, 특정 protocol만 실패하면 승인된 client compatibility와 server policy 교집합 문제입니다.
인증서 갱신 또는 NGINX full-chain·protocol 설정 중 확인된 원인 하나만 변경합니다.
CA rate limit·domain validation·LB 전체 배포 범위와 rollback certificate를 확인합니다. dry-run 성공 없이 live renewal하지 않고, nginx -t 성공 없이 reload하지 않습니다.
sudo certbot certificatessudo certbot renew --cert-name <CERT_NAME> --dry-runsudo certbot renew --cert-name <CERT_NAME>sudo install -o root -g root -m 0644 <REVIEWED_NGINX_TLS_CONFIG> <NGINX_TLS_CONFIG>
sudo nginx -t
sudo systemctl reload nginx갱신은 새 certificate lineage 제공, NGINX 변경은 chain 경로·SNI server block·protocol policy 적용입니다. 원인과 무관한 두 분기를 동시에 실행하지 않습니다.
외부 DNS와 각 backend에서 fingerprint·chain·SNI·TLS protocol을 다시 확인하고 실패하면 이전 config 또는 last-known-good certificate 참조로 원복합니다.
DNS cache와 LB 전파를 고려해 최소 두 관찰 지점에서 검증합니다. 브라우저 한 대의 cache된 intermediate만으로 성공을 판단하지 않습니다.
curl --fail --silent --show-error --output /dev/null --max-time 10 'https://<DNS_NAME>/<APPROVED_HEALTH_PATH>'
openssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -verify_hostname '<DNS_NAME>' -verify_return_error -brief </dev/nullset -o pipefail
openssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -showcerts </dev/null | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256openssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -verify_hostname '<DNS_NAME>' -verify_return_error -tls1_2 -brief </dev/null
openssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -verify_hostname '<DNS_NAME>' -verify_return_error -tls1_3 -brief </dev/nullsudo install -o root -g root -m 0644 <APPROVED_EVIDENCE_DIR>/nginx-tls.before.conf <NGINX_TLS_CONFIG>
sudo nginx -t
sudo systemctl reload nginxopenssl s_client -connect '<DNS_NAME>:443' -servername '<DNS_NAME>' -verify_hostname '<DNS_NAME>' -verify_return_error -brief </dev/null정확한 SAN과 만료일, verify return 성공, 의도한 chain과 backend fingerprint 일치, 승인된 TLS 1.2·1.3 결과, HTTP health 성공이 모두 충족돼야 합니다.
NGINX config는 0600 백업으로 원복합니다. certificate lineage는 CA·Certbot의 검증된 이전 공개 certificate와 기존 private key 조합을 표준 배포 절차로 다시 참조하며, private key를 티켓·터미널 출력·임시 파일로 복사하지 않습니다.
PRIMARY REFERENCES
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.