맨위로가기

온라인 인증서 상태 프로토콜

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
목차

1. 개요

온라인 인증서 상태 프로토콜(OCSP)은 X.509 디지털 인증서의 유효성을 확인하는 데 사용되는 프로토콜로, 인증서 폐지 목록(CRL)보다 더 효율적인 방법으로 여겨진다. OCSP는 CRL보다 적은 데이터를 사용하고, 인증서 폐지 상태를 더 시의적절하게 제공할 수 있지만, 클라이언트가 OCSP 응답자에게 유효성 확인을 요청해야 하므로 개인 정보 보호 문제가 발생할 수 있다. OCSP는 재생 공격 및 중간자 공격에 취약하며, 이러한 취약점을 해결하기 위해 OCSP 스테이플링과 같은 기술이 사용된다. 주요 웹 브라우저는 OCSP를 지원하며, 다양한 오픈 소스 및 상용 소프트웨어에서 OCSP 서버 및 라이브러리를 구현하고 있다.

더 읽어볼만한 페이지

  • 공개 키 기반 구조 - 코드 서명
    코드 서명은 코드의 출처와 무결성을 보장하기 위해 공개 키와 개인 키 쌍을 사용하여 코드를 서명하는 기술이며, 소프트웨어 보안 강화 및 출처 확인에 유용하다.
  • 공개 키 기반 구조 - 루트 인증서
    루트 인증서는 공개 키 기반 구조에서 디지털 인증서의 유효성을 검증하는 최상위 인증서로서, 웹 브라우저와 운영체제가 신뢰하는 목록을 관리하지만, 보안 침해 사례로 인해 사용자들의 적극적인 보안 조치가 필요하다.
  • 공개 키 암호 - 공개 키 기반 구조
    공개 키 기반 구조(PKI)는 공개 키 암호화를 기반으로 안전한 통신과 개체 식별을 가능하게 하는 기술로서, 디지털 인증서를 통해 공개 키를 특정 개체에 연결하고 인증서를 관리하며, 인증 기관(CA), 등록 기관(RA) 등 다양한 구성 요소로 이루어져 인증서 발급, 관리, 배포, 사용 및 폐기와 관련된 역할, 정책, 하드웨어, 소프트웨어 및 절차의 집합을 포함한다.
  • 공개 키 암호 - DNSSEC
    DNSSEC는 DNS의 보안 취약점을 개선하기 위해 도메인 정보에 디지털 서명을 추가하여 응답 레코드의 무결성을 보장하고 DNS 위장 공격을 막는 기술로, RRSIG, DNSKEY 등 다양한 리소스 레코드 유형을 사용하여 인증 체인을 구성하며 공개 키 암호 방식을 활용한다.
  • 암호 프로토콜 - HTTPS
    HTTPS는 HTTP에 보안 기능이 더해진 통신 규약으로, 웹 브라우저와 서버 간 통신을 암호화하여 보안을 강화하지만, 인증서 비용, 서버 부하, 혼합 콘텐츠 문제 등의 단점도 존재한다.
  • 암호 프로토콜 - IPsec
    IPsec은 IP 네트워크에서 보안 통신을 제공하기 위한 프로토콜 스위트로서, 전송 모드와 터널 모드를 지원하며, AH, ESP 등의 프로토콜을 사용하여 데이터 무결성, 인증, 기밀성을 제공하고, IKE 프로토콜을 통해 보안 연결을 설정 및 키를 교환하는 개방형 표준이다.
온라인 인증서 상태 프로토콜
일반 정보
명칭온라인 인증서 상태 프로토콜
영어 명칭Online Certificate Status Protocol
약자OCSP
설명통신 프로토콜
상세 정보
도메인디지털 인증서
웹사이트RFC 6960: OCSP
RFC 8954: OCSP Nonce Extension
RFC 9654: OCSP Nonce Extension Enhancements
기반 표준URI
보안/다목적 인터넷 메일 확장
개발
상태제안된 표준
시작 연도2002년 2월 4일
최초 게시일2013년 2월 11일
저자스테판 산테손
마이클 마이어스
리치 앙크니
암바리시 말파니
슬라바 갈페린
칼라일 아담스
모히트 사니
히만슈 샤르마

