Development Tip

GoDaddy SSL 인증서가 Java에서 작동하지 않음

yourdevel 2020. 12. 30. 19:42
반응형

GoDaddy SSL 인증서가 Java에서 작동하지 않음


UPDATE 1/26/2015 -- It appears the most recent JRE/JDK for Java 8 (update >= 31) and JRE/JDK for Java 7 now include the Godaddy G2 CA server in the default trust store. If possible, it's urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

2014 년 11 월 29 일 업데이트-이것은 여전히 ​​문제이며 Godaddy는 그것에 대해 신경 쓰지 않고 아무것도하지 않을 것 같습니다. 이 블로그 게시물입니다 여기에 수정이의 길이었다 임시 해결 방법을 제공 말을 전 몇 개월에서 보안 제품의 GoDaddy이 부사장으로,하지만있는 그대로의 오늘 아무것도가 변경되었습니다. Godaddy의 G2 CA 서버는 최소 5 년 동안 사용되었으며 그 동안 Godaddy는이 알려진 문제를 해결하기위한 적절한 조치를 취하지 않았습니다. 제공된 해결 방법은 해결 방법이 아니라 해결 방법입니다. 타사 서비스 사용자는 인증서가 서버에 설치되는 방식을 전혀 제어 할 수 없습니다.

It seems users should avoid purchasing Godaddy SSL certs until they get serious about being a CA.

전화 할 의사가있는 경우 SSL 팀의 연락처 정보는 다음과 같습니다.

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: ra@godaddy.com

2014 년 9 월 17 일 업데이트-이것은 여전히 ​​문제이며 Godaddy는 그것에 대해 신경 쓰지 않고 아무것도하지 않을 것 같습니다. Google이 모든 SHA-1 인증서를 지원 중단하는 11 월이 오면 이는 주요 문제가 될 것입니다. 고 디디에게 연락 할 수있는 사람이라면 누구에게나 여기를 추천합니다.

~

tl;dr; - final update with current solution/workaround at the bottom of this post (it is a GoDaddy problem and there is a workaround until they fix it)

Java 앱에서 메일을 보내려는 메일 서버가 있습니다. 포트 25에서 성공적으로 전송할 수 있으므로 코드가 작동한다는 것을 알 수 있지만 25는 암호화 된 세션이 아닙니다. SSL 인증서가 필요한 포트 587에서 TLS를 사용해야합니다. GoDaddy G2 CA에서 서명 한 서버에 유효한 SSL 인증서가 있으며 한동안 사용되었습니다 (문제 없음).

내 문제는 PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target587에 연결하고 메일을 보내려고 할 때 유명한 오류 메시지가 표시된다는 것입니다.

많은 SO 링크와 일반 google-fu에 대한 이해로 볼 때 이것은 일반적으로 자체 서명 된 인증서의 경우와 같이 Java가 인증서 또는 CA를 신뢰하지 않을 때 발생합니다. 체인이 유효한지 등을 확인하기 위해 여러 온라인 SSL 인증서 검사기를 사용했습니다. 모두 정상으로 보이지만 자바는 인증서를 자동으로 사용하지 않습니다.

Sun의 어딘가에 로컬 키 저장소에 인증서를 다운로드하고 설정하는 클래스 파일이 있다는 것을 알고 있으므로 Java는이를 신뢰할 수 있습니다. Godaddy 서명 인증서에 대해 바보입니다.

무슨 일이야? Java가 모든 인증서를 수락하도록 만들지 않고 Java 가 서버에서 유효한 인증서를 사용하도록하려면 어떻게 해야합니까?

편집 : 방금 내 Windows Java 제어판 (jdk 7의 기본 설치)을 보았고 Signer CAIssued By : The Go Daddy Group, Inc. Go Daddy Class 2 Certification Authority가 나열되어 있습니다 ... 그래서 무엇을 제공합니까? 내 인증서는 Godaddy 인증서입니다 ...

UPDATE --

