Import certificate java windows

Хранилище ключей и сертификатов

Защита данных в приложениях имеет важное значение, защита конфиденциальной информации — первостепенное. Одним из самых распространённых способов защиты информации во все времена является шифрование данных. Криптография, симметричное и асимметричное шифрование, ключи и сертификаты непосредственно связаны с данной задачей. Используемые для защиты информации ключи и сертификаты также нужно надежно защитить. Для этих целей используется keystore — хранилище сертификатов и ключей.

keystore — это специализированное хранилище секретных данных, которое используется Java-приложениями для шифрования, аутентификации и установки HTTPS соединений. Так, для аутентификации клиента и сервера, устанавливающих SSL (Secure Sockets Layer — уровень защищённых cокетов) соединение, требуются приватные ключи и сертификаты. Если используется односторонняя аутентификация, то keystore используется только на серверной стороне. При двусторонней аутентификации клиент и сервер обмениваются сертификатами; соответственно и у сервера, и у клиента должны быть keystore с парой ключей private/public + сертификат. Иными словами keystore используется для хранения ключей и сертификатов, применяемых для идентификации владельца ключа (клиента или сервера).

Java поддерживает несколько форматов хранилищ keystore :

Каждая запись в keystore имеет уникальный псевдоним (alias). Рекомендуется в keystore не использовать alias’ы, отличающиеся только регистром. В стандартной реализации каждый ключ в хранилище защищается паролем; кроме того, всё хранилище целиком может быть защищено отдельным паролем.

Стандартное хранилище доверенных CA-сертификатов (Certificate Authority) для Java приложений располагается в директории jre/lib/security/cacerts (пароль — changeit).

Информацию в хранилище можно разделить на две категории: ключевые записи (пары ключей private/public) и доверенные сертификаты. Ключевая запись, используемая для криптографических целей, включает идентификационные данные объекта и его закрытый ключ. Доверенный сертификат содержит идентификационные данные объекта и открытый ключ. Запись с доверенным сертификатом не может использоваться в тех случаях, где требуется закрытый ключ.

Чтобы отделить ключевые записи от сертификатов целесообразно использовать различные хранилища : один для собственных ключей, а другой — для доверенных сертификатов, включая сертификаты Центров сертификации (CA). Такой подход позволит реализовать разделение между собственными сертификатами и соответствующими закрытыми ключами, и доверенными сертификатами. Дополнительно можно обеспечить более высокую защиту для закрытых ключей в отдельном keystore с ограниченным доступом, а доверенные сертификаты оставить в более свободном доступе.

В конце статьи представлен Java пример просмотра содерживого хранилища ключей и сертификатов CertificateReader.

Утилита keytool

Для управления парами ключей (private/public), сертификатами и хранилищем keystore Java включает утилиту keytool, располагаемую в директории bin. Для запуска keytool можно использовать командную строку. Опции утилиты позволяют выполнять различные операции и получать определенные сведения. Так, чтобы получить информацию об утилите, можно просто выполнить команду keytool без опций :

Чтобы получить дополнительную справку о команде необходимо указать ее наименование и волшебное слово help. Не забывайте о дефисе ‘-‘ перед опциями :

Создание самоподписанного сертификата

Для создания самоподписанного сертификата также необходимо использовать команду -genkey с указанием срока действия сертификата в опции -validity. Следующая команда создаст пару 2048-битных RSA-ключей, действительных на протяжении 365 дней, с указанным псевдонимом (parent) в заданном файле/хранилище ключей (keystore.jks). Закрытый ключ в хранилище «закрывается» паролем, открытый ключ «оборачивается» в самоподписанный сертификат .

Если заданного хранилища ключей (keystore.jks) не существует, то keytool создаст его. При выполнении команды keytool будет запрашивать некоторые необходимые данные : пароль хранилища, Distinguished Name и пароль закрытого ключа. Многие параметры используются со значениями по умолчанию. Так, например, алиас — mykey, хранилище — .keystore в домашней директории пользователя (HOMEPATH), алгоритм шифрвания — SHA1withDSA и пр.

Distinquished Name

