Подтвердить что ты не робот

GoDaddy SSL Cert не работает с 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 urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

ОБНОВЛЕНИЕ 11/29/2014 - Это все еще проблема, и Годадди, похоже, не заботится и ничего не сделает с этим. Здесь есть блог от Godaddy VP of Security Products от нескольких месяцев назад, говоря, что исправление было на нем и обеспечило временную работу, но на сегодняшний день ничего не изменилось. Важно отметить, что сервер 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: [email protected]

ОБНОВЛЕНИЕ 9/17/2014 - Это все еще проблема, и Годадди, похоже, не заботится и ничего не сделает с этим. Приходите в ноябре, когда Google обесценивает все сертификаты SHA-1, это станет серьезной проблемой. Я очень рекомендую всем, кто может связаться с 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 не является зашифрованным сеансом. Мне нужно использовать TLS на порту 587, для которого требуется сертификат SSL. У меня есть действующий SSL-сертификат на сервере, который подписан GoDaddy G2 CA и уже давно работает (без проблем).

Моя проблема, я получаю знаменитое сообщение об ошибке PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target при попытке подключения и отправки почты на 587.

Из моего понимания многих ссылок SO, а также обычного google-fu, это обычно происходит, когда Java не доверяет сертификату или CA - как это обычно бывает для самозаверяющего сертификата. Я использовал несколько онлайн-сертификатов SSL Cert, чтобы убедиться, что цепь действительна и т.д. Все выглядит нормально... но java не будет использовать сертификат автоматически.

Я знаю, что есть файл класса где-то от Sun, который будет загружать и устанавливать сертификат в локальном хранилище ключей, чтобы java доверял ему... но это не только нецелесообразно для приложения, которое будет развернуто для нескольких систем, но это просто глупо для подписанного сертификата Godaddy.

Что происходит? Как я могу заставить java использовать действительный сертификат на сервере, не делая java принимать все сертификаты?

EDIT: Я просто посмотрел в свои окна Панель управления 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 по-прежнему вызывает одно и то же исключение в отношении пути cert и т.д. Таким образом, похоже, что цепочка сертификатов 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. Rekeying бесплатно для клиентов GoDaddy до истечения срока действия вашего сертификата (очевидно).

4b9b3361

Ответ 1

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 urged you upgrade your JRE/JDK to the latest Java 8 update to resolve this issue.

ОБНОВЛЕНИЕ 11/29/2014 - Это все еще проблема, и Годадди, похоже, не заботится и ничего не сделает с этим. С нескольких месяцев назад Godaddy VP of Security Products опубликовал сообщение в блоге [here][1], в котором говорится, что исправление было на нем и обеспечило временную работу, но на сегодняшний день ничего не изменилось. Важно отметить, что сервер 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: [email protected]

ОБНОВЛЕНИЕ 9/17/2014 - Это все еще проблема, и Годадди, похоже, не заботится и ничего не сделает с этим. Приходите в ноябре, когда Google обесценивает все сертификаты SHA-1, это станет серьезной проблемой. Я очень рекомендую всем, кто может связаться с Godaddy и указать их здесь.

~~~~