주석에서 권장하는 openssl 명령에서 볼 수있는 인증서 체인은 다음과 같습니다.

~]# openssl s_client -connect smtp.somecompany.com:587 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=smtp.somecompany.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 3 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
---

괜찮아 보이는데 ...

UPDATE 2 --

좋아, @Bruno 덕분에 내 체인이 엉망이 된 것을 확인할 수있었습니다. 서버 키를 다시 입력했으며 이제 내 체인이 다음과 같이 나타납니다.

 ~]# openssl s_client -connect smtp.somecompany.com:587 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, ST = Arizona, L = Scottsdale, O = "GoDaddy.com, Inc.", CN = Go Daddy Root Certificate Authority - G2
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=smtp.somecompany.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
---

이전보다 더 좋아 보입니다. -Java는 여전히 인증서 경로 등에 대해 동일한 예외를 발생시킵니다. 따라서 G2 인증서 체인은 기본적으로 아직 Java 7의 기본 키 저장소에서 신뢰할 수없는 것으로 보입니다.

FINAL UPDATE FOR COMPLETENESS @ 1/14/2014

업데이트와 마찬가지로-이것은 실제로 GoDaddy 문제입니다 (긴 지원 이메일을 받았습니다). 두 개의 CA 서버가 있는데 하나는라고 Class 2 CA하고 다른 하나는 G2 CA. 그들은 Class 2 CA모든 SHA-1인증서에 서명하고 모든 인증서에 G2 CA서명합니다 SHA-2. 이것이 문제가되는 곳입니다. GoDaddy는 새로운 G2 CA서버를 기본 Java 신뢰 저장소에 추가하지 않아 기본 Java 설치가 권한을 신뢰하지 않으므로 체인 인증서를 신뢰하지 않습니다. GoDaddy가 G2 CA기본 신뢰 저장소에 서버를 추가 할 때까지 해결 방법은 서버에서 SHA-1서명 한 인증서를 얻기 위해 as-를 사용하여 인증서를 다시 입력하는 것 Class 2 CA입니다. 인증서가 만료 될 때까지 (분명히) GoDaddy 고객은 키 재 입력이 무료입니다.


UPDATE 1/26/2015 -- It appears the most recent JRE/JDK for Java 8 (update >= 31) and JRE/JDK for Java 7 now include the Godaddy G2 CA server in the default trust store. If possible, it's urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

2014 년 11 월 29 일 업데이트-이것은 여전히 ​​문제이며 Godaddy는 그것에 대해 신경 쓰지 않고 아무것도하지 않을 것 같습니다. [here][1]몇 달 전 보안 제품 담당 부사장 Godaddy 의 블로그 게시물 에서 수정이 진행 중이며 임시 해결 방법을 제공했지만 현재로서는 변경된 사항이 없습니다. Godaddy의 G2 CA 서버는 최소 5 년 동안 사용되었으며 그 동안 Godaddy는이 알려진 문제를 해결하기위한 적절한 조치를 취하지 않았습니다. 제공된 해결 방법은 해결 방법이 아니라 해결 방법입니다. 타사 서비스 사용자는 인증서가 서버에 설치되는 방식을 전혀 제어 할 수 없습니다.

It seems users should avoid purchasing Godaddy SSL certs until they get serious about being a CA.

전화 할 의사가있는 경우 SSL 팀의 연락처 정보는 다음과 같습니다.

GoDaddy SSL Team Support Number: 1-480-505-8852 -- Email: ra@godaddy.com

2014 년 9 월 17 일 업데이트-이것은 여전히 ​​문제이며 Godaddy는 그것에 대해 신경 쓰지 않고 아무것도하지 않을 것 같습니다. Google이 모든 SHA-1 인증서를 지원 중단하는 11 월이 오면 이는 주요 문제가 될 것입니다. 고 디디에게 연락 할 수있는 사람이라면 누구에게나 여기를 추천합니다.

~~~~