2. 인증서 폐지 목록 (CRL)과의 비교

OCSP와 인증서 폐지 목록(CRL)은 모두 X.509 디지털 인증서의 유효성을 확인하는 데 사용되지만, 작동 방식과 특징에서 몇 가지 중요한 차이가 있다.

OCSP는 특정 인증서의 상태만을 확인하여 응답하므로, 전체 폐지 목록을 담고 있는 CRL에 비해 응답 데이터의 크기가 작다.[10] 이는 네트워크 트래픽과 클라이언트의 리소스 부담을 줄일 수 있는 장점으로 이어진다. 또한, 처리해야 할 데이터가 적어 클라이언트 측 라이브러리 구현이 상대적으로 단순해질 수 있다.[11]

반면, CRL은 주기적으로 업데이트되는 전체 목록을 다운로드하여 확인하는 방식이다. 이는 마치 신용 카드 회사의 "악질 고객 리스트"처럼, 필요 이상의 정보가 포함될 수 있다는 비유도 있다.

실시간성 측면에서 OCSP는 요청 시점의 최신 상태를 제공하여 CRL보다 유리할 수 있다. CRL은 배포 주기에 따라 정보가 지연될 수 있기 때문이다. 그러나 클라이언트가 OCSP 응답을 캐시하지 않으면 잦은 요청으로 인해 실시간성의 이점이 상쇄되고 서버 부하가 증가할 수 있다.

보안 측면에서는 OCSP 사용 시 클라이언트의 특정 인증서 조회 기록이 OCSP 응답자에게 노출될 수 있으며, 통신 과정이 기본적으로 암호화되지 않아 제3자에 의해 정보가 가로채기 당할 위험이 있다.[2] CRL은 전체 목록을 다운로드하므로 개별 조회 기록 노출 위험은 상대적으로 적다.

OCSP가 CRL 파싱의 필요성을 없애 클라이언트 측의 복잡성을 줄일 수 있다는 장점도 있지만, 실제 환경에서는 캐시 관리의 필요성이 생기고 대부분의 애플리케이션이 서드파티 라이브러리를 사용하기 때문에 그 효과는 크지 않을 수 있다.

2. 1. 장점


  • 효율성: OCSP 응답은 일반적인 인증서 폐지 목록(CRL)보다 적은 데이터를 포함하므로 네트워크 및 클라이언트 리소스에 부담을 덜 준다.[10]
  • 간단한 처리: OCSP 응답은 파싱해야 할 데이터가 적으므로, 이를 처리하는 클라이언트 측 라이브러리는 CRL을 처리하는 라이브러리보다 덜 복잡할 수 있다.[11] 또한 클라이언트가 CRL을 직접 구문 분석할 필요가 없어 클라이언트 측의 복잡성이 감소된다.
  • 실시간 확인: OCSP는 전형적인 CRL보다 인증서의 폐지 상태를 더 시의적절하게 제공할 수 있다. 그러나 클라이언트가 응답을 캐시하지 않으면, 요청 횟수가 증가하여 이 장점이 상쇄될 가능성도 있다.

2. 2. 단점


  • '''개인 정보 노출 위험''': 클라이언트가 특정 인증서의 유효성을 확인하기 위해 OCSP 응답자에게 요청을 보낼 때, 특정 사용자가 특정 시간에 어떤 웹사이트(인증서)에 접속했는지 정보가 OCSP 응답자에게 노출될 수 있다. 이는 사용자의 개인 정보가 의도치 않게 수집될 가능성을 의미한다.
  • '''정보 가로채기 가능성''': OCSP 통신은 기본적으로 암호화를 강제하지 않으므로, 네트워크 상에서 제3자가 OCSP 요청 및 응답 내용을 가로챌 수 있다. 이는 사용자의 웹 서핑 기록 등 민감한 정보 유출 위험을 내포하며, 중간자 공격 등에 악용될 수 있다.
  • '''효율성 문제''': OCSP 응답은 CRL보다 최신 상태를 반영할 수 있지만, 클라이언트가 응답 결과를 캐시하지 않으면 매번 요청을 보내야 하므로 서버 부하 증가 및 응답 속도 저하로 OCSP의 시의적절성이라는 장점이 상쇄될 수 있다. 또한, OCSP가 CRL 구문 분석의 필요성을 없애 클라이언트 측 복잡성을 줄일 수 있다는 주장도 있으나, 실제로는 대부분의 애플리케이션이 서드파티 라이브러리를 사용하므로 이점은 크지 않으며, 캐시 관리의 복잡성도 고려해야 한다.