Сертификат создается в формате X.509. В этом формате в качестве идентификатора владельца используется Distinquished Name или просто DN в формате X.500. Этот же формат идентификации объектов используется в LDAP-протоколе или в SNMP. Distinquished Name задается в виде разделенных через запятую атрибутов :

• CN — common name (имя владельца);
• OU — organizational unit or department/division (департамент/отдел);
• O — organization name (наименование организации);
• L — locality or city (город/местоположение);
• ST — state or province;
• C — country, two chars (страна).

Часть из атрибутов могут быть пропущены; в этом случае им будет присвоено значение Unknown.

Одним из важных атрибутов сертификата являются альтернативные имена SAN (SubjectAlternativeName). Подробности и пример внесения SAN в самоподписанный сертификат представлены на странице настройки конфигурации сервера Tomcat.

Параметры сертификата можно указывать в качестве опции команды. Так, в следующем варианте примера задаётся информация о компании, наименование алиаса, тип и размещение хранилища, срок действия, алгоритм для генерации ключей, размер ключа, пароли на хранилище и на ключ.

Новое хранилище было размещено в той же директории, где и располагается keytool.

Создание пары ключей

Для создания пары ключей необходимо использовать команду «-genkeypair». Следующая команда создаст пару ключей «keypair» в хранилище keystore.jks, где размещен созданный ранее сертификат.

Сертификат и закрытый ключ сохранены в виде новой keystore записи, идентифицированной псевдонимом «keypair». Открытый ключ обертывается в формат X.509 — это самоподписанный сертификат, который сохранен как одноэлементная цепочка сертификата.

Опции команды genkeypair

• [-storepass storepass]
• [-keypass keypass] — является паролем, используемым для защиты закрытого ключа
• [-dname dname] — определяет отличительное имя в формате X.500, связанное с псевдонимом и используемое в качестве issuer и subject поля в самоподписанном сертификате
• <-keyalg keyalg>— определяет алгоритм, который будет использоваться, чтобы генерировать пару ключей
• <-keysize keysize>— определяет размер каждого ключа, который будет сгенерирован
• <-sigalg sigalg>— определяет алгоритм, который должен использоваться, чтобы подписать самоподписанный сертификат; алгоритм должен быть совместимым с keyalg
• <-ext ext>*
• <-providerClass provider_class_name <-providerArg provider_arg>>

Создадим еще две пары ключей с псевдонимами «keypair1» и «keypair2», чтобы при просмотре содержимого хранилища (ниже) был небольшой список пар ключей :

Экспорт сертификата

Сертификат можно экспортировать из хранилища и предоставить его пользователям Вашей «подписанной» программы. Тогда пользователи могут занести Ваш сертификат в свое хранилище доверенных сертификатов. Для экспорта сертификата используется команда «exportcert». Следующий пример извлекает из хранилища сертификат в файл «parent.cer» :

Импорт сертификата

Чтобы импортировать сертификат в хранилище, нужно его сначала получить каким-либо образом. Не будем мудрить и извлечем сертификат с псевдонимом veriSignclass1g3ca из хранилища доверенных сертификатов jre\lib\security\cacerts (пароль хранилища changeit). То есть выполним команду экспорта сертификата с указанием соответствующего хранилища :

Экспорт сертификата из хранилища cacerts

Импорт сертификата в хранилище

Чтобы импортировать сертификат в хранилище keystore.jks необходимо использовать команду «importcert». Если в качестве опции указать «-trustcacerts», то сертификат импортируется в хранилище доверенных сертификатов, т.е. в jre\lib\security\cacerts. При выполнении команды импорта утилита keytool попросит ввести пароль хранилища :

Просмотр хранилища

Для чтения содержимого хранилища необходимо использовать команду «-list». В качестве опции «-keystore» можно указать путь к хранилищу. По умолчанию команда «-list» отображает цифровой отпечаток SHA1 сертификата. Следующий код позволяет просмотреть содержимое созданного хранилища, включающего сертификат и три пары ключей :

Опции команды list

Если при просмотре хранилища использовать опцию «-v», то информация о сертификате выводится с дополнительной информацией, включающей владельца, порядковый номер и т.д. При использовании опции «-rfc» содержание сертификата печатается согласно интернет-стандарта RFC-1421.

