데비안 SSL 인증서 오류 : XXX 인증서를 확인할 수 없습니다/javax.net.ssl.SSLHandshakeException

Question

내가 이상한 문제가 내가 보관 용에서 뭔가를 다운로드하려면 (예를 들어, 그것은 100 % 서버 구성 문제는,이다) :

Resolving dl.dropboxusercontent.com... 23.23.160.146, 50.17.227.107, 54.221.248.69, ... Connecting to dl.dropboxusercontent.com|23.23.160.146|:443... connected. ERROR: cannot verify dl.dropboxusercontent.com’s certificate, issued by “/C=US/ST=CA/O=SonicWALL Inc./CN=SonicWALL Firewall DPI-SSL”:
Self-signed certificate encountered. To connect to dl.dropboxusercontent.com insecurely, use ‘--no-check-certificate’.

예, 나는 --non-체크 인증서를 사용할 수 있다는 것을 알고 있지만 자바 응용 프로그램에서 SSL 연결을 사용하고자 할 때이 같은 일이 :이 응용 프로그램은 다른 서버에서 또는 로컬에서 잘 작동

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

을 기계, 어떤 아이디어가 여기에 잘못입니까?

Answer 1

클라이언트의 Java 키 저장소에 서버의 SSL 인증서를 추가해야합니다. 이 SO 포스트에서 살펴 보자 :

Resolving javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed Error?

TIP : 고객의 JVM은 '신뢰'서버의 SSL 인증서하지 않기 때문입니다. 따라서 키 스토어에 인증서를 추가해야합니다.

Answer 2

/C=US/ST=CA/O=SonicWALL Inc./CN=SonicWALL Firewall DPI-SSL

트래픽을 모니터링하기 위해 MITM 프록시 역할을하는 딥 패킷 검사 방화벽이 트래픽을 차단합니다.

이것은 일반적으로 "합법적 인"MITM 공격자로 생각할 수 있습니다. (합법적 인 것은 합법적이고 윤리적 인 여러 측면에 따라 달라질 수 있습니다.) 지역 네트워크 관리자가 이에 대해 조금이라도 알려줄 수 있습니다. 이것이 회사 네트워크의 일부인 경우이 회사는 HTTPS 연결의 내용을 포함하여 트래픽을 모니터링하므로 더 이상 종단 간 보안을 유지할 수 없습니다. 방화벽이 제대로 작동하더라도 방화벽에서 서버로의 연결을 안전하게 유지해야합니다. (인증서를 제대로 확인하는지 여부는 알기 힘듭니다.)

일반적으로 이러한 방화벽이나 프록시는 자체 인증으로 작동합니다 권한으로 각 인증서를 효과적으로 위조합니다.

기업 네트워크의 대부분의 클라이언트는 시스템 관리자가 해당 네트워크의 각 시스템에 신뢰할 수있는 인증서로 CA 인증서를 설치하기 때문에 문제가되는 인증서를 신뢰합니다. OS 신뢰 루트 인증서를 가지고있을 것입니다.

그러나 네트워크 관리자가이 CA 인증서를 JRE 설치 (기본적으로 자체 트러스트 앵커 세트 사용)에 설치하지 않았을 수 있습니다.

참조 컴퓨터에서 해당 CA 인증서 (위의 이름 참조)를 내보내고 사용중인 트러스트 스토어로 가져 오십시오 (JRE의 기본 트러스트 스토어 : cacerts 또는 작성한 새 트러스트 스토어). javax.net.trustStore 속성). truststore.jks 파일이 존재하지 않는

keytool -import -file firewallca.pem -alias firewallca -keystore truststore.jks 

경우가 생성됩니다

일반적으로, 당신은 (당신이 "firewallca.pem"로 방화벽의 CA를 내 보낸 가정) 같은 것을 사용할 수 있습니다. 그렇지 않은 경우 JRE의 lib/security 디렉토리에있는 cacerts 파일의 사본을 가져올 수 있습니다. cacerts 파일 (쓰기 권한이있는 경우 -keystore /path/to/truststore.jks 사용)에서 직접이 작업을 수행 할 수도 있습니다.들어 -Djavax.net.trustStore=/path/to/truststore.jks

: 당신이 (즉, cacerts 파일)의 기본 트러스트 스토어에 그것을 할 수 있지만 truststore.jks 같은 로컬 트러스트 스토어를 사용하지 않을 경우 응용 프로그램을 실행할 때

,이 시스템 속성을 사용하여 사용할 수 있습니다 트러스트 스토어를 구성하는 다른 방법은 this answer입니다.

---

이 문제를 해결하는 또 다른 방법은 Java에 your OS's truststore을 사용하는 것입니다. 여기에 Windows를 사용하고 있다고 가정합니다. 이러한 시스템 등록 정보를 사용하여 작동합니다 :

-Djavax.net.trustStore=NONE -Djavax.net.trustStoreType=WINDOWS-ROOT 

(이 작동하지 않을 경우 WINDOWS-MY 대신 WINDOWS-ROOT으로 시도합니다.)

WINDOWS-MY/WINDOWS-ROOT을 약간은 인증서의 일부를 놓칠 것이라고에서 버그가 Windows 스토어에서는, 키 스토어의 별명 (일의)으로서 증명서 「친숙한 이름」(일의가 아닌)을 사용합니다. 따라서 친숙한 이름을 가지는 증명서는, 같은 이름의 다른 것을 숨 깁니다. (불행히도 신뢰할 수있는 CA 인증서의 수를 효과적으로 줄입니다.)

아마도 모든 트래픽이 DPI 방화벽을 통과하는 환경에 있기 때문에 아마도 한 번만 CA 인증서를 사용해야 할 것입니다. 가장. Windows 목록에있는 "친숙한 이름"을 다른 인증서와 공유하지 않는 한 오래 유지해야합니다.