3. 기본 작동 방식

온라인 인증서 상태 프로토콜(OCSP)은 공개 키 인증서의 유효성을 실시간으로 확인하는 방식이다. 기본적인 작동 과정은 사용자와 검증자, 그리고 인증 기관(CA) 또는 OCSP 응답자 간의 상호작용으로 이루어진다.

1. 인증서 사용자는 자신의 공개 키 인증서를 상대방(검증자)에게 제시한다.

2. 검증자는 해당 인증서가 여전히 유효한지 확인하기 위해, 인증서의 고유 정보(예: 일련번호 또는 공개 키의 메시지 다이제스트)를 담은 OCSP 요청을 생성한다.

3. 이 요청은 인증서를 발급한 인증 기관(CA) 또는 해당 기관이 지정한 OCSP 응답자에게 전송된다.

4. OCSP 응답자는 요청받은 인증서 정보를 바탕으로 CA 데이터베이스를 조회하여 인증서의 현재 상태(유효, 폐지됨, 알 수 없음)를 확인한다. CA 데이터베이스는 인증서 상태에 대한 가장 신뢰할 수 있는 정보를 가진다.

5. OCSP 응답자는 확인된 상태 정보와 함께 디지털 서명된 OCSP 응답을 생성하여 검증자에게 반환한다.

6. 검증자는 미리 확보한 OCSP 응답자의 공개 키를 사용하여 응답의 디지털 서명을 검증하고, 응답의 최신성을 확인한다.

7. 응답이 유효하고 인증서 상태가 '유효'로 확인되면, 검증자는 인증서 사용자와의 거래나 통신을 안전하게 진행할 수 있다.

3. 1. PKI (공개 키 기반 구조) 구현 예시

=== 캐롤 CA를 이용한 예시 ===

# 앨리스와 밥은 인증 기관(CA)인 캐롤이 발급한 공개 키 인증서를 가지고 있다.

# 앨리스는 밥과 거래를 하기 위해 자신의 공개 키 인증서를 밥에게 전송한다.

# 밥은 앨리스의 개인 키가 유출되었을 가능성을 염두에 두고, 앨리스 인증서의 일련 번호가 담긴 OCSP 요청을 생성하여 캐롤에게 보낸다.

# 캐롤의 OCSP 응답자는 밥의 요청에 포함된 인증서 일련 번호를 확인한다. 이 번호를 이용해 캐롤이 관리하는 CA 데이터베이스에서 앨리스 인증서의 폐지 상태를 조회한다. 이 CA 데이터베이스는 앨리스 인증서의 유효 상태를 확인할 수 있는 유일하고 신뢰할 수 있는 정보원이다.

# 캐롤의 OCSP 응답자는 앨리스의 인증서가 여전히 유효하다는 것을 확인한 후, 디지털 서명으로 서명된 성공적인 'OCSP 응답'을 밥에게 반환한다.

# 밥은 미리 확보해 둔 캐롤의 공개 키를 사용하여 캐롤이 보낸 응답의 서명을 암호학적으로 검증한다.

# 검증이 완료되면 밥은 앨리스와의 거래를 진행한다.

=== 이반 CA를 이용한 예시 ===

# 앨리스와 밥은 인증 기관(CA)인 이반이 발급한 공개 키 인증서를 가지고 있다.

# 앨리스는 밥과 거래를 원하여 자신의 공개 키 인증서를 밥에게 보낸다.

# 밥은 앨리스의 개인 키가 폐지되었는지 확인하고자, 앨리스 공개 키의 메시지 다이제스트를 포함한 OCSP 요청을 생성하여 이반에게 전송한다.

