인증서 투명성 검색
도메인에 대해 발급된 모든 공개 신뢰 인증서는 공개 로그에 기록됩니다 — 이 검색은 그것을 다시 읽어 보여줍니다. 도메인을 입력하면 crt.sh가 그 도메인과 하위 도메인에 대해 기록한 내용을 볼 수 있습니다: 각 인증서를 누가 발급했는지, 어떤 이름을 포함하는지, 언제 유효했는지. 잊어버린 인증서 — 그리고 한 번도 요청한 적 없는 인증서 — 를 찾아내는 감사입니다.
이것을 계속 지켜보고 싶으신가요? myeventwatch로 무료로 모니터링 — 만료 및 다운타임 알림, 카드 불필요.
이 검색이 측정하는 것
인증서 투명성은 인증서 발급을 사적인 거래에서 공개 기록으로 바꿉니다. 인증 기관이 공개 이름에 대한 인증서를 발급하면 그 인증서를 여러 CT 로그에 제출하고, 브라우저는 기록되지 않은 인증서를 거부합니다. 그 부수 효과는 방어자에게 선물입니다: 모든 도메인의 완전한 발급 이력이 공개된 곳에 놓여 읽히기를 기다리고 있습니다. 이 페이지는 sysosx 서버의 GET /api/check/cert-search를 호출하는데, 이는 crt.sh — 그 로그들의 공개 인덱스 — 에 도메인과 그 아래 모든 것에 대해 단일 요청을 보내고, 응답을 정규화하고, 최신순으로 정렬하고, 한 시간 동안 캐시합니다. 최대 200개의 항목이 표시됩니다; 그보다 많은 도메인은 잘림 안내와 실제 총계를 받으며, 조용히 잘리는 일은 결코 없습니다.
결과를 판결이 아니라 목록으로 읽으세요. 각 항목에 대한 생산적인 질문은 “우리 시스템 중 어느 것이 이것을 요청했는가?”입니다. 현대적인 자산은 소유자가 아는 것보다 더 많은 곳에서 인증서를 발급합니다: 웹 호스트, CDN, 메일 제공업체, 마케팅 팀의 사이트 빌더, 누군가 작년에 세운 클러스터의 Kubernetes ingress. 그 대부분은 정당하고, 몇 개는 어쨌든 당신에게 소식이 될 것입니다 — 그것 자체가 유용합니다. 본 적 없는 인증서 목록은 누구의 갱신이나 해지 계획의 일부도 될 수 없기 때문입니다. 가장 중요한 항목은 어느 시스템과도 연결할 수 없는 것들입니다: 알 수 없는 발급자, 알 수 없는 하위 도메인, 근처에 배포가 없는 발급 날짜. 그것들은 드물며, 바로 CT가 드러내도록 설계된 것들입니다.
세 가지 도구, 세 가지 질문
이 검색은 “지금까지 무엇이 발급되었는가?”에 답합니다. SSL 검사기는 실시간 핸드셰이크로 “서버가 지금 무엇을 제시하는가?”에 답합니다 — 방문자가 실제로 무엇을 받는지 아는 유일한 방법입니다. SSL 등급기는 “그 서버의 TLS가 얼마나 잘 구성되었는가?” — 프로토콜 버전, 완전 순방향 비밀성, HSTS — 에 문자 등급으로 답합니다. 그리고 브라우저 측 SSL 인증서 파서는 당신이 이미 보유한 인증서 파일을 읽습니다. 로그에는 존재하지만 한 번도 배포되지 않은 갱신은 여기에 나타나고 검사기에는 나타나지 않습니다; 오래된 인증서를 제시하는 서버는 검사기에 나타나고 여기에는 나타나지 않습니다. 두 결과가 다를 때 각각은 자기만의 진실을 말하고 있습니다 — 당신의 질문에 맞는 것을 사용하세요.
자주 묻는 질문
인증서 투명성이란 무엇인가요, 한 단락으로?
2018년 이후 브라우저는 공개 신뢰 인증서가 인증서 투명성(CT) 로그에 게시되도록 요구합니다 — CA가 발급하는 모든 인증서의 공개, 추가 전용 목록입니다. 로그가 존재하는 이유는 잘못된 발급이 숨을 수 없게 하기 위해서입니다: 당신이 한 번도 요청한 적 없는, 당신의 도메인에 대한 인증서가 나타나면, 당신을 포함해 보는 모든 사람에게 보입니다. 이 도구는 그 로그들의 가장 잘 알려진 공개 인덱스인 crt.sh를 통해 당신을 대신해 봅니다.
이것은 SSL 검사기 및 SSL 등급기와 어떻게 다른가요?
세 가지 다른 질문입니다. SSL 검사기는 서버가 지금, 실시간 핸드셰이크에서 어떤 인증서를 제시하는지 묻습니다. SSL 등급기는 그 서버의 TLS가 어떻게 구성되었는지 — 프로토콜, 암호, HSTS — 를 감사하고 등급을 매깁니다. 이 검색은 공개 로그에 따르면 도메인에 대해 지금까지 무엇이 발급되었는지 묻습니다. 실시간 도구로는 찾을 수 없는 인증서를 드러낼 수 있습니다: 잊힌 스테이징 인증서, 조직이 더 이상 사용하지 않는 CA의 인증서, 그리고 — CT가 만들어진 바로 그 경우 — 팀의 누구도 전혀 요청하지 않은 인증서입니다.
왜 이것은 브라우저가 아니라 서버에서 실행되나요?
이 사이트의 브라우저 측 인증서 파서도 crt.sh 조회를 제공하며, 그것이 작동하는지는 crt.sh의 교차 출처 헤더에 달려 있다고 분명히 밝힙니다 — 브라우저는 제3자 서비스가 읽도록 허용한 것만 읽을 수 있습니다. 서버 측 요청은 만족시켜야 할 교차 출처 정책이 없으므로, 여기의 검색은 매번 같은 방식으로 작동합니다. 맞바꿈은 늘 그렇듯 이것입니다: 당신이 입력한 도메인은 sysosx의 서버에서 crt.sh로 전송되고(그리고 한 시간 동안 응답이 캐시됩니다), 이 페이지는 그것을 숨기지 않고 밝힙니다.
인식하지 못하는 인증서가 보입니다. 당황해야 하나요?
아직은 아닙니다. 낯선 항목 대부분은 평범합니다: 당신을 대신해 발급하는 호스팅 제공업체나 CDN(Cloudflare, 로드 밸런서, 웹사이트 빌더), 조직이 이미 떠난 인증 기관, 또는 누군가 설정하고 잊은 자동 갱신 시스템. 발급자와 날짜별로 목록을 검토하고 각 항목을 당신이 운영하는 시스템이나 비용을 지불하는 제공업체와 연결하세요. 당황 — 음, 긴급 조사 — 은 나머지를 위한 것입니다: 아무도 사용하지 않는 CA의, 아무도 운영하지 않는 이름을 포함하는, 아무도 아무것도 배포하지 않은 시점에 발급된 인증서. 그것은 기록할 가치가 있는 당신 자산의 잊힌 구석이거나, CT가 잡기 위해 존재하는 잘못된 발급이며, 설명될 때까지 추적해야 합니다.
왜 결과는 한 시간 동안 캐시되며, 왜 검색이 실패할 수 있나요?
crt.sh는 무료 공공 서비스로 부하가 걸리면 악명 높게 느리고, 인증서 이력은 분 단위가 아니라 일 단위로 변하기 때문입니다 — 한 시간의 캐시는 신선도 면에서 비용이 전혀 들지 않으며 이 도구가 crt.sh의 부담을 더하지 않게 합니다: 도메인당 시간당 최대 한 번의 업스트림 쿼리. crt.sh가 다운되었거나 너무 느릴 때, 검색은 빈 목록을 반환하는 대신 명시적인 오류로 그렇게 말합니다. “인증서를 찾을 수 없음”과 “로그 검색 실패”는 반대의 결론이며 그중 하나만 진실이기 때문입니다.