내 초기 게시물 / 질문은 내 체인이 작동하지 않는 이유에 관한 것이 었습니다. 내가 잘못된 설정을 가졌다는 것이 분명해졌습니다 (@Bruno 및 다른 사람들의 조언으로 빠르게 수정되었습니다-감사합니다). 그러나 수정 된 체인이 여전히 Java에서 작동하지 않을 때 훨씬 더 큰 문제가 숨어 있다는 것이 분명해졌습니다. 시간이 좀 걸렸지 만 실제로 문제는 GoDaddy에 있습니다.

이것은 실제로 GoDaddy 문제입니다 (긴 지원 이메일을 보내 왔습니다).

두 개의 CA 서버가 있는데 하나는라고 Class 2 CA하고 다른 하나는 G2 CA. 그들은 Class 2 CA모든 SHA-1인증서에 서명하고 모든 인증서에 G2 CA서명합니다 SHA-2.

이것이 문제가되는 곳입니다. GoDaddy는 새로운 G2 CA서버를 기본값에 추가 Java truststore/keystore하지 않았기 때문에 기본 Java 설치가 자신의 권한을 신뢰하지 않으므로 체인 인증서를 신뢰하지 않습니다.

GoDaddy가 G2 CA기본 신뢰 저장소 / 키 저장소에 서버를 추가 할 때까지 해결 방법은 서버에서 SHA-1서명 한 인증서를 얻기 위해 as-를 사용하여 인증서를 다시 입력하는 것 Class 2 CA입니다. 인증서가 만료 될 때까지 (분명히) GoDaddy 고객은 키 재 입력이 무료입니다.

당신은 일단 SHA-1의해 서명 인증서 Class 2 CA서버를 예상하고 어떤 사용자 정의 신뢰 저장소 / 키 저장소 수입 및 / 또는 설치가 필요하지 않습니다으로, 신뢰 체인 작동합니다.

제대로 작동하기 위해 "약한"인증서를 사용해야하는 것은 행복하지 않습니다. 지금까지 이메일 지원을 통해 GoDaddy와 논의한 결과 현재 G2 CA기본 신뢰 저장소 / 키 저장소에 서버를 추가 할 계획이 없다고 표시 되었습니다. . 그들이 그것을 추가 할 때까지 SHA-1 Class 2 CAJava로 작업 할 계획이라면 서버 서명 인증서를 받으십시오.


Fixer와 Wayne Thayer의 답변은 반대표를 받았지만 실제로는 올바른 해결 방법을 옹호하고 있습니다. 실제로 Wayne Thayer는 GoDaddy의 SSL 비즈니스를 이끌고 있으므로 아마 알고있을 것입니다. 중간 인증서와 함께 "GoDaddy G1 to G2 Cross"인증서를 인증서 체인에 설치해야합니다.

SHA1로 다운 그레이드하는 것은 더 이상 사용되지 않으며 앞으로 더 많은 작업을 수행하게되므로 이상적인 옵션이 아닙니다. 다행히 GoDaddy는이 문제를 해결하는 크로스 오버 인증서를 제공했습니다. 그들은 Wayne이 복제 한 지침을 게시 했으며 여기에 댓글에 묻혀 있습니다 .

개인적으로이 솔루션을 SHA2 인증서로 테스트했으며 잘 작동합니다. 키 재 입력 및 SHA1로 다운 그레이드하는 것보다 훨씬 우수한 솔루션입니다. SHA2가 필요 해지면이 옵션을 사용할 수 없으며 새 인증서 없이도 Java 도구 체인이있을 수 있습니다.

GoDaddy 지원에 따르면 2014 년 7 월 현재 Java 8의 최신 버전에 올바른 루트 인증서가 포함되어 있으며 2014 년 9 월에 GoDaddy의 Wayne Thayer 는 인증서가 "다음 몇 달 내에 Java에 추가 될 예정" 이라고 말했습니다. ". 여기 에서 다운로드 한 Mac OS 용 Java 8의 cacerts 파일을 확인했으며 실제로 SHA2 루트 인증서가 포함되어 있습니다.