# OCSP 응답자인 이반은 CA 데이터베이스를 참조하여 앨리스 인증서의 폐지 상태를 확인한다. CA 데이터베이스는 해당 인증서의 상태에 대한 유일한 신뢰 기관이다.

# 이반은 앨리스 인증서의 유효성을 확인한 뒤, 디지털 서명이 포함된 OCSP 응답을 밥에게 반환한다.

# 밥은 (신뢰할 수 있는 응답자인) 이반의 공개 키를 이용해 응답의 서명을 검증하고, 응답 정보가 최신인지 확인한다.

# 확인 후 밥은 앨리스와의 거래를 실행한다.

4. 프로토콜 상세 정보

OCSP 응답자(일반적으로 인증서 발급자가 운영하는 서버)는 요청에 지정된 인증서가 '유효', '폐지', 또는 '알 수 없음' 상태임을 나타내는 서명된 응답을 반환할 수 있다. 요청을 처리할 수 없는 경우에는 오류 코드를 반환할 수도 있다.

OCSP 응답은 일반적인 인증서 폐지 목록(CRL)보다 적은 데이터를 포함하므로 네트워크 및 클라이언트 리소스 부담을 덜 준다.[10] 또한, OCSP 응답은 파싱해야 할 데이터가 적어, 이를 처리하는 클라이언트 측 라이브러리는 CRL 처리 라이브러리보다 덜 복잡할 수 있다.[11]

반면, OCSP는 응답자에게 특정 네트워크 호스트가 특정 시간에 특정 인증서를 사용했음을 알리게 된다. OCSP는 암호화를 의무화하지 않으므로, 제3자가 이 정보를 가로챌 수 있는 프라이버시 문제가 있다.[2]

4. 1. 추가 기능

OCSP 요청 형식은 특정 PKI(Public Key Infrastructure) 구성에 맞게 사용자 정의를 가능하게 하는 확장 기능을 지원한다.

OCSP는 여러 수준의 인증 기관(CA, Certificate Authority)을 지원할 수 있다. OCSP 요청은 대상 인증서 발급에 적합한 CA를 찾기 위해 여러 OCSP 응답자 서버 간에 연쇄적으로 전달될 수 있다(chaining). 또한, 응답자들은 루트 CA에 대해 서로의 응답을 각자의 OCSP 요청을 통해 검증하며 상호 유효성을 확보할 수 있다.

OCSP 응답자는 위임된 경로 유효성 검사(DPV, Delegated Path Validation) 서버로부터 인증서 폐지 상태에 대한 정보를 질의받을 수 있다. 그러나 OCSP 자체가 제공된 인증서에 대해 직접 DPV를 수행하지는 않는다.

응답 메시지에 서명하는 데 사용되는 키는 해당 인증서를 발급(서명)한 CA의 키와 반드시 같을 필요는 없다. 인증서 발급 기관은 다른 기관에게 OCSP 응답자 역할을 수행하도록 권한을 위임할 수 있다. 이 경우, 위임받은 응답자의 인증서(응답 서명에 사용되는 인증서)는 해당 권한을 위임한 CA가 발급해야 하며, 인증서 내에는 OCSP 서명 권한이 있음을 명시하는 특정 확장 키 사용 확장이 포함되어야 한다. 구체적으로는 OID(Object Identifier) 값이 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) keyPurpose(3) ocspSigning(9)}인 확장이 필요하다.

한편, OCSP는 재생 공격(Replay Attack)에 취약할 수 있다.[12] 재생 공격은 악의적인 공격자가 과거에 유효했던 OCSP 응답(예: '유효' 상태 응답)을 가로채 저장해 두었다가, 해당 인증서가 실제로 폐지된 이후 시점에 클라이언트에게 다시 전송하여 속이는 방식이다. OCSP 표준은 이러한 공격을 막기 위해 요청 시 논스(nonce, 임의의 일회성 값)를 포함하고, 응답에도 동일한 논스를 포함하도록 하는 기능을 제공한다. 하지만 실제 운영 환경에서는 서버 부하를 줄이기 위해 많은 OCSP 응답자들이 미리 서명된 응답을 일정 기간(예: 며칠) 동안 재사용하는 경우가 많으며, 이 경우 논스 기능이 효과적으로 활용되지 못한다. 따라서 재생 공격은 OCSP 시스템의 잠재적인 보안 위협으로 남아있다.