Мой первоначальный пост/вопрос касался того, почему моя сеть не работает. Стало очевидным, что у меня была плохая настройка (которая была быстро исправлена ​​с помощью некоторых советов от @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. Rekeying бесплатно для клиентов GoDaddy до истечения срока действия вашего сертификата (очевидно).

Как только у вас есть сертификат SHA-1, подписанный сервером Class 2 CA, ваша цепочка доверия должна работать так, как ожидалось, и не требуется импорт и/или настройка импортного хранилища/хранилища ключей.

Мне не нравится, что я должен использовать "более слабый" сертификат, чтобы заставить его работать правильно, а обсуждения с GoDaddy по электронной почте до сих пор указали, что у них нет текущих планов по добавлению сервера G2 CA в хранилище по умолчанию/хранилище ключей. Я думаю, пока они не добавят его, убедитесь, что вы получили сертификат SHA-1 Class 2 CA, подписанный сервером, если вы планируете работать с Java.

Ответ 2

г. Ответы Фиксера и Уэйна Тайера были приостановлены, но они фактически выступают за правильные обходы. Фактически, Уэйн Тайер возглавляет бизнес GoDaddy SSL, поэтому он, вероятно, знает. Вы должны установить сертификат "GoDaddy G1 в G2 Cross" в цепочке сертификатов вместе с промежуточным сертификатом.

Переход на SHA1 не является идеальным вариантом, поскольку он устарел и заставит вас больше работать в будущем. К счастью, GoDaddy предоставил кроссовер сертификат, который решает эту проблему. Они разместили инструкции, которые Уэйн дублировал, и они были похоронены в комментариях здесь.

Я лично протестировал это решение с сертификатом SHA2, и он работает хорошо. Это намного лучшее решение против повторного набора и понижения до SHA1. Когда SHA2 становится необходимым, эта опция не будет доступна в любом случае, и там все еще могут быть Java toolchains без нового сертификата.

Согласно поддержке GoDaddy, с июля 2014 года правильный корневой сертификат был включен в последние версии Java 8, а в сентябре 2014 года Wayne Thayer of GoDaddy также сказал, что сертификат "планируется добавить в Java в ближайшие несколько месяцев". Я проверил файл cacerts в Java 8 для Mac OS скачанный здесь, и он действительно содержит корневой сертификат SHA2.

Итак, вместо вашей цепочки выглядит так:

  • Go Daddy Root Certificate Authority - G2: (SHA-2) - Hash 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) - Hash 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 Root Certificate Authority - G2: (SHA-2) - Hash 34 0B 28 80 F4 46 FC C0 4E 59 ED 33 F5 2B 3D 08 D6 24 29 64. Это так называемый "GoDaddy G1-G2" Cross Certificate ".
  • Go Daddy Secure Certificate Authority - G2: (SHA-2) - Hash 27 AC 93 69 FA F2 52 07 BB 26 27 CE FA CC BE 4E F9 C3 19 B8
  • Ваш сертификат SHA-2

См. также - мой пост в блоге, обобщающий эту проблему с общими задачами.

Ответ 3

Чтобы получить сертификаты Godaddy для работы на Java с SHA2, вам нужно будет использовать свой кросс-сертификат в своей цепочке, чтобы связать корень G2 (SHA2) с корнем G1 (SHA1), пока Java не решит обновить свой репозиторий. Комплект Cross Certificate можно скачать здесь:

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

Связки сертификатов GoDaddy - G2 С переходом к G1 включает Root

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

Ответ 4

г. Фиксер прав. Установите сертификат "GoDaddy G1 в G2 Cross" в файл пакета сертификатов вместе с промежуточным сертификатом. Это позволяет доверять сертификатам GoDaddy SHA-2 любому клиенту, который распознает корни SHA-1, включая Java. Вы можете получить этот файл из https://certs.godaddy.com/repository. После того, как он будет установлен, Java построит цепочку сертификатов из вашего сертификата в "Сертификат безопасного сервера GoDaddy (промежуточный сертификат)" на "GoDaddy G1 to G2 Cross Certificate" к корню GoDaddy SHA-1. Вы также можете найти файл пакета, содержащий крест-сертификат в нашем репозитории. Последнее замечание по этой опции: Подписи на корневых сертификатах не проверяются, поэтому, даже если вы полагаетесь на корень SHA-1, это так же безопасно, как и полная цепочка сертификатов SHA-2.

Ответ 5

Следующие комментарии и вывод openssl s_client -connect the.server.name:587 -starttls smtp.

В цепочке сертификатов сертификат n должен быть выдан сертификатом n + 1 в списке: эмитент (i) сертификата n должен быть субъектом сертификата 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 выдается сертификатом 1 (штраф), сертификат 1 выдается сертификатом 2 (штраф), cert 2 является самоподписанным (также отлично, это корневой CA).

Однако сертификат 2 не выдается сертификатом 3. Сертификат 3 не применяется (и, вероятно, совпадает с сертификатом 1). Это может вызвать проблемы, так как это делает цепочку недействительной.

Вы должны хотя бы удалить cert 3 из своей конфигурации. Кроме того, вы также можете удалить cert 2, поскольку корневые ЦС не нужны (это все равно, чтобы клиент знал об этом).

Ответ 6

Похоже, ваш почтовый сервер не подписан Go Daddy Class 2 Certification Authority, но фактически подписан одним из их промежуточных органов сертификации. Вам нужно будет убедиться в этом сами. Предполагая, что это так...