따라서 체인 대신 다음과 같이 보입니다.

  • Go Daddy 루트 인증 기관 – G2 : (SHA-2) – 해시 47 BE AB C9 22 EA E8 0E 78 78 34 62 A7 9F 45 C2 54 FD E6 8B. 이것은 일부 시스템 (예 : Chrome)에 내장 된 루트 인증서입니다. SnakeDoc은 "Java, Windows CE, Microsoft Exchange 및 기타 플랫폼에 내장되어 있지 않습니다"라고 주장합니다.
  • Go Daddy 보안 인증 기관 – G2 : (SHA-2) – 해시 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8
  • SHA2 인증서

다음과 같이 표시되어야합니다.

  • Go Daddy 클래스 2 인증 기관 : (SHA-1) – 해시 27 96 BA E6 3F 18 01 E2 77 26 1B A0 D7 77 70 02 8F 20 EE E4. 이것은 Java를 포함한 대부분의 시스템에 내장 된 오래된 루트 인증서입니다.
  • Go Daddy 루트 인증 기관 – G2 : (SHA-2) – 해시 34 0B 28 80 F4 46 FC C0 4E 59 ED 33 F5 2B 3D 08 D6 24 29 64. 이것은 소위 "GoDaddy G1에서 G2 교차 인증서"입니다. .
  • Go Daddy 보안 인증 기관 – G2 : (SHA-2) – 해시 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8
  • SHA-2 인증서

참조-이 문제를 해결 방법으로 요약 한 내 블로그 게시물.


SHA2와 함께 Java에서 작동하도록 Godaddy 인증서를 얻으려면 Java가 저장소를 업데이트하기로 결정할 때까지 G2 (SHA2) 루트를 G1 (SHA1) 루트에 연결하기 위해 체인에서 교차 인증서를 사용해야합니다. 교차 인증서 번들은 여기에서 다운로드 할 수 있습니다.

https://certs.godaddy.com/anonymous/repository.pki

GoDaddy 인증서 번들-G2와 G1 간 교차, 루트 포함

[gd_bundle-g2-g1.crt][1] 

Mr. Fixer가 맞습니다. 중간 인증서와 함께 인증서 번들 파일에 "GoDaddy G1 to G2 Cross"인증서를 설치합니다. 이를 통해 Java를 포함한 SHA-1 루트를 인식하는 모든 클라이언트가 GoDaddy SHA-2 인증서를 신뢰할 수 있습니다. https://certs.godaddy.com/repository 에서이 파일을 가져올 수 있습니다.이 파일 이 설치되면 Java는 인증서에서 "GoDaddy 보안 서버 인증서 (중간 인증서)", "GoDaddy G1에서 G2로 인증서 체인을 구축합니다. Cross Certificate "를 GoDaddy SHA-1 루트에 추가합니다. 리포지토리에서 교차 인증서가 포함 된 번들 파일을 찾을 수도 있습니다. 이 옵션에 대한 마지막 참고 사항 : 루트 인증서의 서명은 확인되지 않으므로 SHA-1 루트에 의존하더라도


주석 및 openssl s_client -connect the.server.name:587 -starttls smtp.

인증서 체인에서 인증서 n은 목록의 인증서 n + 1에 의해 발급되어야합니다. 인증서 n의 발급자 (i)는 인증서 n + 1의 주체 여야합니다.

 0 s:/OU=Domain Control Validated/CN=smtp.somecompany.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
 3 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2

여기서 cert 0은 cert 1 (fine)에 의해 발급되고 cert 1은 cert 2 (fine)에 의해 발급되고 cert 2는 자체 서명 (괜찮음, 루트 CA)입니다.

그러나 cert 2는 cert 3에 의해 발급되지 않습니다. Cert 3이 잘못 배치되었으며 아마도 cert 1과 동일합니다. 이로 인해 체인이 무효화되므로 문제가 발생할 수 있습니다.

최소한 구성에서 인증서 3을 제거해야합니다. 또한 루트 CA가 필요하지 않으므로 인증서 2를 제거 할 수도 있습니다 (어쨌든 클라이언트가이를 알 수 있음).