4. 2. 보안 고려 사항

OCSP는 재생 공격에 취약할 수 있다.[12] 재생 공격이란, 악의적인 공격자가 이전에 유효했던 OCSP 응답(예: '유효' 상태 응답)을 가로챈 뒤, 해당 인증서가 실제로 폐지된 이후에 다른 사용자에게 다시 보내는 방식의 공격이다. 이를 방지하기 위해 OCSP 요청 시 논스(Nonce, 한 번만 사용되는 임의의 숫자)를 포함하여 응답에도 동일한 논스가 포함되도록 할 수 있다. 하지만 서버 부하를 줄이기 위해 많은 OCSP 응답 서버는 매번 새로운 응답을 생성하는 대신, 며칠간 유효한, 미리 서명된 응답을 재사용하는 경우가 많다. 이 때문에 논스를 사용하지 않는 환경에서는 재생 공격이 여전히 보안상 위협이 될 수 있다.

또한 OCSP는 여러 단계의 인증 기관(CA) 구조를 지원한다. OCSP 요청은 해당 인증서를 발급한 올바른 CA를 찾기 위해 여러 OCSP 응답 서버를 거쳐 연쇄적으로(chaining) 전달될 수 있다. 이 과정에서 응답 서버들은 루트 CA에 대해 서로의 응답을 검증하기도 한다.

5. 개인 정보 보호 문제

OCSP 검사는 클라이언트가 인증서 유효성을 확인하기 위해 제3자에게 연락해야 하므로 일부 사용자에게 개인 정보 보호 문제를 일으킬 수 있다. 비록 이 제3자가 클라이언트 소프트웨어 공급업체가 신뢰하는 당사자일지라도, 사용자의 접속 정보가 노출될 가능성이 있다.[2]

5. 1. 해결 방안

OCSP 검사는 클라이언트가 인증서 유효성을 확인하기 위해 제3자(비록 클라이언트 소프트웨어 공급업체가 신뢰하는 당사자)에게 연락해야 하므로, 일부 사용자에게 개인 정보 보호 문제를 야기할 수 있다. OCSP 스테이플링은 인증 기관(CA)에 브라우징 행위를 노출하지 않고 유효성을 검증하는 방법이다.[2]

6. 비판

OCSP 기반 해지 방식은 HTTPS 서버의 개인 키가 유출되었을 때 중간자 공격에 취약하다는 한계가 있다. 공격자가 네트워크 중간에서 OCSP 요청을 방해할 수 있으며, 많은 클라이언트는 응답 지연 시 확인 절차를 건너뛰기 때문에 키 유출 문제에 대한 신뢰성 있는 대응책이 되기 어렵다.[13] 이러한 문제는 인증서의 MustStaple TLS 확장이나 OCSP 스테이플링을 통해 일부 완화될 수 있다.[10] 다만, OCSP는 공격자가 "중간자" 위치에 있지 않은 상황, 예를 들어 코드 서명 인증서나 오류로 잘못 발급된 인증서를 처리하는 데에는 여전히 유효한 방어 수단이 될 수 있다.

또한, OCSP 프로토콜은 요청자가 OCSP 응답 서버에 네트워크를 통해 접근할 수 있다고 가정한다. 하지만 실제로는 로컬 네트워크 정책(예: 데이터 센터 내부망) 때문에 직접적인 인터넷 접근이 차단되어 OCSP 서버에 연결하지 못하는 경우가 발생할 수 있다. 내부 서버가 OCSP 확인을 위해 인터넷에 직접 연결하도록 강제하는 것은 보안 경계를 허물어뜨리는 디-페리미터화(de-perimeterization) 추세에 기여할 수도 있다. OCSP 스테이플링은 서버가 OCSP 응답을 미리 받아 캐시해두었다가 클라이언트에게 전달하는 방식으로, 클라이언트가 직접 OCSP 응답 서버에 접속할 필요가 없게 하여 이러한 네트워크 접근 문제를 해결하는 대안이 될 수 있다.

