인증 기관
브라우저에 자물쇠가 표시되면 이는 서버의 신원을 보증하는 것입니다. 그리고 그 보증은 궁극적으로 인증 기관이라는 소규모 조직에 달려 있습니다. CA가 실제로 수행하는 작업, 신뢰를 얻는 방법, 수년에 걸쳐 신뢰가 무너지고 재구축된 방법을 이해하면 최신 웹이 현재의 모습인 이유에 대해 많은 것을 알 수 있습니다.
전체 기사 본문은 아래에 영어로 제공됩니다.
A 인증 기관(CA)는 공개 키를 ID에 바인딩하는 디지털 인증서를 발급하는 조직입니다. 가장 친숙한 역할은 TLS 인증서를 발급하는 것입니다. example.com이 브라우저에 인증서를 제공하면 브라우저는 CA의 서명을 확인하고 CA가 신뢰 저장소에 있으면 연결이 진행됩니다. 전체 장치는 PKI(공개 키 인프라).
인증서에 포함된 내용
X.509 인증서는 다음을 포함하는 구조화된 문서입니다.
- Subject — 인증서의 용도(example.com 또는 *.example.com) 와일드카드)
- 주체의 공개 키
- Issuer — 서명한 CA
- 유효 기간 — 시작 및 종료 날짜, 현재 최대 397일 browsers
- 일련 번호
- Extensions — 주체 대체 이름(추가 도메인), 키 사용 제약 조건, 해지 확인을 위한 CRL/OCSP URL
- 전체에 대한 CA 서명 위
신뢰 체인 작동 방식
브라우저 및 운영 체제는 신뢰할 수 있는 root CAs 목록과 함께 제공됩니다. 그 중 약 100개는 Chrome에 있으며 Mozilla, Apple, Microsoft에서도 유사합니다. 각 루트 CA에는 공개 키가 있으며 해당 루트 키로 서명된 인증서(직접 또는 중간 CA를 통해)는 브라우저에서 신뢰됩니다.
실제로 루트 CA는 중간 CA 인증서에 서명하고 중간 CA는 최종 엔터티(서버) 인증서에 서명합니다. 이는 루트를 보호합니다. 루트의 개인 키는 오프라인으로 유지되며 중간 서명에만 사용됩니다. 중간 인증서가 손상된 경우 전체 CA를 중단하지 않고 루트에서 이를 취소할 수 있습니다.
브라우저가 example.com에 연결될 때의 확인 흐름:
- Server는 해당 인증서와 중간 인증서를 보냅니다.
- Browser는 서버의 인증서가 중간 인증서에 의해 서명되었는지 확인합니다.
- Browser는 중간 인증서가 신뢰 저장소의 루트에 의해 서명되었습니다.
- Browser는 날짜, 인증서의 도메인 이름, 키 사용 및 해지 상태를 확인합니다.
- 모든 확인을 통과하면 연결이 진행됩니다.
CA가 소유권을 확인하는 방법
example.com에 대한 인증서를 발급하기 전에 CA는 요청자가 실제로 제어하는지 확인해야 합니다. example.com. 세 가지 검증 수준:
- 도메인 검증(DV) — CA는 DNS, HTTP 또는 이메일 챌린지를 통해 도메인 제어를 확인합니다. Let의 Encrypt 인증서는 모두 DV입니다. 대량의 웹 트래픽에 일반적입니다. 저렴하거나 무료입니다.
- 조직 확인(OV) — 요청 조직의 법적 신원 확인을 추가합니다. 비용이 더 많이 들며 인증서에 조직 이름이 포함됩니다.
- 확장 유효성 검사(EV) — 조직에 대한 광범위한 조사입니다. 녹색 주소 표시줄을 트리거하는 데 사용됩니다. 최신 브라우저는 더 이상 EV에 특수 UI 처리를 제공하지 않습니다.
CA가 잘못된 경우
신뢰할 수 있는 CA가 도메인에 대한 인증서를 잘못된 당사자에게 발급하면 신뢰 모델이 중단됩니다. 역사적 사건:
- DigiNotar(2011) — 네덜란드 CA가 침해되어 Google, Yahoo 및 기타 업체에 대한 사기 인증서를 발급했습니다. 이 인증서는 이란 반체제 인사에 대한 MITM 공격에 사용되었습니다. DigiNotar는 신탁 상점에서 제거되고 파산했습니다.
- Comodo(2011) — 리셀러 타협 후 주요 브랜드에 대해 발급된 사기 인증서.
- Symantec(2017) — 수년간 여러 건의 잘못된 발급 사고. 브라우저는 2018년부터 2019년까지 점차 시만텍 루트를 불신했습니다. Symantec은 CA 사업을 DigiCert에 매각했습니다.
인증서 투명성: 최신 가드레일
2018년부터 브라우저는 인증서가 승인되기 전에 공개 CT(인증서 투명성) 로그에 표시되도록 요구합니다. 신뢰할 수 있는 CA에서 발급한 모든 인증서는 발급 후 몇 시간 내에 공개적으로 기록됩니다. 누구나 crt.sh.
와 같은 도구를 통해 자신의 도메인에서 예상치 못한 인증서를 모니터링할 수 있습니다. 이는 CA 오작동을 극적으로 제한합니다. 잘못 발급된 인증서를 감지할 수 있으며 발급 CA의 평판이 위태로워집니다. CT 의무화 이후 부정발급 사건이 급격하게 감소했습니다.
해지: 여전히 손상된 부분
인증서의 개인 키가 손상된 경우 인증서를 취소해야 합니다.
- CRL(인증서 해지 목록) — 정기적으로 다운로드되는 해지된 일련 번호 목록입니다. 업데이트 속도가 느립니다.
- OCSP(온라인 인증서 상태 프로토콜) — 인증서별 온라인 확인. 더 빠르지만 개인 정보 유출이 발생합니다(OCSP 응답자는 사용자가 방문 중인 사이트를 학습합니다).
둘 모두 문제가 있습니다. CRL이 너무 커져서 정기적으로 가져올 수 없습니다. OCSP는 소프트 실패할 수 있습니다(서버가 느린 경우 브라우저는 어쨌든 연결을 허용하며 공격자는 OCSP를 차단하여 이를 악용합니다). 최신 브라우저는 CRLite, CRLSets 및 유사한 일괄 취소 다운로드로 이동했습니다. 2026년의 취소는 이전보다 낫지만 여전히 불완전합니다.
현재 주요 CA를 운영하는 사람
- Let's Encrypt / ISRG — 무료 DV 인증서, 인증서 수에 따라 결정
- DigiCert — 주요 상업용 CA, ate Symantec
- Sectigo — 이전 Comodo, 광범위한 시장 입지
- GoDaddy — 호스팅 비즈니스와 번들
- GlobalSign — 상업용 CA
- Apple, Amazon, Google — 자체 고객을 위해 CA를 실행하는 클라우드 제공업체
자주 묻는 질문
- 왜 그렇게 많은 CA를 신뢰해야 합니까?
- 역사적이고 운영적입니다. 다양한 CA는 다양한 지역, 정부 및 시장 부문에 서비스를 제공합니다. 가지치기는 신뢰 경로를 깨뜨릴 수 있습니다. 브라우저는 오작동하는 CA를 정기적으로 제거합니다. 이 목록은 Mozilla, Apple, Microsoft 및 Google에 의해 선별되었습니다. 이들 중 어느 누구도 불필요한 CA를 신뢰하고 싶어하지 않습니다. 각각은 잠재적인 공격 표면이기 때문입니다.
- 자체 CA를 실행할 수 있나요?
- 내부용으로는 그렇습니다. 많은 조직에서 사설 CA를 실행하고 관리되는 장치에 루트 인증서를 설치합니다. 공개 TLS의 경우 아니요. 브라우저는 수년간의 CA 브라우저 포럼 심사를 거치지 않으면 루트를 신뢰하지 않습니다. 공용 CA는 좁고 규제된 범주인 데에는 그만한 이유가 있습니다.
- CA가 폐업하면 어떻게 되나요?
- 기존 인증서가 만료될 때까지 계속해서 유효성을 검사하는 동안 브라우저는 점차적으로 신뢰 저장소에서 CA를 제거합니다. 인증서 보유자는 일반적으로 만료되기 전에 다른 CA로 교체합니다. 시만텍의 불신은 브라우저 조정 단계를 통해 18개월에 걸쳐 지속되었습니다.
- CA가 내 검색 내용을 볼 수 있나요?
- 발급 단계는 일회성입니다. 그 후에 인증서는 서버에서 브라우저로 제공되며 CA 왕복이 필요하지 않습니다(OCSP가 쿼리되고 최신 스테이플링이 해당 책임을 서버에 푸시하지 않는 한). CA는 일일 트래픽을 볼 수 없습니다.
- 이제 인증서가 397일로 제한되는 이유는 무엇입니까?
- 수명이 짧아지면 손상된 인증서와 강제 순환 규정으로 인한 피해가 제한됩니다. CA/브라우저 포럼은 최대 기간을 5년에서 2년, 1년(397일)으로 점진적으로 줄였으며, 더 줄일 것을 제안했습니다(90일 이하). ACME를 통한 자동화는 운영상 수명을 단축합니다.