저는 CentOS 7(Diladele 어플라이언스)에서 Squid 3.5.10을 실행하는 회사 웹 프록시를 관리하고 SSL 범핑을 수행하고 있습니다. 시스템 신뢰 저장소에 새 CA 인증서를 추가하는 데 문제가 있습니다. SSL로 보호되는 여러 사이트에 액세스할 수 있어야 합니다. 그 사이트 중 하나가 바로https://www.sexierdating.com/(그렇습니다. 하지만 우리 정책은 합법적인 한 사람들이 점심 시간에 무엇을 서핑하는지 상관하지 않는 것입니다.)
Squid의 오류 메시지는 일반적입니다 X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY. 이는 어떤 이유로 Squid가 대상 서버 인증서를 신뢰하지 않거나 확인할 수 없음을 의미합니다. 지금까지는 CA 지원 페이지에서 PEM 형식의 CA 루트 인증서를 가져와서 Squid를 /etc/pki/ca-trust/source/anchors실행 update-ca-trust하고 다시 시작하는 것만으로도 문제를 해결할 수 있었지만 현재의 경우에는 그렇지 않았습니다. ca-certificates 패키지는 현재 버전입니다. 방금 컴퓨터에서 전체 yum 업데이트를 실행했기 때문입니다.
현재 문제가 있는 모든 도메인에는 "Go Daddy Secure Certificate Authority - G2" 인증서가 있습니다. 지원 페이지에서 모든 인증서를 다운로드했습니다(https://certs.godaddy.com/repository/), 위에서 설명한 대로 설치하고 오징어를 다시 로드했지만 오류가 지속됩니다. 나는 실제로 올바른 PEM 파일을 선택하는지 확인하기 위해 strace를 사용하여 update-ca-trust를 보았습니다. 실제로 그렇습니다.
좀 이상한 점은 certs.godaddy.com 다운로드 페이지가 문제가 있는 일부 도메인과 정확히 동일한 루트 및 중간 인증서를 사용하는 것 같지만 해당 페이지는 Squid를 통해 제대로 작동한다는 것입니다. Firefox에서 인증서를 비교할 때 전체 사양과 알고리즘에는 차이가 없지만 여전히 하나는 작동하고 다른 하나는 작동하지 않습니다.
어찌할 바를 모르겠습니다. 누군가가 이 문제를 해결하기 위해 올바른 방향을 제시해 줄 수 있기를 바랍니다. GoDaddy 인증서를 사용하면 두 번째 페이지마다 프록시 예외를 추가할 수 없습니다.
답변1
컴퓨터 및 브라우저의 CA 저장소에는 루트 CA 인증서가 포함됩니다.
웹사이트는 절대로 루트 CA가 아닌 중개자로부터 인증서를 발급받아야 합니다.
자체 인증서와 중개 인증서를 모두 반환하는 것은 웹 사이트의 책임이므로 브라우저는 중개 인증서를 신뢰하는 루트 인증서 중 하나에 연결할 수 있습니다.
귀하가 제공한 웹사이트 예에서는 중개 인증서가 포함되어 있지 않으므로 사용자가 사이트를 신뢰할 수 없습니다. 이는 ssllabs 스캔을 통해 확인할 수 있습니다.https://www.ssllabs.com/ssltest/analyze.html?d=www.sexierdating.com. 보시다시피 두 개가 아닌 하나의 인증서만 보내고 이로 인해 불완전한 경고가 표시됩니다. 인증서 경로 섹션을 확장하면 전체 체인이 표시되며 설치하려는 경우 이 중개자를 다운로드할 수 있습니다.
브라우저는 다른 사이트 방문에서 캐시된 공통 중간 인증서를 갖거나 누락된 중간 인증서를 찾으려고 시도하기 때문에 이러한 상황을 처리하는 경우가 많다는 점에 유의해야 합니다. 따라서 대부분의 사용자와 사이트 운영자는 이러한 잘못된 구성을 발견하지 못하는 경우가 많습니다. 여기에서 SSL 범핑이 이러한 오류를 처리하기에는 사용자 친화적이지 않다고 추측합니다.
이는 certs.godaddycom(https://www.ssllabs.com/ssltest/analyze.html?d=certs.godaddy.com) 이는 완전한 체인을 보내는 것입니다. 실제로는 반대의 문제가 있으며 루트 인증서를 보낼 필요가 없기 때문에 너무 많은 인증서를 보내고 있습니다. (그러나 두 개의 인증서 체인 경로가 있다는 것을 볼 수 있듯이 역사적인 이유로 그럴 수도 있습니다. 그 중 하나에는 루트 인증서가 필요합니다. 다른 인증서로 서명해야 합니다. 이는 아마도 신뢰 저장소에 새 루트 인증서가 없는 이전 브라우저에서 사용되었을 것입니다.
어쨌든 귀하의 옵션은 다음과 같습니다:
- 사용자에게 웹사이트가 올바르게 설정되지 않았음을 알리고, 다시 업무로 돌아가서 의심스러운 사이트를 찾느라 회사 시간을 낭비하지 않도록 하세요.
- Squid CA 루트 저장소에 중간 인증서를 추가하세요. 물론 이것은 루트 CA가 아니므로 실제로 저장소에 있어서는 안 되며 어떤 이유로든 취소된 경우에도 여전히 신뢰할 수 있습니다(이는 제거하기가 매우 어렵기 때문에 루트 인증서에서 인증서가 발급되지 않는 이유 중 하나입니다) 신탁 상점에서 구입하세요). 따라서 이를 포함하면 보안 위험이 발생합니다.
- 해당 웹사이트에 연락하여 문제를 설명하고 수정을 요청하세요. 그런 다음 사용자가 원하는 다른 모든 손상된 사이트의 문제를 기본적으로 해결할 준비를 하세요!
저라면 의심할 여지없이 옵션 1을 선택하겠습니다 :-)