[{"data":1,"prerenderedAt":14},["ShallowReactive",2],{"guide-detail-20260616_ocsp_disappearing_reason":3},{"data":4,"content":13},{"id":5,"title":6,"thumbnail":7,"category":8,"subCategory":9,"date":10,"summary":11,"isFeatured":12},"20260616_ocsp_disappearing_reason","25년 동안 사용된 OCSP는 왜 사라지고 있을까?","\u002Fimages\u002Finsight\u002Fimage_20260618_141247_001.webp","기술 및 보안","","2026.06.16","SSL 인증서 폐기 여부를 확인하기 위해 오랫동안 사용되어 온 OCSP가 점차 역할을 잃어가고 있습니다. OCSP의 한계와 인증서 관리 방식의 변화를 살펴봅니다.","false","\r\n**SSL 인증서를 사용하는 이유는 웹사이트의 신뢰성을 보장**하기 위해서입니다.\r\n\r\n하지만 인증서가 발급되었다고 해서 항상 신뢰할 수 있는 것은 아닙니다. 인증서의 개인키가 유출되거나, 인증기관(CA)이 잘못된 인증서를 발급하거나, 서버가 침해되는 상황이 발생할 수 있기 때문입니다. 이러한 문제를 해결하기 위해 등장한 기술이 **OCSP(Online Certificate Status Protocol)** 입니다.\r\n\r\nOCSP는 브라우저가 인증기관에 직접 문의하여 해당 인증서가 현재도 유효한 상태인지 확인하는 방식입니다. 인증서가 폐기(Revocation)된 경우 브라우저는 이를 감지하여 접속을 차단할 수 있습니다.\r\n\r\n한때는 인터넷 인증서 생태계의 핵심 기술로 여겨졌지만, 최근 보안 업계의 흐름은 예상과 다른 방향으로 움직이고 있습니다. OCSP를 강화하는 것이 아니라, 오히려 사용을 줄이거나 대체하려는 움직임이 확산되고 있는 것입니다.\r\n\r\n> 함께 읽어보면 좋은 글  \r\n> [**SSL 인증서 유효기간이 47일까지 줄어드는 이유**](\u002Fguide\u002F20260616_ocsp_disappearing_reason)\r\n\r\n---\r\n\r\n## 인증서가 유효해도 믿을 수 없는 순간\r\n\r\n일반적으로 SSL 인증서는 유효기간이 남아 있는 동안 신뢰할 수 있는 것으로 간주됩니다. 하지만 현실에서는 **유효기간이 남아 있어도 더 이상 신뢰할 수 없는 상황**이 발생할 수 있습니다.\r\n\r\n아래와 같은 문제가 발생하면 인증서는 만료일까지 사용할 수 있도록 둘 수 없으며, 유효기간이 남아 있더라도 **즉시 신뢰를 철회하고 무효화**해야 합니다.\r\n\r\n- **인증서 개인키(Private Key) 유출**\r\n- **인증기관(CA)의 오발급**\r\n- **서버 침해 사고**\r\n- **도메인 소유권 변경**\r\n\r\n### 인증서 폐기 문제를 해결하기 위해 등장한 OCSP\r\n\r\n**OCSP(Online Certificate Status Protocol)** 는 인증서가 현재도 안전하게 사용할 수 있는 상태인지 확인하기 위해 만들어진 기술입니다. 브라우저는 웹사이트에 접속할 때 인증기관(CA)에 질의하여 해당 SSL 인증서가 정상 상태인지 확인하고, 그 결과를 바탕으로 접속 여부를 판단합니다.\r\n\r\n#### 이 인증서가 아직 믿어도 되는 상태인지를 인증기관에 직접 물어보는 방식입니다.\r\n\r\n당시에는 매우 합리적인 아이디어로 평가받았습니다. 실제로 OCSP는 25년 가까이 인터넷 보안 생태계에서 인증서 폐기(Revocation)를 확인하는 대표적인 기술로 사용되어 왔습니다.\r\n\r\n> 하지만 실제 인터넷 환경은 예상보다 훨씬 복잡했고, 시간이 지나면서 여러 구조적 한계가 드러나기 시작했습니다.\r\n\r\n---\r\n\r\n## 문제는 인증서를 확인하는 과정 그 자체\r\n\r\nOCSP는 개념적으로는 매우 합리적인 기술이었습니다. 하지만 실제 인터넷 환경에서는 인증서 상태를 확인하는 과정 자체가 새로운 문제를 만들기 시작했습니다. SSL 인증서의 상태를 확인하려면 브라우저가 웹 서버뿐 아니라 **인증기관(CA)의 OCSP 서버와도 추가로 통신**해야 하기 때문입니다.\r\n\r\n즉, 웹사이트 하나에 접속하더라도 보이지 않는 곳에서는 또 다른 연결이 발생하게 됩니다.\r\n\r\n### OCSP가 안고 있던 현실적인 문제\r\n\r\n- **HTTPS 연결 지연**\r\n- **사용자 접속 정보 노출 가능성**\r\n- **인증기관 서버 장애 영향**\r\n- **네트워크 차단 시 검증 실패**\r\n- **대규모 운영 비용 증가**\r\n\r\n특히 사용자 개인정보 측면에서도 논란이 있었습니다.\r\n\r\n브라우저가 특정 웹사이트의 인증서 상태를 확인하기 위해 인증기관 서버에 직접 접속하다 보니, 이론적으로는 사용자가 어떤 사이트에 접속했는지 추적할 수 있는 가능성이 존재했기 때문입니다.\r\n\r\n### 더 큰 문제는 '확인 실패'였습니다.\r\n\r\n만약 브라우저가 OCSP 서버에 접속할 수 없다면 어떻게 해야 할까요? 원칙대로라면 인증서 상태를 확인할 수 없으므로 접속을 차단해야 합니다. 하지만 현실에서는 네트워크 장애나 인증기관 서버 문제로 인해 정상적인 웹사이트 접속까지 차단되는 상황이 빈번하게 발생할 수 있었습니다. 결국 대부분의 브라우저는 다음과 같은 선택을 하게 됩니다.\r\n\r\n> 인증서 상태를 확인할 수 없어도 일단 접속은 허용한다.\r\n\r\n#### 이를 **Soft-fail** 방식이라고 부릅니다.\r\n\r\n문제는 인증서 폐기 여부를 확인하기 위해 만들어진 기술이 정작 확인에 실패했을 때는 그대로 통과시켜 버린다는 점입니다. 이 때문에 보안 업계에서는 오랫동안 OCSP의 실효성에 대한 의문이 제기되어 왔으며, 브라우저 업체와 인증기관들은 점차 다른 대안을 찾기 시작했습니다.\r\n\r\n---\r\n\r\n## OCSP의 한계를 보완하려는 시도\r\n\r\nOCSP의 성능 문제와 개인정보 노출 문제를 해결하기 위해 등장한 기술이 **OCSP Stapling** 입니다. 기존 방식에서는 브라우저가 인증기관(CA)에 직접 접속하여 인증서 상태를 확인해야 했습니다. 반면 OCSP Stapling은 웹 서버가 미리 인증기관으로부터 OCSP 응답을 받아 두었다가, SSL\u002FTLS 연결 과정에서 함께 전달하는 방식입니다.\r\n\r\n### 무엇이 개선되었을까?\r\n\r\n- **추가 네트워크 통신 감소**\r\n- **HTTPS 연결 성능 개선**\r\n- **사용자 접속 정보 노출 최소화**\r\n- **인증기관 서버 의존도 감소**\r\n\r\n실제로 OCSP의 대표적인 단점들을 상당 부분 보완할 수 있었습니다.\r\n\r\n### 하지만 근본적인 문제는 남아 있었습니다.\r\n\r\n문제는 OCSP Stapling 역시 결국 **OCSP를 기반으로 동작하는 기술**이라는 점입니다.  \r\n웹 서버는 계속해서 인증기관으로부터 최신 응답을 받아야 했고, 운영 환경에 따라 다양한 문제가 발생했습니다.\r\n\r\n- 서버 설정 오류\r\n- 응답 갱신 실패\r\n- 운영 복잡성 증가\r\n- 서버별 구성 차이\r\n\r\n무엇보다도 **인증서 폐기 여부를 확인하기 위한 별도의 체계 자체는 그대로 유지해야 했습니다.**\r\n\r\n> 즉, OCSP를 더 효율적으로 만드는 방법은 있었지만,  \r\n> OCSP가 가진 구조적 한계를 해결한 것은 아니었습니다.\r\n\r\n### 보안 업계는 다른 방향을 고민하기 시작했습니다.\r\n\r\n> 인증서 상태를 계속 확인하는 것이 맞을까?  \r\n> 아니면 인증서 자체를 더 짧게 사용하고 자주 교체하는 것이 맞을까?\r\n\r\n실제로 최근 SSL 인증서 유효기간 단축 정책과 단기 인증서(Short-Lived Certificate) 확대 움직임은 이러한 고민에서 출발한 변화로 볼 수 있습니다. OCSP를 개선하는 방향보다, 인증서 관리 방식을 바꾸는 방향으로 무게 중심이 이동하기 시작한 것입니다.\r\n\r\n---\r\n\r\n## Let's Encrypt가 OCSP 지원 종료를 결정한 이유\r\n\r\n이러한 흐름은 2025년 더욱 분명해져서 세계 최대 인증기관인 \u003Cstrong>Let's Encrypt는 OCSP 지원 종료 계획을 발표\u003C\u002Fstrong>했습니다.\r\n\r\n공개된 자료에 따르면 Let's Encrypt는 하루 약 120억 건에 달하는 OCSP 요청을 처리하고 있었지만, 운영 비용에 비해 실질적인 보안 효과는 제한적이라고 판단했습니다. 이 결정은 비용 절감 차원의 문제가 아닙니다.\r\n\r\nGoogle Chrome은 오래전부터 자체적인 인증서 차단 목록 체계를 운영하고 있으며, Mozilla 역시 CRLite와 같은 대체 방식을 도입해 왔습니다.\r\n\r\n#### 즉, 업계 전체가 OCSP 중심 구조에서 벗어나고 있는 것입니다.\r\n\r\n---\r\n\r\n## 실제 운영 환경에서는 어떤 변화가 생길까?\r\n\r\nOCSP 축소와 SSL 인증서 정책 변화는 브라우저 업체나 인증기관만의 이야기가 아닙니다. 실제 서비스를 운영하는 조직에서는 인증서 관리 방식 자체를 다시 점검해야 하는 시점이 다가오고 있습니다.\r\n\r\n공공기관과 교육기관에서는 다음과 같은 운영 환경을 자주 접할 수 있습니다.\r\n\r\n| 운영 환경 | 고려해야 할 사항 |\r\n|:---:|:---:|\r\n| 대민 서비스 | 인증서 만료 시 서비스 중단 위험 |\r\n| 내부 업무 시스템 | 인증서 현황 관리 필요 |\r\n| 폐쇄망 환경 | 자동 갱신 방식 검토 필요 |\r\n| 다수의 웹 서비스 운영 | 인증서 통합 관리 필요 |\r\n\r\n> **리프아이티가 구축, 운영하는 e-Book 시스템 역시 대부분 SSL 인증서를 기반으로 서비스**되고 있습니다.\r\n\r\n특히 외부 인터넷 접근이 제한된 환경에서는 인증서 갱신 절차와 관리 체계가 운영 안정성에 직접적인 영향을 줄 수 있습니다. 지금까지는 인증서를 발급받고 보관하는 것이 중요했다면, 앞으로는 **어떻게 관리하고 갱신할 것인가**가 더 중요한 운영 과제가 될 가능성이 높습니다.\r\n\r\n---\r\n\r\n## 바뀌고 있는 인증서 관리 방식\r\n\r\n최근 SSL 인증서 유효기간 단축, OCSP 축소, 인증서 자동화 확대는 모두 같은 방향을 가리키고 있습니다. **인증서를 발급**하는 것보다 **관리하는 과정의 중요성**이 점점 커지고 있다는 점입니다. 특히 앞으로는 다음과 같은 항목이 운영 안정성에 직접적인 영향을 줄 수 있습니다.\r\n\r\n- **인증서 현황 관리**\r\n- **만료일 모니터링**\r\n- **자동 갱신 체계**\r\n- **장애 대응 절차**\r\n\r\n과거에는 인증서를 발급한 뒤 일정 기간 유지하는 것이 일반적인 운영 방식이었습니다.\r\n\r\n반면 최근 보안 업계는 짧은 수명의 인증서와 자동화된 관리 체계를 중심으로 빠르게 변화하고 있습니다. OCSP가 역할을 줄여가고 있는 이유도 같은 흐름 속에서 이해할 수 있습니다.\r\n\r\n인터넷 보안은 인증서 상태를 반복적으로 확인하는 구조에서, **인증서를 자동으로 발급하고 관리하는 구조**로 이동하고 있습니다.\r\n\r\n> *함께 읽어보면 좋은 글* : OCSP 축소와 단기 인증서 확산은 같은 흐름 속에서 이해할 수 있습니다.  \r\n> [**SSL 인증서 유효기간이 47일까지 줄어드는 이유**](\u002Fguide\u002F20260612_ssl_certificate_47_day_validity)\r\n\r\n\r\n---\r\n\r\n**Keywords**  \r\n`OCSP`, `OCSP Stapling`, `인증서 폐기`, `Revocation`, `Let's Encrypt`, `SSL 인증서`, `TLS 인증서`, `PKI`, `인증서 관리`, `인증서 자동 갱신`, `SSL 인증서 관리`, `웹 보안`, `정보보안`, `공공기관 보안`, `리프아이티`\r\n\r\n---\r\n\r\n* [공공기관·교육기관 정보시스템 구축 사례 살펴보기](\u002Flibrary)\r\n* [안정적인 웹 서비스 운영을 위한 플랫폼 구축 방법 알아보기](\u002Fsolution)\r\n* [시스템 구축 및 운영 관련 기술 상담 문의하기](\u002Fcontact-us)\r\n\r\n---\r\n**작성자 :** (주)리프아이티 ICT사업본부",1781759641845]