Java клиентская аутентификация сертификата HTTPS
Не возможно получить 'истинные' случайные числа, компьютер является логической конструкцией, которая не может возможно создать 'действительно' случайный ничто, только псевдослучайное. Существуют лучшие и худшие псевдослучайные алгоритмы там, как бы то ни было.
для получения 'действительно' случайного числа, Вам нужен физический случайный источник, некоторым игровым автоматам на самом деле встроили их - часто это - радиоактивный источник, радиоактивный распад (который, насколько я знаю, действительно случайны), используется для генерации чисел.
2 ответа
Наконец-то удалось решить все проблемы, поэтому я отвечу на свой вопрос. Это настройки / файлы, которые я использовал для решения моей конкретной проблемы;
Клиентское хранилище ключей представляет собой файл PKCS # 12 в формате , содержащий
- открытый сертификат клиента (в данном случае подписанный самоподписанным ЦС)
- закрытый ключ клиента
Для его создания я использовал OpenSSL pkcs12 , например;
openssl pkcs12 -export -in client.crt -inkey client.key -out client.p12 -name "Whatever"
Совет: убедитесь, что у вас установлена последняя версия OpenSSL, не версии 0.9.8h, потому что в ней есть ошибка, которая не позволяет вам правильно сгенерировать файлы PKCS # 12.
Этот файл PKCS # 12 будет использоваться клиентом Java для представления сертификата клиента серверу, когда сервер явным образом запросил у клиента аутентификацию. См. статью в Википедии о TLS для обзора того, как на самом деле работает протокол аутентификации сертификата клиента (также объясняется, почему нам здесь нужен закрытый ключ клиента).
клиентское хранилище доверенных сертификатов представляет собой прямой файл формата JKS , содержащий корневой или промежуточный сертификат CA . Эти сертификаты CA будут определять, с какими конечными точками вам будет разрешено связываться, в этом случае он позволит вашему клиенту подключиться к любому серверу, который представляет сертификат, подписанный одним из центров сертификации доверенного хранилища.
Для его создания вы можете использовать, например, стандартный Java keytool;
keytool -genkey -dname "cn=CLIENT" -alias truststorekey -keyalg RSA -keystore ./client-truststore.jks -keypass whatever -storepass whatever
keytool -import -keystore ./client-truststore.jks -file myca.crt -alias myca
Используя это хранилище доверенных сертификатов, ваш клиент попытается выполнить полное установление связи SSL со всеми серверами, которые представляют сертификат, подписанный центром сертификации, идентифицированным myca.crt .
Указанные выше файлы предназначены только для клиента. Если вы также хотите настроить сервер, ему нужны собственные файлы ключей и доверенных сертификатов. Отличное пошаговое руководство по настройке полностью рабочего примера для клиента и сервера Java (с использованием Tomcat) можно найти на этом веб-сайте .
Проблемы / Замечания / Советы
- Проверка подлинности сертификата клиента может выполняться только сервером.
- ( Важно! ) Когда сервер запрашивает сертификат клиента (как часть подтверждения TLS), он также предоставляет список доверенных центров сертификации. s как часть запроса сертификата. Когда сертификат клиента, который вы хотите представить для аутентификации, не подписан одним из этих центров сертификации, он вообще не будет представлен (на мой взгляд, это странное поведение, но я уверен, что есть причина этого). Это было основной причиной моих проблем, поскольку другая сторона не настроила свой сервер должным образом для приема моего самоподписанного клиентского сертификата, и мы предположили, что проблема была на моей стороне из-за того, что я не предоставил должным образом сертификат клиента в запросе.
- Загрузите Wireshark. Он имеет отличный анализ пакетов SSL / HTTPS и будет огромным подспорьем при отладке и поиске проблемы. Он похож на
-Djavax.net.debug = ssl, но более структурирован и (возможно) легче интерпретируется, если вам неудобны выходные данные отладки Java SSL. Это ' Вполне возможно использовать библиотеку Apache httpclient. Если вы хотите использовать httpclient, просто замените целевой URL-адрес на эквивалент HTTPS и добавьте следующие аргументы JVM (которые одинаковы для любого другого клиента, независимо от библиотеки, которую вы хотите использовать для отправки / получения данных через HTTP / HTTPS) :
-Djavax.net.debug = ssl -Djavax.net.ssl.keyStoreType = pkcs12 -Djavax.net.ssl.keyStore = client.p12 -Djavax.net.ssl.keyStorePassword = что угодно -Djavax.net.ssl.trustStoreType = jks -Djavax.net.ssl.trustStore = client-truststore.jks -Djavax.net.ssl.trustStorePassword = something
Их JKS-файл - это просто контейнер для сертификатов и пар ключей. В сценарии аутентификации на стороне клиента различные части ключей будут расположены здесь:
- Хранилище клиента будет содержать пару ключей частного и открытого клиента. Он называется хранилищем ключей .
- Хранилище сервера будет содержать открытый ключ клиента. Он называется хранилищем доверенных сертификатов .
Разделение хранилища доверенных сертификатов и хранилища ключей не является обязательным, но рекомендуется. Они могут быть одним и тем же физическим файлом.
Чтобы установить расположение файловой системы двух хранилищ, используйте следующие системные свойства:
-Djavax.net.ssl.keyStore=clientsidestore.jks
и на сервере:
-Djavax.net.ssl.trustStore=serversidestore.jks
Чтобы экспортировать сертификат клиента (открытый ключ) в файл , чтобы вы могли скопировать его на сервер, используйте
keytool -export -alias MYKEY -file publicclientkey.cer -store clientsidestore.jks
Чтобы импортировать открытый ключ клиента в хранилище ключей сервера, используйте (как упоминалось на плакате, это уже было сделано администраторами сервера)
keytool -import -file publicclientkey.cer -store serversidestore.jks