A+ SSL 등급 받는 방법 (2026 체크리스트)

무엇이 실제로 등급을 결정하는가

CertH는 순수 TLS 핸드셰이크 한 번만으로 다섯 개의 가중 영역을 채점합니다. 인증서 유효성과 체인, 키 강도와 서명 알고리즘, 제공하는 프로토콜 버전, 협상된 암호 스위트, 그리고 HSTS와 OCSP 스테이플링입니다. 서버 접근도, 에이전트도, 구성 파일 업로드도 없습니다. 모든 것은 브라우저가 보는 것과 똑같이 외부에서 관찰합니다.

임계값은 단순합니다. A+는 점수 95 이상, 협상된 프로토콜 목록에 TLS 1.3, 그리고 HSTS가 preload 되었거나 max-age가 최소 180일이어야 합니다. A는 90부터, B는 80, C는 70, D는 55이며 55 미만은 F입니다. 인증서 만료는 자동으로 0점입니다.

A에서 A+로 올리는 네 가지 변경

실제로 격차는 거의 항상 이 네 가지 중 하나입니다. 순서대로 고치세요. 각각 외부에서 독립적으로 검증할 수 있으므로 단계마다 다시 스캔할 수 있습니다.

• •TLS 1.3 활성화. 그 자체로 점수가 되고, 나머지가 모두 100점이어도 A+에는 필수입니다.
• •HSTS를 최소 max-age=15552000(180일)로 올리기. 1년(31536000)이 일반적인 선택입니다.
• •중간 인증서를 포함한 완전한 체인 제공. 중간 인증서가 없으면 일부 클라이언트에서 체인 오류로 나타나고 점수가 깎입니다.
• •OCSP 스테이플링 활성화. 폐기 확인이 핸드셰이크와 함께 전달되어 방문자 IP가 CA에 노출되지 않습니다.

A+를 받는 nginx 구성

최신 nginx(1.19 이상, OpenSSL 1.1.1 이상)용 완전한 server 블록 조각입니다. nginx가 더 오래된 OpenSSL로 빌드되었다면 여기에 무엇을 쓰든 TLS 1.3은 조용히 사용할 수 없습니다. 먼저 nginx -V로 확인하세요.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

A+를 받는 Apache 구성

Apache는 스테이플링 캐시를 가상 호스트 안이 아니라 서버 수준에서 한 번 선언해야 합니다. 나머지는 <VirtualHost *:443> 블록에 넣습니다.

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

SSLUseStapling on
SSLStaplingCache "shmcb:logs/ssl_stapling(32768)"

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

사이트를 A에 묶어두는 실수들

가장 흔한 것: 아직 HTTP만 쓰는 서브도메인이 있는 도메인에 includeSubDomains가 붙은 HSTS를 켜는 경우입니다. 그 서브도메인은 즉시 열리지 않고, 보통의 반응은 헤더를 통째로 지우는 것이며 그러면 다시 A로 돌아갑니다. HSTS는 단계적으로 배포하세요. 먼저 max-age 300초로 시작해 일주일 관찰한 뒤 1년까지 올립니다.

두 번째로 흔한 실수는 인증서가 최신이면 TLS 1.3도 켜져 있다고 가정하는 것입니다. 인증서와 프로토콜 버전은 별개입니다. TLS 1.2만 말하는 서버에 새 인증서를 붙여도 점수는 95 미만입니다.

세 번째는 원본 서버 앞의 CDN입니다. Cloudflare, Fastly 또는 로드밸런서가 TLS를 종료하면 원본 구성은 무의미합니다. 등급은 엣지를 반영하므로 설정은 그쪽에서 바꿔야 합니다.

직접 확인하기

각 변경은 터미널에서 몇 초면 확인됩니다. TLS 1.3은 서버가 실제로 제공할 때만 협상되고, HSTS는 응답 헤더에 나타나며, 스테이플링은 OCSP 응답 블록에 드러납니다.

# Does the server actually negotiate TLS 1.3?
openssl s_client -connect example.com:443 -tls1_3 -servername example.com </dev/null 2>/dev/null | grep "Protocol"

# Is HSTS set, and for how long?
curl -sI https://example.com | grep -i strict-transport-security

# Is OCSP stapling actually working?
openssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | grep -A2 "OCSP Response"

FAQ