GoDady G2 번들을 Java 키 저장소로 가져 오면 문제가 해결됩니다.

export JAVA_HOME=/usr/lib/jvm/java-8-oracle/
wget https://certs.godaddy.com/repository/gd_bundle-g2.crt
$JAVA_HOME/bin/keytool -import -alias root -file ./gd_bundle-g2.crt -storepass changeit -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts

메일 서버가에 의해 서명되지 않은 것 Go Daddy Class 2 Certification Authority같지만 실제로는 중간 인증 기관 중 하나에 의해 서명되었습니다. 이를 직접 확인해야합니다. 이것이 사실이라고 가정하면 ...

이론적으로는 소프트웨어가 작동해야합니다. 중간 인증서는 클래스 2 기관에서 서명하고 기본 JDK 인증서 저장소에 클래스 2 기관이 있기 때문입니다. 그러나 인증서 저장소에 중간 인증서를 추가하지 않으면 작동하지 않는 것으로 나타났습니다. 다음은 유사한 경험을 설명하는 블로그 게시물에 대한 링크입니다.

http://drcs.ca/blog/adding-godaddy-intermediate-certificates-to-java-jdk/

다음은 더 많은 GoDaddy 중간 인증서에 대한 직접 링크입니다. https://certs.godaddy.com/anonymous/repository.pki

어떤 인증서를 추가해야하는지 정확히 알 수는 없습니다. 메일 서버에서 사용되는 CA에 따라 다릅니다.

[최신 정보]

is there a way to do this programmically?

아마도. 무엇을하고 싶은지에 따라 다릅니다. java.security.KeyStore클래스를 사용하여 .NET을 사용하지 않고 Java 코드에서 직접 개인 키 저장소를 자동으로 업데이트했습니다 keytool. 개념적으로 간단합니다. 파일에서 키 저장소를로드하고 새 인증서를 읽고이를 키 저장소에 추가 한 다음 키 저장소를 새 파일에 기록합니다. 그러나 세부 정보를 올바르게 가져 오는 데 시간이 걸리며 단일 인증서를 가져 오는 것만으로는 문제가되지 않을 수 있습니다.

그래도 시도하는 것이 흥미 롭습니다. 체크 아웃 키 스토어의 JavaDoc 과은에 읽어 load, storesetCertificateEntry방법.


"Java 제어판"에서 방금 "보안 사이트 CA"에 GD 루트 인증서를 추가했으며 Java를 사용할 때 더 이상 인증서 오류가 발생하지 않습니다. 내가 추가 한 인증서 : Go Daddy Class 2 인증 기관 루트 인증서-G2


Update - this "solution" is no longer valid (see my above accepted answer) - keeping this answer because it did help alleviate the problem so long as the side-effects are tolerable.

알겠습니다. 제 케이스에 대한 해결 방법을 찾았을 수 있습니다.

props.put("mail.smtp.ssl.trust", "smtp.somecompany.com");

이것을 세션 구성에 추가했고 이제 작동합니다. 내 Godaddy SSL 인증서가 기본적으로 신뢰할 수없는 이유를 여전히 알 수 없기 때문에 해결 방법이 아닙니다. 자체 서명 된 인증서가 아닙니다.

이 문제를 정말로 이해하고 싶기 때문에 누구든지 자유롭게 차임하십시오.


시도해 볼 수있는 것은 다음과 같습니다. 런타임에 GoDaddy 루트 및 중간 인증서를 신뢰 관리자에 추가하십시오. 즉, 응용 프로그램을 시작합니다.