6. 1. MustStaple 확장

OCSP 기반 해지 방식은 서버의 개인 키가 유출되었을 때 효과적인 대응책이 되기 어렵다. 서버 개인 키를 탈취한 공격자는 보통 중간자 공격을 시도하는데, 이 위치에서는 클라이언트의 OCSP 요청까지 방해할 수 있기 때문이다. 많은 클라이언트는 OCSP 서버로부터 응답이 제때 오지 않으면 확인 절차를 그냥 건너뛰므로, OCSP만으로는 키 유출 문제에 확실히 대처하기 힘들다.[13]

인증서의 MustStaple TLS 확장은 이러한 문제를 해결하기 위해 도입되었다. 이 확장은 인증서 상태를 확인할 때 반드시 OCSP 스테이플링된 응답을 사용하도록 강제한다.[10] 즉, 서버가 미리 OCSP 응답을 받아두었다가 클라이언트에게 직접 전달하도록 요구하여, 공격자가 중간에서 OCSP 확인 과정을 방해하는 것을 막는다.

7. 브라우저 지원 현황

대부분의 주요 웹 브라우저는 OCSP를 지원한다. 구체적인 지원 현황은 브라우저별로 차이가 있다.

Google Chrome은 예외적으로 OCSP 검사를 기본적으로 비활성화하고 자체적인 인증서 해지 목록 업데이트 방식을 사용한다.[21][31][32]

7. 1. 주요 브라우저 지원

Firefox 89의 OCSP 정보


대부분의 주요 웹 브라우저에서 OCSP를 지원한다.

  • Internet Explorer는 Windows의 CryptoAPI를 기반으로 하며, Windows Vista의 버전 7부터 OCSP 검사를 지원한다. (XP는 제외)[14]
  • Mozilla Firefox는 모든 버전에서 OCSP 검사를 지원하며, Firefox 3부터는 기본적으로 OCSP 검사가 활성화되어 있다.[16]
  • Apple의 Safari(macOS 버전)는 OCSP 검사를 지원한다. Mac OS X 10.7 (Lion)부터 기본적으로 활성화되어 있다.[17] 그 이전 버전에서는 키체인 환경 설정에서 수동으로 활성화해야 했다.
  • Opera는 버전 8.0부터 OCSP 검사를 지원한다.[18][19]
  • Google Chrome은 예외적으로, 지연 시간 및 개인 정보 보호 문제를 이유로 2012년에 OCSP 검사를 기본적으로 비활성화했다.[21][31][32] 대신 자체 업데이트 메커니즘을 사용하여 해지된 인증서 정보를 브라우저로 전송하는 방식을 사용한다. 다만, OCSP 스테이플링은 계속 지원하고 있다.[33]

8. 구현체

다수의 오픈 소스 및 상용 소프트웨어 OCSP 구현체가 존재한다. 여기에는 완전한 기능을 갖춘 서버와 사용자 지정 애플리케이션 구축을 위한 라이브러리가 포함된다. OCSP 클라이언트 지원은 HTTPS와 월드 와이드 웹의 확산으로 인해 많은 운영 체제, 웹 브라우저 및 기타 컴퓨터 네트워크 관련 소프트웨어에 내장되어 있다.

8. 1. 서버 측 구현

오픈 소스

  • 볼더(Boulder): Let's Encrypt에서 개발하고 사용하는 Go 기반 OCSP 응답자이다.
  • DogTag:[23] 오픈 소스 인증 기관(CA), CRL 및 OCSP 응답자이다.
  • EJBCA:[24] Java 기반 CA 및 OCSP 응답자이다.
  • XiPKI:[25] Java 기반 CA 및 OCSP 응답자이다. RFC 6960 및 SHA3를 지원한다.
  • OpenCA OCSP Responder:[26] OpenCA 프로젝트의 독립형 OCSP 응답자 (C)이다.