На странице описания SSL сертификата представлен результат выполнения команды просмотра хранилища keytool -list для опций ‘-v’ и ‘-rfc’.

Полную англоязычную версию документации на keytool можно найти здесь.

Пример просмотра хранилища и сертификата

На скриншоте представлен пример CertificateReader, позволяющий просматривать хранилище ключей и сертификаты, а также извлекать информацию о сертификате.

Внутри сертификата хранится пара значений Distinqueshed Names. Один DN принадлежит владельцу сертификата, а второй DN указывает идентификатор цента сертификации (CA), подписавшего сертификат. В случае с самоподписанным (self-signed) сертификатом, оба эти DN указывают на владельца сертификата.

Листинг примера

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

В листинге примера представлены два метода : loadKeyStore, showCertificate. Первый метод позволяет выбрать хранилище сертификатов. Второй метод выполняет чтение сертификата и представление его параметров в интерфейсе. После листинга представлен скриншот, на котором выполнено чтение созданного сертификата.

Примечание : класс CertificateReader используется в качестве примера на странице цифровой подписи jar файлов

Скачать пример

Рассмотренный на странице пример просмотра хранилища ключей и сертификатов можно скачать здесь (2.5 Кб).

Источник

Import Java Trusted Certificate to JRE

I need to install a certificate from a Java app to a lot of people. I want to use a one click program or batch file to import it as a Trusted Certificate(in Control Panel->Security->Certificate). Then they won’t need to press always allow first time they use the application.

I have extracted the needed certificate as both a .csr and as a .cer (the .csr via Control Panel and the .cer via keytool). Now I need to get one of them back without any clicking in menus.

I don’t really understand the documentation of importing .cer with keytool and would like an example. Or are there an easier way than using keytool?

4 Answers 4

A couple of examples on how to do this using «keytool»

The second link here has an example batch file:

Which part are you having trouble understanding? Is there a particular section that doesn’t make sense? Do you need help with the batch file? Where, specifically, are you getting stuck? Perhaps I can help more specifically.

The chain of trust concept for the Java keytool and signed apps expects the user to confirm trust by taking an affirmative action. In this case the user would import the public key related to the code publisher into their keystore which requires them to have a Java keystore and password related to same. See http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html section stating —

6: Import Certificate as a Trusted Certificate

Ray downloads SSignedApplet.jar and CompanyCer.cer to his home directory. Ray must now >create a keystore database (raystore) and import the certificate into it using the alias >company. Ray uses keytool in his home directory to do this.

This presents a considerable challenge thus the default behavior is to run signed apps with the OK dialog you are trying to address. Remotely accessing/creating Java keystores for others is counter to the security design.

We had a similar problem here trying to avoid certificate acceptance pop ups on signed applets. We found a fix, it’s not pretty, but it seems to have worked so far. Every user has a trusted.certs keystore (depending on OS it’s somewhere under /AppData. Sun/Java/Deployment/trusted.certs ) that is generated the first time they access an applet on the given machine. You can have a startup script replace this file for each user from somewhere central. To create the new trusted.certs file, we have just accepted the certs on a single machine that we want in there, and then copy that entire trusted.certs keystore over to the new machine.

Loading into the central certs keystore for the JRE did not work for us, so we went this other route. It’s ugly, and if you had the password to that keystore you could also set that via batch script as above, but is what we did.

This approach made the most sense to us since it worked on a user by user basis, and since it’s tied to a logon, it allows for centralized administration and mass updates.

In C:\Windows\Sun\Java\Deployment create a file called deployment.config .

The contents of this file should be:

Create another file in the same location called deployment.properties and include this line in deployment.properties:

copy the trusted.certs from a user profile with all of the necessary certs to c:\windows\sun\java\deployments also.

All certs contained int he file will now appear in java control panel under System/Trusted Certificates

you can also do this with most other java properties by including them in the deployment.properties file such as:

The first line sets the property, the second (with .locked at the end) prevents the users from changing the properties in java control panel

you can also manage the site exception list by creating a file in the same location called exception.sites and adding the web addresses to this file (one site per line) and including this line in deployment.properties :

this link will explain most of the configurable properties:

Источник