약간의 연구를 거친 후, 나는 this post을 발견했습니다. 다음은 내가 사용을 종료 한 이유입니다.
import javax.net.ssl.HostnameVerifier
import javax.net.ssl.HttpsURLConnection
import javax.net.ssl.SSLContext
import javax.net.ssl.TrustManager
import javax.net.ssl.X509TrustManager
def nullTrustManager = [
checkClientTrusted: { chain, authType -> },
checkServerTrusted: { chain, authType -> },
getAcceptedIssuers: { null }
]
def nullHostnameVerifier = [
verify: { hostname, session -> true }
]
SSLContext sc = SSLContext.getInstance("SSL")
sc.init(null, [nullTrustManager as X509TrustManager] as TrustManager[], null)
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory())
HttpsURLConnection.setDefaultHostnameVerifier(nullHostnameVerifier as HostnameVerifier)
위험을 감수하면서 사용하십시오.
일반적으로 hvgotcodes가 더 나은 솔루션입니다. 물론 마일리지가 다를 수 있습니다. 솔루션의 문제점은 모든 호스트가 현재 실제로 사용할 수있는 소수의 호스트가 아닌 유효한 호스트라는 것입니다. 코드가 엄격하게 제어되고 "신뢰할 수있는"소스에만 연결될 것이라는 확신이 든다면 괜찮을 것입니다. 그러나 인증서를 트러스트 스토어로 가져올 경우 DNS 오 검색과 보호해야 할 기타 여러 가지 문제에 취약합니다. 보다 동적 인 동작 인 경우 런타임시 javax.net.ssl.trustStore 속성을 설정할 수도 있습니다. –
일반적으로 동의합니다. 그러나 인증서 관리를 완전히 무시하는 것이 바람직한 스크립팅 컨텍스트가 있습니다. 예를 들어 테스트 서버가 동적으로 생성되고 클라이언트의 키 저장소가 지속적으로 동기화되어야하는 경우가 있습니다. 루비 나 파이썬 같은 다른 동적 인 언어는 이것을 간단한 설정으로 만들고 디폴트로 인증서 체인을 강제하지 않는다는 점도 주목할 가치가 있습니다. – ataylor
@ BrianM.Carr의 의견을 거치지 않고 복사/붙여 넣기를하는 독자를 위해이 코드를 굵은 글씨로 표기 해주십시오 : **이 솔루션은 인증서 확인 단계를 모두 불가능하게하므로 MITM 공격 **에 취약 할 수 있습니다. – Bruno