상용

  • 인증 서비스:[27] 윈도우 서버에 포함된 인증 기관(CA) 및 OCSP 응답자이다.

8. 2. 라이브러리

참조

[1] 웹사이트 History for draft-ietf-pkix-rfc2560bis-20 https://datatracker.[...] 2021-12-23
[2] 웹사이트 How To Configure OCSP Stapling on Apache and Nginx https://www.digitalo[...] Digital Ocean, Inc. 2015-03-02
[3] 웹사이트 OCSP Stapling https://support.glob[...] GMO GlobalSign Inc. 2015-03-02
[4] 웹사이트 CA/Revocation Checking in Firefox https://wiki.mozilla[...] 2022-06-29
[5] 웹사이트 Are revoked certificates detected in Safari and Chrome? https://community.le[...] 2022-06-29
[6] 웹사이트 CRLSets https://www.chromium[...] 2022-06-29
[7] 간행물 Revocation Statuses on the Internet 2021
[8] 웹사이트 '[Servercert-wg] IPR Review period for SC63: Make OCSP optional, require CRLs, and incentivize automation' https://lists.cabfor[...] 2024-08-04
[9] 웹사이트 Intent to End OCSP Service https://letsencrypt.[...] 2024-08-04
[10] 웹사이트 Security Certificate Revocation Awareness: The case for "OCSP Must-Staple" https://www.grc.com/[...] Gibson Research Corporation 2015-03-02
[11] 웹사이트 OCSP Stapling in Firefox https://blog.mozilla[...] Mozilla Foundation 2015-03-02
[12] 문서 RFC 6960, section 5, Security Considerations
[13] 웹사이트 No, Don't Enable Revocation Checking https://www.imperial[...] 2014-04-24
[14] 웹사이트 Windows XP Certificate Status and Revocation Checking http://social.techne[...] Microsoft 2016-05-09
[15] 웹사이트 What's New in Certificate Revocation in Windows Vista and Windows Server 2008 https://technet.micr[...] Microsoft 2016-05-09
[16] 웹사이트 Mozilla Bug 110161 – Enable OCSP by Default https://bugzilla.moz[...] Mozilla 2010-07-18
[17] 웹사이트 Apple users left to defend themselves against certificate attacks http://nakedsecurity[...] Sophos 2011-03-26
[18] 웹사이트 Introducing Extended Validation Certificates http://labs.opera.co[...] Opera Software 2010-01-08
[19] 웹사이트 Rootstore newsletter http://my.opera.com/[...] Opera Software 2010-01-08
[20] 웹사이트 Revocation checking and Chrome's CRL https://www.imperial[...] 2015-01-30
[21] 뉴스 Chrome does certificate revocation better https://www.zdnet.co[...] ZDNet 2014-04-21
[22] 웹사이트 Boulder – an ACME CA https://github.com/l[...] 2018-03-17
[23] 웹사이트 Dogtag Certificate System https://www.dogtagpk[...] 2019-08-12
[24] 웹사이트 EJBCA – Open Source PKI Certificate Authority https://www.ejbca.or[...] PrimeKey 2018-03-17
[25] 웹사이트 XiPKI https://github.com/x[...] 2018-03-17
[26] 웹사이트 OpenCA OCSP https://www.openca.o[...] 2024-01-03
[27] 웹사이트 Certificate Services (Windows) https://msdn.microso[...] Microsoft 2018-03-17
[28] 웹사이트 Package ocsp https://godoc.org/gi[...] 2018-03-17
[29] 웹사이트 OCSP_response_status https://www.openssl.[...] OpenSSL 2018-03-17
[30] 웹사이트 OCSP in wolfSSL Embedded SSL – wolfSSL https://www.wolfssl.[...] 2019-01-25
[31] 문서 https://www.imperial[...]
[32] 웹사이트 Google Chrome、SSL証明書のオンライン失効チェックを無効に https://www.itmedia.[...] ITmedia 2020-12-04
[33] 웹사이트 Issue 361230: SSL Certificate Revocation not enabled by default https://bugs.chromiu[...] 2020-12-04


본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com