GoDaddy SSL証明書が機能しないJava

Question

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 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月に、これは大きな問題になります。 Godaddyに連絡して、ここでポイントできる人を強くお勧めします。

〜

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証明書があり、しばらくの間（問題なく）配置されています。

私の問題は、587で接続してメールを送信しようとすると、有名な_PKIX path building failed: Sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target_エラーメッセージが表示されることです。

多くのSOリンクおよび通常のgoogle-fuの理解から、これは通常、Javaが証明書またはCAを信頼しない場合に発生します-自己署名証明書では一般的です。チェーンが有効であることを確認するために、いくつかのオンラインSSL証明書チェッカーを使用しました。すべては正常に見えますが... Java証明書を自動的に使用しないでください。

ローカルキーストアに証明書をダウンロードしてセットアップするクラスファイルがSunのどこかにあるので、Javaはそれを信頼します...しかし、これはアプリにとって非実用的であるだけではありません複数のシステムに展開されますが、GoDaddyの署名済み証明書には馬鹿げています。

どうしたの？ Javaサーバーで有効な証明書を使用するwithoutmake Javaすべての証明書を受け入れますか？

編集：私はちょうど私の窓でJavaコントロールパネル（jdk 7のデフォルトのインストール）と、確かに、_Signer CA_の下で発行者：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の問題です（私は彼らとの長いサポートメールがありました）。これらには2つのCAサーバーがあり、1つは_Class 2 CA_と呼ばれ、もう1つは_G2 CA_と呼ばれます。 _Class 2 CA_はすべての_SHA-1_証明書に署名し、_G2 CA_はすべての_SHA-2_証明書に署名します。これが問題の原因です-GoDaddyは新しい_G2 CA_サーバーをデフォルトのJava truststore-デフォルトのJavaインストールが信頼しないようにするGoDaddyが_G2 CA_サーバーをデフォルトのトラストストアに追加するまでの回避策は、証明書を取得するために_SHA-1_を使用して証明書のキーを再生成することです。 _Class 2 CA_サーバーにより、証明書の有効期限が切れるまで（明らかに）GoDaddyのお客様はキーの再生成が無料です。

SnakeDoc · Accepted Answer

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はそれを気にしておらず、何もしません。ブログpost[here][1]by 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月に、これは大きな問題になります。 Godaddyに連絡して、ここでポイントできる人を強くお勧めします。

~~~~

私の最初の投稿/質問は、私のチェーンが機能しなかった理由に関するものでした。セットアップが悪いことが明らかになりました（@Brunoなどからのアドバイスですぐに修正されました-ありがとう）。しかし、修正したチェーンがまだJavaで動作しない場合、はるかに大きな問題が潜んでいることが明らかになりました。しばらく時間がかかりましたが、実際にはGoDaddyに問題があります。

これは実際、GoDaddyの問題です（長い間サポートメールを送ってきました）。

2つのCAサーバーがあり、1つはClass 2 CAと呼ばれ、もう1つは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サーバーを追加する現在の計画がないことを示しています。デフォルトのトラストストア/キーストア。 Javaを使用する予定がある場合は、追加するまでSHA-1 Class 2 CAサーバー署名証明書を取得するようにしてください。

Isaac Potoczny-Jones · Answer

フィクサー氏とウェイン・セイヤーの答えは否定されましたが、実際には正しい回避策を提唱しています。実際、Wayne ThayerはGoDaddyのSSLビジネスをリードしているので、おそらく知っています。中間証明書とともに、証明書チェーンに「GoDaddy G1 to G2 Cross」証明書をインストールする必要があります。

SHA1へのダウングレードは非推奨であり、将来さらに多くの作業が必要になるため、理想的なオプションではありません。幸い、GoDaddyはこの問題を解決するクロスオーバー証明書を提供しています。彼らは、ウェインが複製した指示を投稿し、ここのコメントにを埋めている。

私はこのソリューションをSHA2証明書で個人的にテストしましたが、うまく機能します。キーを再生成してSHA1にダウングレードするよりも、はるかに優れたソリューションです。 SHA2が必要になると、このオプションはとにかく利用できなくなり、新しい証明書なしでJavaツールチェーンがまだ存在する可能性があります。

GoDaddyのサポートによると、2014年7月現在、正しいルート証明書がJava 8の最近のバージョンに含まれており、2014年9月、GoDaddyのWayne Thayer は次の数か月でJavaに追加されました」。ここからダウンロードしたMac OS のJava 8でcacertsファイルを確認しました。実際にSHA2ルート証明書が含まれています。

したがって、チェーンは次のようになります。

Go Daddy Root Certificate Authority – 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 Secure Certificate Authority – 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 Class 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 2964。これは、いわゆる「GoDaddy G1 to G2クロス証明書」です。。
Go Daddy Secure Certificate Authority – 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証明書

参照-この問題を回避策とともに要約した私のブログ投稿。

Mr. Fixer · Answer