정적 최종 문자열 GD_CERT1 = // "----- 인증서를 BEGIN -----" "MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx"+ "EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoT는"+ "EUdvRGFkZHkuY29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRp"+ "ZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTExMDUwMzA3MDAwMFoXDTMxMDUwMzA3"+ "MDAwMFowgbQxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQH"+ "EwpTY290dHNkYWxlMRowGAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UE"+ "CxMkaHR0cDovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQD"+ " EypHbyBEYWRkeSBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEi "+"MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC54MsQ1K92vdSTYuswZLiBCGzD "+"BNliF44v / z5lz4 / OYuY8UhzaFkVLVat4a2ODYpDOD2lsmcgaFItMzEUz6ojcnqOv "+"K / 6AYZ15V8TPLvQ / MDxdR / yaFrzDN5ZBUY4RS1T4KL7QjL7wMDge87Am + GZHY23e "+"cSZHjzhHU9FGHbTj3ADqRay9vHHZqm8A29vNMDp5T19MR / gd71vCxJ1gO7GyQ5HY "+"pDNO6rPWJ0 + tJYqlxvTV0KaudAVkV4i1RFXULSo6Pvi4vekyCgKUZMQWOlDxSq7n "+"eTOvDCAHf + jfBDnCaQJsY1L6d8EbyHSHyLmTGFBUNUtpTrw700kuH9zB0lL7AgMB "+"AAGjggEaMIIBFjAPBgNVHRMBAf8EBTADAQH / MA4GA1UdDwEB / wQEAwIBBjAdBgNV "+"HQ4EFgQUQMK9J47MNIMwojPX + 2yz8LQsgM4wHwYDVR0jBBgwFoAUOpqFBxBnKLbv "+"9r0FQW4gwZTaD94wNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v "+"b2NzcC5nb2RhZGR5LmNvbS8wNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5n " + "b2RhZGR5LmNvbS9nZHJvb3QtZzIuY3JsMEYGA1UdIAQ / MD0wOwYEVR0gADAzMDEG"+ "CCsGAQUFBwIBFiVodHRwczovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkv"+ "MA0GCSqGSIb3DQEBCwUAA4IBAQAIfmyTEMg4uJapkEv / oV9PBO9sPpyIBslQj6Zz"+ "91cxG7685C / B + LrTW + C05 + Z5Yg4MotdqY3MxtfWoSKQ7CC2iXZDXtHwlTxFWMMS2 "+"RJ17LJ3lXubvDGGqv QqG + + 6EnriDfcFDzkSnE3ANkR / 0yBOtg2DZ2HKocyQetawi "+"DsoXiWJYRBuriSUBAA / NxBti21G00w9RKpv0vHP8ds42pM3Z2Czqrpv1KrKQ0U11 "+"지오 / ikGQI31bS / 6kA1ibRrLDYGCD H1QQc7CoZDDu + + + 8CL9IVVO5EFdkKrqeKM 배 "+"LXY2JtwE65 / 3YR8V3Idv7kaWKK2hJn0KCacuBKONvPi8BDAB "// + "----- END CERTIFICATE -----";

