Еще не ответ, но это слишком сложно для комментариев, поэтому я начну и отредактирую позже.
Должны ли (SSL / TLS) сервер (ы) и клиент (ы) совместно использовать ключ (и сертификат)? Подходит для разработки и, возможно, тестирования, зависит от производства. Как правило, каждая независимая система, которая должна быть аутентифицирована, должна иметь свой собственный закрытый ключ и сертификат для этого ключа (или иногда, но редко, несколько сертификатов). Если обе (или, в более общем смысле, все) задействованные системы и связь между ними будут находиться под контролем одного и того же администратора, не повредит ослабить это правило и (повторно) использовать один ключ + сертификат. Поскольку используемый ключ + сертификат (ы) всегда должен быть (пере) настраиваемым, это решение вы можете изменить позже, даже изменить несколько раз, если это окажется желательным или необходимым.
Должны ли сертификаты быть самоподписанными? Обычно подходят для разработки и тестирования, но могут отличаться для производственной среды. Опять же, если все соответствующие системы находятся под контролем одного администратора или, по крайней мере, ограниченной группы людей, которые знают друг друга (например, подразделения или офисы одной организации), ЦС не нуждается в реальной безопасности для проверки личности и определения доверия. Одно из соображений заключается в том, что сертификат сервера должен кодировать доменное имя (а) (или IP-адрес (а), если вы используете эту опцию) в сертификате, поэтому их изменение, которое часто требуется при разработке и тестировании, означает возврат к CA для получения нового сертификата, по крайней мере, незначительное неудобство, а иногда и задержка.
На данный момент у вас есть один ключ и самоподписанный сертификат, которым вы пытаетесь поделиться как для клиента, так и для сервера. Хотя вы, возможно, захотите изменить их позже, я бы порекомендовал сначала сосредоточиться на том, чтобы что-нибудь заработало. Изменение нескольких взаимосвязанных вещей одновременно может вызвать путаницу.
«Извлечь» сертификат? Для текущей настройки с одним (общим) ключом + сертификатом (самоподписанным) у вас уже есть ключ + сертификат в JKS, тот же ключ + сертификат в P12, и тот же сертификат в файле (cert.crt), поэтому вам не нужно ничего извлекать. Если вы (позже) сгенерируете для стороны Java (клиента) новый ключ и самоподписанный сертификат с помощью keytool, да, вам нужно будет извлечь этот сертификат. Если вы получаете сертификат, подписанный ЦС, для существующего или нового ключа, вам может потребоваться извлечь корень / якорь, но, возможно, он у вас уже есть, см. Ниже.
Какому сертификату (сертификатам) необходимо доверять? Клиенту всегда (с небольшими исключениями, не имеющими отношения к данному случаю) всегда требуется в своем хранилище доверенных сертификатов привязка для сертификата сервера, а при аутентификации клиента (также называемый двусторонним или двусторонним) используется, поскольку в вашем случае серверу требуется в своем хранилище доверенных сертификатов привязка для сертификата клиента. В вашем текущем случае клиент и сервер используют один и тот же сертификат, поэтому обеим сторонам нужен один и тот же якорь.
Для самозаверяющего сертификата привязкой должен быть сам сертификат, который необходимо изменять, обычно вручную, при каждом изменении партнерского сертификата. .
Для сертификата, выданного ЦС, привязкой может быть и (всегда?) Должен быть корневой сертификат для этого ЦС; корень CA обычно долговечен (например, 20 лет и более) и не нуждается в изменении, когда это делает сертификат партнера / организации.
Если вы используете хорошо известный ЦС, такой как Verisign или GoDaddy, в отличие от ЦС, управляемого вами или, возможно, «Магазином спиртных напитков и центром сертификации Joe's Dicount» в вашем местном районе красных фонарей, в некоторых system, корни для этих хорошо известных центров сертификации могут быть уже установлены, и в этом случае вам не нужно ничего делать.
Каким образом клиент доверял серверу? Очевидно, ваш Java-клиент использовал файл client.jks как хранилище ключей и как хранилище доверенных сертификатов. Это может легко сработать, потому что Java использует один формат файла, который может содержать оба типа данных, и дополнительно обрабатывает сертификат в записи с собственным ключом как также доверенный сертификат (привязку).
А как насчет хранилища доверенных сертификатов сервера? С другой стороны, программное обеспечение, которое использует формат pkcs12 для хранилища ключей или, по крайней мере, для импорта записи хранилища ключей, иногда (я бы сказал, что часто ) не использует тот же формат для своего хранилища доверенных сертификатов и, конечно же, не те же файлы. Тот факт, что он действительно отклонил использование клиентом того же сертификата, который у него уже есть, в качестве собственного вероятно означает, что он не обрабатывает pkcs12, который вы ему предоставили, как данные хранилища доверенных сертификатов, хотя в в принципе, ему может не нравиться что-то еще, например, отсутствие расширения ExtendedKeyUsage или недоступность данных отзыва / статуса.
Вы не идентифицируете и не описываете устройство, которое является вашим сервером, поэтому я могу только догадываться о множестве способов, которыми могут работать серверы SSL / TLS, особенно встроенные. Но где-то на вашем устройстве есть вероятно способ добавить сертификаты в его хранилище доверенных сертификатов. Также у него должен быть какой-то журнал ошибок, который может содержать дополнительную информацию о том, нужен ли ему якорь (здесь самоподписанный сертификат) в хранилище доверенных сертификатов или что-то еще - если вы видите этот журнал без аутентификации SSL / TLS!
Если вы можете предоставить нам (ссылку на) документ на вашем сервере / устройстве или достаточно подробно рассказать нам, что он показывает, предлагает и / или принимает, я, вероятно, могу быть более конкретным.
person
dave_thompson_085
schedule
19.06.2015
