SSL 스캐너가 OCSP 스테이플링이 비활성이라고 합니다. 꼭 고쳐야 하는 문제인가요?

대개 아니고, 2026년에는 고치고 싶어도 못 고치는 경우가 많습니다. OCSP 스테이플링은 인증서에 OCSP 응답자 URL이 들어 있어야만 동작하는데, 웹에서 가장 큰 CA인 Let's Encrypt가 그 URL을 빼 버렸습니다. 2025년 5월 7일부터 새로 발급하는 인증서에서 OCSP URL을 제거했고, 2025년 8월 6일에는 OCSP 응답자를 완전히 내리고 CRL로 옮겼습니다. 그 이후 발급된 Let's Encrypt 인증서에는 스테이플할 대상이 없으므로 'OCSP 스테이플링 비활성'은 설정 실수가 아니라 현실을 정확히 묘사한 것입니다. 브라우저는 이미 OCSP를 소프트페일 처리하고 의존하지 않아서, 스테이플이 없다고 사이트가 취약해지지 않습니다. 먼저 어느 CA가 인증서를 발급했고 OCSP URL이 있기나 한지 확인하세요 — 그래야 비로소 스테이플링을 켜는 게 실제 과제가 됩니다.

nginx에서 ssl_stapling을 켰는데도 검사에 여전히 꺼졌다고 나옵니다. 왜죠?

흔한 원인이 셋입니다. 첫째, 인증서에 OCSP URL이 없을 수 있습니다(위 설명 참고) — 이때 nginx는 '인증서에 OCSP 응답자 URL이 없다'는 경고를 로그에 남기고 스테이플할 것을 내보내지 않습니다. 둘째, nginx는 OCSP 응답을 지연 방식으로 가져옵니다. 리로드 직후 첫 핸드셰이크들은 백그라운드로 응답을 받아오기 전이라 스테이플이 없어서, 리로드 1초 뒤 테스트하면 설정이 맞아도 '비활성'으로 보입니다 — 1분쯤 뒤 다시 테스트하세요. 셋째, nginx는 ssl_trusted_certificate가 전체 체인(발급 중간 인증서 포함)을 가리키고 응답자에 닿을 resolver 줄이 있어야 합니다. 둘 중 하나라도 없으면 검증이 조용히 실패하고 아무것도 스테이플되지 않습니다.

강제하려면 OCSP Must-Staple을 켜야 하나요?

거의 틀림없이 아닙니다, 특히 지금은요. Must-Staple(RFC 7633)은 스테이플된 OCSP 응답이 없으면 브라우저가 연결을 하드페일하도록 지시하는 인증서 플래그입니다. 소프트페일 구멍을 막긴 하지만, CA의 응답자를 하드 의존성으로 만듭니다. 응답자 장애든, 캐시된 응답 만료든, 가져오기 실패든 — 어떤 이유로든 스테이플이 빠지면 사이트가 '저하'가 아니라 '다운'됩니다. 주요 CA들이 OCSP를 적극 폐기하는 와중에, 사라질 수도 있는 응답에 스스로를 묶는 건 제 사이트를 내리는 확실한 방법입니다. 확실히 이해한 특별한 이유와 완전히 신뢰하는 자동화가 있지 않다면 Must-Staple은 꺼 두세요.

OCSP 스테이플링 비활성? 필요한지부터 확인

문제

스캐너나 감사 체크리스트, SSL 등급 도구가 당신 사이트에 대해 OCSP 스테이플링: 비활성이라고 보고하고, 당신은 이게 진짜 문제인지 잡음인지 — 진짜라면 어떻게 켜고 실제로 동작하는지 확인하는지 — 를 판단하려 합니다.

증상

SSL/TLS 리포트가 OCSP 스테이플링을 꺼짐·없음·“스테이플 안 됨”으로 표시합니다.
openssl s_client -connect yourdomain:443 -status가 OCSP response: no response sent을 돌려줍니다.
nginx에 ssl_stapling on;을 추가했는데도 상태가 여전히 꺼짐으로 보고됩니다.
사이트는 멀쩡히 되는데 컴플라이언스 검사가 스테이플 누락을 지적합니다.

먼저, 스테이플할 것이 있기는 한지 확인하라

OCSP 스테이플링은 TLS 확장(Certificate Status Request, RFC 6066)으로, 서버가 CA로부터 자기 폐기 증명을 직접 가져와 핸드셰이크에 붙이는 — ‘스테이플’하는 — 기능입니다. 제대로 되면 방문자는 CA로 우회하지 않고도 신선도 증명을 받고, CA는 방문자의 IP를 보지 못합니다. 좋은 생각입니다. 단, 인증서가 Authority Information Access 필드에서 CA의 OCSP 응답자가 어디인지 알려 줘야만 동작합니다. 인증서에 OCSP URL이 없으면 스테이플할 것도 없습니다.