static final String GD_CERT2 =
//"-----BEGIN CERTIFICATE-----"
"MIIEfTCCA2WgAwIBAgIDG+cVMA0GCSqGSIb3DQEBCwUAMGMxCzAJBgNVBAYTAlVT"
+"MSEwHwYDVQQKExhUaGUgR28gRGFkZHkgR3JvdXAsIEluYy4xMTAvBgNVBAsTKEdv"
+"IERhZGR5IENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTQwMTAx"
+"MDcwMDAwWhcNMzEwNTMwMDcwMDAwWjCBgzELMAkGA1UEBhMCVVMxEDAOBgNVBAgT"
+"B0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoTEUdvRGFkZHku"
+"Y29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRpZmljYXRlIEF1"
+"dGhvcml0eSAtIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv3Fi"
+"CPH6WTT3G8kYo/eASVjpIoMTpsUgQwE7hPHmhUmfJ+r2hBtOoLTbcJjHMgGxBT4H"
+"Tu70+k8vWTAi56sZVmvigAf88xZ1gDlRe+X5NbZ0TqmNghPktj+pA4P6or6KFWp/"
+"3gvDthkUBcrqw6gElDtGfDIN8wBmIsiNaW02jBEYt9OyHGC0OPoCjM7T3UYH3go+"
+"6118yHz7sCtTpJJiaVElBWEaRIGMLKlDliPfrDqBmg4pxRyp6V0etp6eMAo5zvGI"
+"gPtLXcwy7IViQyU0AlYnAZG0O3AqP26x6JyIAX2f1PnbU21gnb8s51iruF9G/M7E"
+"GwM8CetJMVxpRrPgRwIDAQABo4IBFzCCARMwDwYDVR0TAQH/BAUwAwEB/zAOBgNV"
+"HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDqahQcQZyi27/a9BUFuIMGU2g/eMB8GA1Ud"
+"IwQYMBaAFNLEsNKR1EwRcbNhyz2h/t2oatTjMDQGCCsGAQUFBwEBBCgwJjAkBggr"
+"BgEFBQcwAYYYaHR0cDovL29jc3AuZ29kYWRkeS5jb20vMDIGA1UdHwQrMCkwJ6Al"
+"oCOGIWh0dHA6Ly9jcmwuZ29kYWRkeS5jb20vZ2Ryb290LmNybDBGBgNVHSAEPzA9"
+"MDsGBFUdIAAwMzAxBggrBgEFBQcCARYlaHR0cHM6Ly9jZXJ0cy5nb2RhZGR5LmNv"
+"bS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAWQtTvZKGEacke+1bMc8d"
+"H2xwxbhuvk679r6XUOEwf7ooXGKUwuN+M/f7QnaF25UcjCJYdQkMiGVnOQoWCcWg"
+"OJekxSOTP7QYpgEGRJHjp2kntFolfzq3Ms3dhP8qOCkzpN1nsoX+oYggHFCJyNwq"
+"9kIDN0zmiN/VryTyscPfzLXs4Jlet0lUIDyUGAzHHFIYSaRt4bNYC8nY7NmuHDKO"
+"KHAN4v6mF56ED71XcLNa6R+ghlO773z/aQvgSMO3kwvIClTErF0UZzdsyqUvMQg3"
+"qm5vjLyb4lddJIGvl5echK1srDdMZvNhkREg5L4wn3qkKQmw4TRfZHcYQFHfjDCm"
+"rw==";
//+"-----END CERTIFICATE-----";

static final String GD_CERT3 =
//"-----BEGIN CERTIFICATE-----"
"MIIEADCCAuigAwIBAgIBADANBgkqhkiG9w0BAQUFADBjMQswCQYDVQQGEwJVUzEh"
+"MB8GA1UEChMYVGhlIEdvIERhZGR5IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBE"
+"YWRkeSBDbGFzcyAyIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA0MDYyOTE3"
+"MDYyMFoXDTM0MDYyOTE3MDYyMFowYzELMAkGA1UEBhMCVVMxITAfBgNVBAoTGFRo"
+"ZSBHbyBEYWRkeSBHcm91cCwgSW5jLjExMC8GA1UECxMoR28gRGFkZHkgQ2xhc3Mg"
+"MiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCASAwDQYJKoZIhvcNAQEBBQADggEN"
+"ADCCAQgCggEBAN6d1+pXGEmhW+vXX0iG6r7d/+TvZxz0ZWizV3GgXne77ZtJ6XCA"
+"PVYYYwhv2vLM0D9/AlQiVBDYsoHUwHU9S3/Hd8M+eKsaA7Ugay9qK7HFiH7Eux6w"
+"wdhFJ2+qN1j3hybX2C32qRe3H3I2TqYXP2WYktsqbl2i/ojgC95/5Y0V4evLOtXi"
+"EqITLdiOr18SPaAIBQi2XKVlOARFmR6jYGB0xUGlcmIbYsUfb18aQr4CUWWoriMY"
+"avx4A6lNf4DD+qta/KFApMoZFv6yyO9ecw3ud72a9nmYvLEHZ6IVDd2gWMZEewo+"
+"YihfukEHU1jPEX44dMX4/7VpkI+EdOqXG68CAQOjgcAwgb0wHQYDVR0OBBYEFNLE"
+"sNKR1EwRcbNhyz2h/t2oatTjMIGNBgNVHSMEgYUwgYKAFNLEsNKR1EwRcbNhyz2h"
+"/t2oatTjoWekZTBjMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYVGhlIEdvIERhZGR5"
+"IEdyb3VwLCBJbmMuMTEwLwYDVQQLEyhHbyBEYWRkeSBDbGFzcyAyIENlcnRpZmlj"
+"YXRpb24gQXV0aG9yaXR5ggEAMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQAD"
+"ggEBADJL87LKPpH8EsahB4yOd6AzBhRckB4Y9wimPQoZ+YeAEW5p5JYXMP80kWNy"
+"OO7MHAGjHZQopDH2esRU1/blMVgDoszOYtuURXO1v0XJJLXVggKtI3lpjbi2Tc7P"
+"TMozI+gciKqdi0FuFskg5YmezTvacPd+mSYgFFQlq25zheabIZ0KbIIOqPjCDPoQ"
+"HmyW74cNxA9hi63ugyuV+I6ShHI56yDqg+2DzZduCLzrTia2cyvk0/ZM/iZx4mER"
+"dEr/VxqHD3VILs9RaRegAhJhldXRQLIQTO7ErBBDpqWeCtWVYpoNz4iCxTIM5Cuf"
+"ReYNnyicsbkqWletNw+vHX/bvZ8=";
//+"-----END CERTIFICATE-----";