Godaddy証明書をJavaで動作させるには、チェーンでそれらの相互証明書を使用して、G2（SHA2）ルートをG1（SHA1）ルートにJavaはリポジトリの更新を決定します。クロス証明書バンドルはここからダウンロードできます：

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

GoDaddy証明書バンドル-G1にクロスするG2にはルートが含まれます

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

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

GoDaddy証明書バンドル-G1にクロスするG2にはルートが含まれます

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

Wayne Thayer · Answer

フィクサー氏は正しい。中間証明書と共に、証明書バンドルファイルに「GoDaddy G1 to G2 Cross」証明書をインストールします。これにより、GoDaddy SHA-2証明書は、Javaを含むSHA-1ルートを認識するクライアントによって信頼されます。このファイルは https://certs.godaddy.com/repository から取得できます。これがインストールされると、Javaは証明書から「 GoDaddy Secure Server証明書（中間証明書）」から「GoDaddy G1 to G2クロス証明書」へGoDaddy SHA-1ルートへ。また、クロス証明書を含むバンドルファイルをリポジトリで見つけることができます。このオプションに関する最後の注意：ルート証明書の署名はチェックされないため、SHA-1ルートに依存している場合でも、これは完全なSHA-2証明書チェーンと同じくらい安全です。

Bruno · Answer

以下のコメントと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

ここで、証明書0は証明書1（罰金）によって発行され、証明書1は証明書2（罰金）によって発行され、証明書2は自己署名されます（これもルートCAです）。

ただし、証明書2は証明書3によって発行されません。証明書3は誤って配置されています（おそらく証明書1と同じです）。これによりチェーンが無効になるため、問題が発生する可能性があります。

少なくとも設定から証明書3を削除する必要があります。さらに、ルートCAを持つ必要がないため、証明書2を削除することもできます（とにかくそれを知るのはクライアント次第です）。

jpereira · Answer

de 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

lanbrown · Answer

「Javaコントロールパネル」で、「セキュアサイトCA」にGdルート証明書を追加しただけで、Javaを使用するときに証明書エラーが発生しなくなりました。追加した証明書は次のとおりです。 Go Daddy Class 2 Certification Authority Root Certificate-G2

Guido Simone · Answer

メールサーバーはGo Daddy Class 2 Certification Authorityによって署名されていないようですが、実際には中間認証局の1つによって署名されているようです。これを自分で確認する必要があります。これが事実だと仮定すると...

理論的には、ソフトウェアは動作するはずです-中間証明書はクラス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クラスを使用して、keytoolを使用せずにJavaコードから直接プライベートキーストアを自動的に更新します。概念的には簡単です-キーストアをファイルからロードします。新しい証明書を読み取り、キーストアに追加してからキーストアを新しいファイルに書き出しますが、詳細を正しく取得するには時間がかかり、単一の証明書をインポートするだけでは面倒な場合があります。

それでも、試してみるのは面白いです。チェックアウト KeyStore JavaDoc およびload、storeおよびsetCertificateEntryメソッドを確認します。

junaid · Answer

試してみてください。実行時に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 + jfBDnCaQJsY1L6d8EbyHSHyLmTGFBUNUtpTrw700ku H9zB0lL7AgMB "+ "AAGjggEaMIIBFjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNV" + "HQ4EFgQUQMK9J47MNIMwojPX + 2yz8LQsgM4wHwYDVR0jBBgwFoAUOpqFBxBnKLbv" + "9r0FQW4gwZTaD94wNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8v" + "b2NzcC5nb2RhZGR5LmNvbS8wNQYDVR0fBC4wLDAqoCigJoYkaHR0cDovL2NybC5n" + "b2RhZGR5LmNvbS9nZHJvb3QtZzIuY3JsMEYGA1UdIAQ/MD0wOwYEVR0gADAzMDEG" + "CCsGAQUFBwIBFiVodHRwczovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkv" + "MA0GCSqGSIb3DQEBCwUAA4IBAQAIfmyTEMg4uJapkEv/oV9PBO9sPpyIBslQj6Zz" +" 91cxG7685C/B + LrTW + C05 + Z5Yg4MotdqY3MxtfWoSKQ7CC2iXZDXtHwlTxFWMMS2" + "RJ17LJ3lXubvDGGqv + QqG + 6EnriDfcFDzkSnE3ANkR/0yBOtg2DZ2HKocyQetawi" + "DsoXiWJYRBuriSUBAA/NxBti21G00w9RKpv0vHP8ds42pM3Z2Czqrpv1KrKQ0U11" + "GIO/ikGQI31bS/6kA1ibRrLDYGCD + H1QQc7CoZDDu + 8CL9IVVO5EFdkKrqeKM + 2X" + "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()); }

作業バージョンからコードをコピーしました。そのため、複雑なエラーが発生する場合があります。あなたはそれらを介して作業する必要があります。

SnakeDoc · Answer

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証明書がデフォルトで信頼されない理由がまだわからないので、修正ではありません...自己署名証明書ではありません。

この問題を本当に理解したいので、誰でも気軽に声をかけてください。