2012-02-10 3 views
-1

Привет, я немного потерялся и надеюсь, что вы меня уберете отсюда. Я постараюсь быть максимально ясным, так как я действительно не понимаю/знаю, как использовать сертификаты.JBoss/Java и SSL

У меня есть приложение, которое должно связываться с другим, используя webservices и SSL. Мы оба попросили наш главный «Центр сертификации» получить сертификаты. Они послали нам 4 файла и пароль для P12-файла: .csr, .cer, .key, .p12

Вот что я сделал: * Настройка JBoss для использования SSL на 8443 и использовать P12 файл в качестве хранилища ключей Чтобы проверить это, я сделал небольшой класс Java, что обратиться за помощью к веб-сервисы на этом сервере, используя:

props.setProperty("javax.net.ssl.trustStore", "/.../.../certif.p12"); 
props.setProperty("javax.net.ssl.trustStorePassword", "XXXXXXXXX"); 
props.setProperty("javax.net.ssl.trustStoreType", "PKCS12"); 

соединение работает, но я думаю, что я что-то не хватает, как я не использовал другой файлы. Если я отправлю файл .P12 и пароль для приложения, которое должно вызывать мои веб-службы, будет ли это нормально/достаточно?

Редактировать: Я забыл упомянуть, что я должен называть Webservice и в другом приложении, так что это должно быть наоборот, мне нужен только .P12 и передать?

Я читал много вещей об открытом ключе, закрытом ключе, keytool, но сейчас это немного грязно в моей голове. Спасибо за любую информацию!

+0

