이 구덩이를 밟아본 적이 있어. 수행법은 잊었지만, 이 원리는 여전히 기억하고 있습니다. 대략적으로 설명하자면:
브라우저의 설치 패키지는 신뢰하는 일부 루트 인증서(공개 키)를 저장합니다.
보안을 위해 인증서 발급자는 보통 이 루트 인증서에 해당하는 개인 키를 완전히 분리된 볼트에 저장합니다. 이 루트 개인 키는 볼트에서 일부 "중간" 인증서를 발급하는 데 사용되며, 이 중간 인증서의 개인 키는 다음 단계 인증서를 발급할 권한을 가집니다. 이 중간 개인 키들은 웹사이트 인증서를 발급하여 수익을 벌기 위해 온라인 서버에 설치됩니다. 이 서버들이 해킹되면, 퍼블리셔는 볼트 내 물리적으로 격리된 루트 인증서 개인 키를 사용해 중간 인증서들의 신뢰를 제거하면서도 퍼블리셔의 루트 인증서를 완전히 불신하지 않고도 해제 명령을 내릴 수 있습니다. 새로운 중간 발급증서에 서명하면, 당신은 돈을 벌 수 있는 좋은 사람이 될 것입니다.
여기서 질문이 나옵니다.
브라우저는 루트 인증서만 인식합니다. 중간 자격증 인증을 받으려면, 웹사이트에서 직접 인증서를 발급해야 합니다.
적절히 구성된 HTTPS 웹사이트는 인증서에 전체 인증서 체인을 포함해야 합니다.
예를 들어, openssl s_client -connect www.wosign.com:443 명령을 사용해 Wosign의 자체 웹사이트 구성을 확인할 수 있습니다.
나머지 내용은 무시해도 되고, 증명서 체인 단락을 보세요:
---
인증서 체인
0 s:/1.3.6.1.4.1.311.60.2.1.3=CN/1.3.6.1.4.1.311.60.2.1.2=Guangdong/1.3.6.1.4.1.311.60.2.1.1=Shenzhen/businessCategory=Private 조직/시리얼 번호=440301103308619/C=CN/ST=\xE5\xB9\xBF\xE4\xB8\x9C\xE7\x9C\x81/L=\xE6\xB7\xB1\xE5\x9C\xB3\xE5\xB8\x82/postalCode=518067/street=\xE6\xB7\xB1\ xE5\x9C\xB3\xE5\xB8\x82\xE5\x8D\x97\xE5\xB1\xB1\xE5\x8C\xBA\xE5\x8D\x97\xE6\xB5\xB7\xE5\xA4\xA7\xE9\x81\x931057\xE5\x8F\xB7\xE7\xA7\x91\xE6\x8A\x80\xE5\xA4\xA7\xE5\xA7\xE5\ x8E\xA6\xE4\xBA\x8C\xE6\x9C\x9FA\xE6\xA0\x8B502#/O=WoSign\xE6\xB2\x83\xE9\x80\x9A\xE7\x94\xB5\xE5\xAD\x90\xE8\xAE\xA4\xE8\xAF\x81\xE6\x9C\x8D\xE5\x8A\xA1\xE6\x9C\x89\ xE9\x99\x90\xE5\x85\xAC\xE5\x8F\xB8/CN=www.wosign.com
i:/C=CN/O=WoSign CA Limited / CN=WoSign 클래스 4 EV 서버 CA
1 s:/C=CN/O=WoSign CA Limited/CN=WoSign 클래스 4 EV 서버 CA
i:/C=CN/O=WoSign CA Limited/CN=WoSign의 인증 기관
2 s:/C=CN/O=WoSign CA Limited/CN=WoSign의 인증 기관
i:/C=IL/O=StartCom Ltd./OU=보안 디지털 인증서 서명/CN=StartCom 인증 기관
---
0, 1, 2는 인증서 체인 내 각 등급의 일련번호입니다. 0은 웹사이트가 검증할 때 사용하는 인증서입니다. CN은 웹사이트 도메인 이름과 일치해야 합니다.
각 일련번호 뒤에는 s로 시작하는 줄이 증명서를, i로 시작하는 줄은 인증서를 발급한 사람을 나타냅니다.
0의 CN에는 의심되는 중국어 도메인과 영어 도메인 www.wosign.com 이 포함되어 있음을 알 수 있습니다. 이 서비스는 WoSign CA Limited/CN=WoSign Class 4 EV Server CA에서 발행합니다.
증명서가 1이면 0을 발행하는 것입니다. 1 자체는 WoSign의 인증 기관이라는 또 다른 인증서에 의해 발급됩니다.
다음 단계로 살펴보겠습니다. WoSign의 인증 기관은 StartCom에서 발급한다고 되어 있는데(하하, 하청업체였네요!). ）
그래서 그런 수준에서 보면, 브라우저는 '아, 2개의 발행자를 알고 있다'고 나오고, 설치 패키지인 StartCom에도 언급되어 있습니다. 서명과 검증이 정확하니 신뢰하세요 2. 그렇다면 2에서 발행한 1과 1에서 발행된 0도 신뢰해야 합니다. 그래서 이 웹사이트는 신뢰할 수 있습니다.
－－
하지만 웹사이트가 CRT 파일 내에 자신만 포함하도록 설정되어 있고, 브라우저 내장 데이터로 검증할 수 있을 만큼 완전한 인증서 체인이 포함되지 않는다면, 브라우저가 이를 거부할 수 있습니다. 예를 들면
OpenSSL s_client -connect touko.moe:443
---
인증서 체인
0 s:/CN=touko.moe
i:/C=CN/O=WoSign CA Limited / CN=WoSign CA 무료 SSL 인증서 G2
---
한 그룹에는 0명만 있습니다. 설명: 라인 s에 있는 touko.moe는 라인 i에서 WoSign CA Free SSL Certificate G2에서 발급됩니다. 사라졌어요.
이 함정에서 가장 놀라운 점은 이 시점에서 브라우저가 검증을 실패하는지 항상 사실이 아니라는 것입니다. 두 가지 상황이 있습니다:
A. 브라우저를 설치한 이후로 이런 현상을 본 적이 없습니다. 그럼 검증이 실패합니다.
B. 브라우저가 이전에 i를 보고 검증한 적이 있다면, 인증은 성공합니다.
보통 관리자는 인증서 발급자의 https 웹사이트에 접속해 인증서를 구매하고, 브라우저가 이를 검증한 후 성공적으로 검증된 모든 중간 인증서를 캐시하여 미래 시간을 절약합니다. 관리자가 (실수로) 웹사이트를 설정하고 테스트를 탐색했을 때는 아무런 문제가 발생하지 않았습니다. 그의 브라우저가 이미 이 중간 인증서를 인식하고 있기 때문입니다.
하지만 많은 사용자가 이 중간 인증서로 발급된 제대로 구성된 다른 웹사이트를 방문하지 않았을 수도 있습니다. 따라서 검증은 신뢰할 수 있는 발행자를 찾지 못해 실패합니다.
이는 폭스바겐 디젤 차량의 배기 배출가스 제어 시스템과 비교할 만합니다. 확인했을 때 모든 것이 정상이었습니다. 밖에 나가자마자 독을 뿌려.
수정: 어떻게 해결...... 서버 설정 시 SSLCertificateChainFile 설정을 추가하고, 인증서 발급자 웹사이트에서 제공하는 번들 파일을 사용하는 것일 것입니다(이 파일에는 인증서와 고신뢰 인증서 간 연결을 구축하는 여러 중간 인증서가 포함되어 있습니다).
|
게시됨 2017. 8. 15. 오후 9:08:39
|
|
|
