Блог

Я использую самозаверяющий сертификат для подключения по протоколу HTTPS к серверу Axis2 и обратно. Все эти соединения работают нормально и по желанию.

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

Проблема в том, что когда я пытаюсь отправить почту с использованием SSL-соединения, я получаю ошибку сертификата, т.Е. Сертификат GMail не является доверенным. Я также столкнулся с аналогичной проблемой с JBoss. На этот раз я смог обойти эту проблему, загрузив сертификат GMail, а затем импортировав его в хранилище ключей с помощью утилиты Keytool. Долгое время это работало.

Но только недавно я снова начал сталкиваться со старой проблемой. Я попытался использовать старую технику, которая исправила проблему в прошлый раз, но на этот раз это не сработало. (не уверен, почему)

Я считаю, что GMail использует подписанный сертификат, которому из коробки должен доверять любой из серверов, пусть это будет JBoss или Axis2. Я не могу понять, в чем проблема на самом деле. Это из-за использования самозаверяющего сертификата? Или есть какой-то конкретный способ его создания, чтобы подписанные сертификаты были доверенными?

Спасибо за помощь.

Чтобы иметь связь между сервером и клиентом, зашифрованную SSL, нам нужны хранилища ключей и Truststore для сервера и клиента. Ниже приведены шаги по их созданию.

 #Creating Server keystore and exporting a certificate
keytool -genkey -alias serverkeys -keyalg RSA -keystore server.keystore -storepass changeit -keypass changeit -dname "CN=test.com, OU=Test, O=Test, L=London, ST=London, C=UK"
keytool -export -alias serverkeys -keystore server.keystore -storepass changeit -file server.cer

#Creating Client keystore and exporting a certificate
keytool -genkey -alias clientkeys -keyalg RSA -keystore client.keystore -storepass changeit -keypass changeit -dname "CN=test.com, OU=test, O=test, L=London, ST=London, C=UK"
keytool -export -alias clientkeys -keystore client.keystore -storepass changeit-file client.cer

#Making a copy of cacerts file. These copies will be used for client/server truststore
cp /usr/java/jdk1.6.0_14/jre/lib/security/cacerts client.truststore
cp /usr/java/jdk1.6.0_14/jre/lib/security/cacerts server.truststore

#Copying server certificate to Client truststore
keytool -import -trustcacerts -v -keystore client.truststore -storepass changeit -file server.cer

#Copying Client certificate to Server truststore
keytool -import -trustcacerts -v -keystore server.truststore -storepass changeit -file client.cer
  

В течение первых нескольких итераций я не использовал cacert, а напрямую создавал хранилища доверия из сертификата, и это тоже работало хорошо. Проблемы возникали, когда нам нужно было подключиться к некоторым другим службам с использованием SSL, и соединение не могло быть установлено, даже если служба использовала подписанный сертификат.

Например, подключение к SMTP-серверу GMail не удалось бы, если бы хранилище доверия не было создано из cacerts. Причина в том, что, хотя GMail использует подписанный сертификат, мы будем использовать хранилище доверия, которое не будет знать, можно ли доверять сертификату GMail. По этой причине мы использовали cacerts для создания хранилища доверия. После чего мы смогли подключить любую службу, использующую подписанный сертификат.

Если в случае, если мы столкнемся с неподписанным сертификатом, нам придется добавить их в хранилище доверия компонентов.