Теоретически ваше программное обеспечение должно работать - поскольку промежуточный сертификат подписывается полномочием класса 2, и у вас есть полномочия класса 2 в хранилище сертификатов JDK по умолчанию. Однако я обнаружил, что он просто не работает, если вы также не добавляете промежуточный сертификат в хранилище сертификатов. Вот ссылка на сообщение в блоге, описывающее аналогичный опыт:

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 для автоматического обновления собственного хранилища ключей непосредственно из кода Java без использования keytool. Это концептуально просто - загрузите хранилище ключей из файла, прочитайте новый сертификат, добавьте его в хранилище ключей и затем запишите хранилище ключей в новый файл. Однако для получения подробных сведений требуется некоторое время, и, возможно, не стоит беспокоиться только об импорте одного сертификата.

Тем не менее, интересно попробовать. Оформить заказ KeyStore JavaDoc и прочитать методы load, store и setCertificateEntry.

Ответ 7

В "Панель управления Java" я только что добавил корневой сертификат GD в "Secure Site CA", и у меня больше нет ошибки сертификата при использовании Java. Сертификат, который я добавил, был: Go Daddy Class 2 Certification Authority Корневой сертификат - G2

Ответ 8

если вы импортируете пакет 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

Ответ 9

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");

Я добавил это в мою сессию, и теперь она работает. Это обход, а не исправление imho, поскольку я до сих пор не знаю, почему мой SSL-сертификат Godaddy не пользуется доверием по умолчанию... это не самоподписанный сертификат.

Кто-нибудь, пожалуйста, не стесняйтесь звонить, так как я действительно хотел бы понять эту проблему.

Ответ 10

Вот что вы можете попробовать. Добавьте корневой и промежуточный сертификаты GoDaddy в диспетчер доверия во время выполнения. т.е. начать, если приложение.

статическая конечная строка GD_CERT1 =//"-----BEGIN CERTIFICATE-----" "MIIE0DCCA7igAwIBAgIBBzANBgkqhkiG9w0BAQsFADCBgzELMAkGA1UEBhMCVVMx" + "EDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAYBgNVBAoT" + "EUdvRGFkZHkuY29tLCBJbmMuMTEwLwYDVQQDEyhHbyBEYWRkeSBSb290IENlcnRp" + "ZmljYXRlIEF1dGhvcml0eSAtIEcyMB4XDTExMDUwMzA3MDAwMFoXDTMxMDUwMzA3" + "MDAwMFowgbQxCzAJBgNVBAYTAlVTMRAwDgYDVQQIEwdBcml6b25hMRMwEQYDVQQH" + "EwpTY290dHNkYWxlMRowGAYDVQQKExFHb0RhZGR5LmNvbSwgSW5jLjEtMCsGA1UE" + "CxMkaHR0cDovL2NlcnRzLmdvZGFkZHkuY29tL3JlcG9zaXRvcnkvMTMwMQYDVQQD" + "EypHbyBEYWRkeSBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5IC0gRzIwggEi" + "MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC54MsQ1K92vdSTYuswZLiBCGzD" + "BNliF44v/z5lz4/OYuY8UhzaFkVLVat4a2ODYpDOD2lsmcgaFItMzEUz6ojcnqOv" + "К /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 + С05 + Z5Yg4MotdqY3MxtfWoSKQ7CC2iXZDXtHwlTxFWMMS2" + "RJ17LJ3lXubvDGGqv + q¯qg + 6EnriDfcFDzkSnE3ANkR/0yBOtg2DZ2HKocyQetawi" + "DsoXiWJYRBuriSUBAA/NxBti21G00w9RKpv0vHP8ds42pM3Z2Czqrpv1KrKQ0U11" + "ПИБ /ikGQI31bS/6kA1ibRrLDYGCD + H1QQc7CoZDDu + 8CL9IVVO5EFdkKrqeKM + 2х" + "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) вызывает исключение {

    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());
}

Я скопировал код из моей рабочей версии. так что может быть ошибка усложнения. вам просто нужно проработать это.

Ответ 11

Если вы используете ниже свойства при отправке почты, прокомментируйте это. Это работает для меня. Но это может вызвать проблему безопасности.

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