그리고 바로 여기서 2026년이 답을 바꿉니다. 업계는 OCSP를 폐기하는 중입니다. 2023년 8월, CA/Browser Forum은 인증 기관의 OCSP 지원을 선택 사항으로 바꾸고 CRL을 의무로 만들었습니다. 그러자 웹 최대 CA가 그것을 실행에 옮겼습니다. Let’s Encrypt는 2025년 5월 7일 새 인증서에서 OCSP URL을 제거했고, 2025년 8월 6일에는 OCSP 응답자를 완전히 내린 뒤 CRL에 의존합니다. 당신 인증서가 Let’s Encrypt 발급이고 2025년 봄 이후 나온 것이라면 OCSP 응답자 URL이 없습니다 — 그러니 ‘OCSP 스테이플링 비활성’은 그냥 사실이고, nginx를 아무리 손봐도 바뀌지 않습니다. 가져올 게 없으니까요.

그래서 첫 진단 단계는 설정 파일을 여는 게 아닙니다. 누가 인증서를 발급했는지 보는 것입니다. Let’s Encrypt(또는 OCSP를 중단한 어떤 CA)라면 스테이플링은 설계상 사라진 것이고, 브라우저는 이미 의존하지 않으니, 그 지적은 ‘해당 없음’으로 닫아도 됩니다. 아직 OCSP 응답자를 운영하는 상용 CA라면, 스테이플링은 — 작지만 — 제대로 켤 가치가 있는 개선입니다.

주요 원인 3가지

인증서에 OCSP URL이 없다. 가장 흔하게는 2025년 5월 전환 이후 발급된 Let’s Encrypt 인증서. 질의할 응답자가 없어 스테이플링이 일어날 수 없습니다. 이건 결함이 아니라 예상된 상태입니다.
스테이플링이 설정되지 않았거나 불완전하다. CA는 아직 OCSP를 운영하는데, 서버가 스테이플링을 켜지 않았거나, 전체 체인(ssl_trusted_certificate)과 동작하는 DNS resolver 줄 없이 켜 둬서 검증이 실패하고 아무것도 서빙되지 않습니다.
리로드 직후에 너무 빨리 테스트했다. nginx는 OCSP 응답을 백그라운드에서 지연 방식으로 가져옵니다. 재시작·리로드 직후 첫 핸드셰이크들에는 캐시된 응답이 없어 설정이 맞아도 ‘비활성’으로 보고됩니다. 실트래픽 1~2분이면 채워집니다.

DechoNet으로 진단

SSL 점검은 발급 CA와 인증서 체인을 보여 줘서, 당신 인증서가 Let’s Encrypt(스테이플링 폐기)에서 왔는지 아직 OCSP를 운영하는 CA에서 왔는지 바로 알 수 있습니다 — 이게 애초에 설정 과제인지 아닌지를 결정합니다.
HTTP 점검은 당신이 생각하는 호스트에서 HTTPS로 서빙되는지 확인해 줘서, 캐시나 다른 vhost 뒤의 옛 인증서가 아니라 실제로 살아 있는 인증서를 테스트하게 해 줍니다.

해결 체크리스트

SSL 점검을 돌려 발급자부터 읽으세요. Let’s Encrypt(또는 OCSP를 중단한 다른 CA)라면 여기서 멈추세요 — 스테이플할 것이 없고 지적은 해당 없음입니다.
CA가 아직 OCSP를 운영하고 스테이플링을 원한다면, nginx에서 ssl_stapling on;과 ssl_stapling_verify on;을 설정하고, ssl_trusted_certificate를 전체 체인 파일(인증서+중간 인증서)로 가리키고, resolver 줄(예: resolver 1.1.1.1 8.8.8.8 valid=300s;)을 넣어 응답자에 닿게 한 뒤 리로드하세요.
Apache에서는 서버 수준에서 SSLUseStapling on과 SSLStaplingCache(예: SSLStaplingCache "shmcb:logs/ssl_stapling(32768)")를 설정하고 리로드하세요.
서버가 첫 OCSP 응답을 가져와 캐시할 수 있도록 1분쯤 기다린 뒤, openssl s_client -connect yourdomain:443 -status로 검증하고 OCSP Response Status: successful과 Cert Status: good을 확인하세요.
Must-Staple은 꺼 두세요. 선택적 점검을, CA가 폐기할지도 모르는 응답자에 대한 하드 의존성으로 바꾸는 건 자초하는 장애입니다.

에스컬레이션 시점 (또는 넘어가기)

인증서가 OCSP 응답자 없는 CA에서 온 것이라면, 이건 끝난 일입니다. 지적이 낡은 것이고, 올바른 조치는 서버가 아니라 스캐너의 기대치를 고치는 것입니다. 그런 인증서의 폐기는 브라우저가 스스로 받아가는 CRL로 처리됩니다.
스테이플링이 살아 있는 응답자에 대해 올바르게 설정됐는데도 몇 분의 트래픽 뒤에도 openssl ... -status가 아무것도 돌려주지 않으면, ssl_trusted_certificate 체인이 완전한지, 서버가 자기 네트워크에서 응답자 호스트명을 실제로 해석하고 닿을 수 있는지 확인하세요 — CA로의 아웃바운드 HTTP를 막는 이그레스 방화벽이 흔하고 조용한 원인입니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.