public static void main(String[] args) throws Exception {

    TrustManagerFactory dtmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
    dtmf.init((KeyStore) null); // gets you the default trust manager


    X509TrustManager defaultTm = null;
    for (TrustManager tm : dtmf.getTrustManagers()) 
    {
        if (tm instanceof X509TrustManager) 
        {
            defaultTm = (X509TrustManager) tm;
            break;
        }
    }


    CertificateFactory cf = CertificateFactory.getInstance("X.509");
    byte [] decoded = Base64.getDecoder().decode(GD_CERT1);
    ByteArrayInputStream in = new ByteArrayInputStream(decoded);
    Certificate ca1 = cf.generateCertificate(in);
    in.close();

    decoded = Base64.getDecoder().decode(GD_CERT2);
    in = new ByteArrayInputStream(decoded);
    Certificate ca2 = cf.generateCertificate(in);
    in.close();

    decoded = Base64.getDecoder().decode(GD_CERT3);
    in = new ByteArrayInputStream(decoded);
    Certificate ca3 = cf.generateCertificate(in);
    in.close();

    String keyStoreType = KeyStore.getDefaultType();
    KeyStore ks = KeyStore.getInstance(keyStoreType);
    ks.load(null, null);
    ks.setCertificateEntry("cert1", ca1);
    ks.setCertificateEntry("cert2", ca2);
    ks.setCertificateEntry("cert3", ca3);


    TrustManagerFactory gdtmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
    gdtmf.init(ks);

    X509TrustManager gdTm = null;
    for (TrustManager tm : gdtmf.getTrustManagers()) 
    {
        if (tm instanceof X509TrustManager) 
        {
            gdTm = (X509TrustManager) tm;
            break;
        }
    }

    TrustManager tms[] = new TrustManager[2];
    tms[0] = gdTm;
    tms[1] = defaultTm;


    try 
    {
         SSLContext sslCtx = SSLContext.getInstance("TLS");
        sslCtx.init(null, tms, new SecureRandom());
    } 
    catch (java.security.GeneralSecurityException e) 
    {
        e.printStackTrace();
        throw e;
    }

     HttpsURLConnection.setDefaultSSLSocketFactory(sslCtx.getSocketFactory());
}

I copied the coded from my working version. so there might be complication error. you just need to work through those.


If u are using below properties while sending mail, then comment it. This works for me. But this might cause security problem.

props.put("mail.smtp.starttls.enable","true");

ReferenceURL : https://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java

반응형