Возможно, вы захотите больше узнать о различии между хранилищем ключей и доверительным магазином, например [здесь] (http://stackoverflow.com/a/6341566/372643). – Bruno

ответ

2

Они послали нам 4 файла и пароль для P12-файла: .csr, .cer, .key, .p12

В идеале, вы должны генерироваться секретный ключ (в .key) и CSR (в .csr), и CA должен был вернуться с сертификатом (обычно в .cer) на основе CSR, который вы собрали бы вместе, чтобы создать свой файл PKCS №12 (.p12).

На этом этапе вы можете отказаться от CSR. Теперь файл PKCS # 12 должен содержать закрытый ключ, связанный с ним сертификат и, возможно, цепочку сертификатов. Вы можете снова извлечь файлы .key и .cer из этого файла .p12. Я думаю, вам дали все эти файлы из-за того, как они были сгенерированы (с использованием промежуточных файлов) или для удобства, а не для их преобразования.

Терминология Java не идеальна, но хранилище ключей и доверительное хранилище - это два объекта типа хранилища ключей, но с другой целью. Разница между KeyManager и TrustManager (и, таким образом, между javax.net.ssl.keyStore и javax.net.ssl.trustStore) следующим образом (цитата из JSSE ref guide):

TrustManager: Определяет, является ли удаленные аутентификационные данные (и, следовательно, соединение) должны быть доверены.

KeyManager: Определяет, какие учетные данные для аутентификации отправлять на удаленный хост.

Свойства javax.net.ssl.trustStore* являются одним из способов настройки TrustManager. Свойства javax.net.ssl.keyStore* являются одним из способов настройки KeyManager.

Как правило, нет необходимости хранить секретный ключевой материал в хранилище доверия (если вы не используете его также как хранилище ключей). Часто лучше использовать отдельный магазин доверия, который вы сможете свободно копировать на машине, не беспокоясь о утечке секретного ключевого материала. Было бы целесообразно построить новое хранилище ключей (JKS), которое вы использовали бы в качестве доверительного хранилища, используя сертификаты CA (не уверены, были ли вы предоставлены с ними).

Вы не выполняете взаимную аутентификацию, установив только доверительное хранилище (для хранилища ключей нет значений по умолчанию, поэтому им необходимо явно указать эти параметры). Если вы хотите использовать свой клиентский сертификат для подключения к удаленной стороне, вам необходимо установить его в хранилище ключей (например, используя свойства javax.net.ssl.keyStore* так же, как вы сделали это для хранилища доверия).

Вы можете указать хранилище ключей и доверие к тому же файлу .p12. Побочным эффектом является то, что другим соединениям, сделанным вашей службой в других местах (например, https://www.google.com), не будет доверено, поскольку для них не будет CA. Поэтому было бы лучше создать отдельный «хранилище ключей доверия» (JKS может быть проще) для сертификатов CA. Вы можете сделать копию по умолчанию cacerts (в каталоге JRE), импортировать сертификат CA в него и использовать его.

+0

Большое спасибо за этот комментарий, он очень помогает. Если я пойду с «хранилищем ключей и доверием, являющимся файлом .P12», мне придется передать его клиенту с паролем .P12? Разве это не опасно, поскольку файл .P12 содержит закрытый ключ? –

+0

Действительно, вам нужно будет предоставить им пароль (и, таким образом, закрытый ключ): что-то, чего вам следует избегать, конечно. Я бы предложил создать отдельный магазин JKS с сертификатами CA (а не вашим сертификатом или его закрытым ключом). Я сомневаюсь, что эти сертификаты находятся в вашем файле '.cer' (это, вероятно, только ваш сертификат без цепочки), но полная цепочка может находиться в файле' .p12'. Вы также можете легко получить сертификаты CA от СА. Затем импортируйте его в новое хранилище ключей с помощью 'keytool -import'. – Bruno

+0

Спасибо большое, я многое сделал после прочтения вашего ответа, но это дало мне хороший способ. –

2

У меня есть приложение, которое должно связываться с другим с помощью webservices и SSL.

Хорошо, остановитесь здесь. Общайтесь как? Я имею в виду, это только сервер аутентификация, то есть ваше клиентское приложение будет аутентифицировать веб-службу или взаимной аутентификации, а веб-служба также запросит сертификат вашего приложения?

Это важно, поскольку файлы, которые вы представляете по именам, как представляется, предполагают, что последний предполагает, что ожидается взаимная аутентификация, пока ваш код, который вы показываете, устанавливает только SSL-библиотеку для аутентификации сервера.

Поскольку вы не обеспечивают контекст здесь я хотел бы сказать, что:

  • .key имеет секретный ключ
  • .p12 имеет свой секретный ключ вместе с подписанным сертификатом или, возможно, корневой сертификат СА (?)
  • CER может иметь подписанный сертификат или, возможно, сертификат подписи ЦС в суперпользователя, который считается доверенным в домене и , вероятно, также подписал веб-сервис, который вы хотите общаться с сертификатом (хорошо, что есть возможность/догадка здесь, так как вы не сказать много)
  • ксо является ваш запрос на подпись сертификата

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

Что вы делаете в коде, устанавливаете p12 в качестве доверия.

Если вы говорите, что это работает, то аутентификации на стороне сервера не существует, а вы аутентифицируете веб-службу, используя , независимо от того, находится в p12.

В этом случае остальные не нужны для communication.It для вас, чтобы сохранить особенно файл key, так как это может быть вашим личным ключом, и если вы потеряете/кто-то украдет это, то ваш частный сертификат бесполезен/скомпрометирована ,

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

Даже на этот вопрос, я просто пытался сделать обоснованное предположение на основе имен файлов .....

Я надеюсь, что это ставит вас в какой-то трек, чтобы читать.

+0

Спасибо за комментарий, после большего чтения становится ясно, что я должен использовать взаимную аутентификацию. Я нашел эту интересную ссылку https://community.jboss.org/wiki/SSLSetup (глава 2), но они начинают создавать пару открытого/закрытого ключа. Имея уже файл .key с моим личным ключом, я действительно не знаю, как создать связанный открытый ключ, если это способ сделать что-то. –

+0

Ваш открытый ключ находится в вашем сертификате – Cratylus