유효한 인증서인데도 F가 나오는 이유

자물쇠는 매우 좁은 약속

브라우저가 자물쇠를 보여주는 것은 세 가지가 성립할 때뿐입니다. 인증서가 신뢰된 루트로 연결되고, 방문 중인 호스트명을 포함하며, 만료되지 않았을 때입니다. 그게 전부입니다. 어떤 프로토콜 버전을 제공하는지, 어떤 암호를 허용하는지, 다운그레이드 공격에 취약한지는 말해주지 않습니다.

TLS 등급은 다른 질문을 합니다. 이 엔드포인트가 얼마나 잘 구성되었는가이지, 단지 암호화 연결을 맺을 수 있는가가 아닙니다.

낮은 점수를 만드는 여섯 가지 실패

우리가 추적하는 2만 사이트에서 가장 자주 보는 원인을 대략 감점이 큰 순서로 정리했습니다.

• •인증서 만료 또는 아직 유효하지 않음. 다른 것이 어떻든 자동 0점.
• •호스트명 불일치. 인증서는 유효하지만 다른 이름에 대한 것. 도메인 이전 후나 CDN이 SNI 없이 공유 인증서를 제공할 때 흔합니다.
• •불완전한 체인. 중간 인증서가 없어 일부 클라이언트가 루트까지 경로를 만들지 못합니다. 브라우저는 자주 덮어주지만 API 클라이언트와 모바일 스택은 그렇지 않습니다.
• •레거시 프로토콜이 여전히 활성. TLS 1.0/1.1을 현대 버전과 함께 제공하면 아무도 쓰지 않아도 점수를 끌어내립니다.
• •약한 암호 또는 전방 비밀성 없음. 정적 RSA 키 교환은 개인 키가 유출되면 기록된 트래픽이 복호화된다는 뜻입니다.
• •핸드셰이크 실패. 서버가 프로브 자체를 거부합니다. 엄격한 SNI 요구나 비브라우저 클라이언트를 막는 방화벽 규칙이 흔한 원인입니다.

순서대로 진단하기

먼저 인증서 문제와 구성 문제를 분리하세요. 인증서가 만료되었거나 불일치하면 고칠 때까지 다른 것은 보지 않습니다. 인증서가 정상이면 다음은 프로토콜 목록입니다. 인증서 유효성 다음으로 낮은 점수의 최대 원인입니다.

CertH의 도메인 보고서는 다섯 평가 영역 중 어디서 점수를 잃었는지, 구체적 감점과 해결책까지 보여줍니다. 전체 스캔을 손으로 읽는 것보다 대개 빠릅니다.

# What does the certificate actually cover?
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName -dates

# Which protocols does the server accept?
for v in tls1 tls1_1 tls1_2 tls1_3; do
  printf '%s: ' "$v"
  echo | openssl s_client -connect example.com:443 -$v -servername example.com 2>/dev/null | grep -q "Protocol" && echo yes || echo no
done

SNI 함정

여러 도메인을 호스팅하는 서버는 올바른 인증서를 고르기 위해 SNI가 필요합니다. 일부 구성은 SNI를 강제하고 없으면 클라이언트를 거부합니다. 브라우저에는 문제없지만 모니터링 도구, 구형 Java 클라이언트, 일부 API 라이브러리가 깨집니다. 스캐너가 핸드셰이크 실패를 보고하는데 브라우저는 정상이라면 이것부터 확인하세요.

FAQ