Keystore в Java
Keystore используется для хранения собственных приватных ключей и сертификатов сервера или клиента.
Для аутентификации клиента и сервера устанавливающих SSL соединение требуются приватные ключи и сертификаты. Если используется односторонняя аутентификация, то keystore нужен только на серверной стороне. При двусторонней аутентификации и клиент и сервер обмениваются сертификатами, соответственно и у сервера, и у клиента должен быть keystore с парой приватный ключ/публичный ключ + сертификат.
Т.е. иными словами Keystore используется для хранения ключей и сертификатов, использующихся для идентификации владельца ключа (клиента или сервера).
Trust Store
Второй тип keystore применяется для хранения trusted сертификатов. В него кладутся ключи trusted certificate authorities CA. При пользовании самоподписанными сертификатами, в trusted store может класться самоподписанный сертификат. Это тоже keystore, но в Java он называется trusted store.
Форматы Keystore поддерживаемые Java
Т.о., как описано выше, keystore — контейнер, используемый для хранения ключей и сертификатов. Java поддерживает два формата keystore:
- JKS (Java Key Store) – Java format
- PKCS12 — this is an industry standard
Тип keystore, используемый по-умолчанию, задается в Java security properties файле свойством keystore.type. Если приложение обращается к key store файлу без явного указания его типа, используется JKS формат. Java security properties файл расположен в каталоге lib внутри инсталляционного директория с Java по пути: /lib/security/java.security
Для работы с keystore в java дистрибутиве есть специальная утилита keytool. Keytool вполне достаточно для операций с ключами в Java. Однако JKS формат является пропиетарным и закрытым. Поэтому часто для разнообразных конвертаций и взаимодействия со сторонними разработчиками могут использоваться утилиты, поставляемые в комплекте с библиотекой OpenSSL.
В тех случаях, когда планируется использовать ключи исключительно в Java keystore в формате JKS вполне подойдет.
Алиасы
Keystore (по крайней мере в JKS формате), позволяет хранить несколько пар ключей и сертификатов. Для идентификации каждой пары или отдельного сертификата используется алиас. Алиас указывается в исходном коде при доступе к соответствующему ключу или сертификату. Доступ к каждому алиасу ограничивается паролем.
Создание keystore
Процесс генерации keystore (JKS или PKS12) включает генерацию пары ключей (приватного и публичного). Затем получение от Certificate Authority (CA) подписи к публичному ключу и связанной с ним идентифицирующей информации в виде сертификата. Certificate authority генерирует сертификат на основе публичного ключа и идентификационной информации, переданной ему в виде CSR.
Wikipedia говорит, что CA выдает сертификат, привязывающий публичный ключ к указанному Distinguished Name (это может быть имя хоста (hostname, имя пользователя или название приложения). Шаги по созданию keystore представляющего пользователя, приложение или хост следующие:
- Сгенерировать пару ключей (public / private key)
В java при генерации пары ключей с помощью keytool сразу создается самоподписанный self-signed сертификат, который можно немедленно использовать для тестирования. Следующие шаги, таким образом, нужны только для создания полноценного официального сертификата.
- Сгенерировать запрос на получение сертификата (Certificate Signing Request (CSR)).
- Получить CSR, подписанный доверенным CA (output of this is a certificate)
- Импортировать сертификат, сделанный CA в ваш key store.
- Импортировать сертификат CA в ваш truststore как trusted certificate
Java’s Default Keystore
Веб-сервер или приложение может сказать Java использовать заданный keystore файл установкой свойства javax.net.ssl.keyStore. (указывается путь к файлу keystore). Если приложение не укажет keystore property, тогда загружается keystore по-умолчанию. Keystore по-умолчанию хранится в файле .keystore в пользовательском домашнем директории, определяемом в свою очередь системным свойством user.home.
Java’s Default Truststore
Приложение может указать Java использовать определенный truststore файл установкой свойства javax.net.ssl.trustStore. Если приложение не указывает явно truststore, тогда truststore по-умолчанию загружается и используется. По-умолчанию java truststore находится в /lib/security/cacerts и его пароль по-умолчанию: ‘changeit’. Файлы truststore — обычные keystore файлы, содержащие один или более сертификатов trusted CA (Certificate Authorities).
Keytool
Для облегчения создания и управления keystore файлами в дистрибутив Java входит утилита keytool, позволяющая создавать JKS файлы. Keytool позволяет управление сертификатами и парами публичных приватных ключей.
С опцией -genkey, keytool генерирует новую пару public/private ключей, и для public ключа создает self-signed сертификат.
keytool -genkey -keystore server.jks -dname "CN=localhost, OU=dev64, O=dev64-wordpress, L=Unknown, ST=Unknown, C=RU" -storepass storepass -alias server-test -keypass serverpass Сертификат создается в формате X.509. В этом формате в качестве идентификатора владельца используется Distinquished Name или просто DN в формате X.500. Точно такой же формат идентификации объектов используется, например в LDAP-протоколе или в SNMP. Distinquished Name задается в виде разделенных через запятую атрибутов: «CN=Andrey Chesnokov, OU=dev64, O=dev64-wordpress, L=Unknown, ST=Unknown, C=RU». Здесь отдельные атрибуты расшифровываются так:
- CN — common name имя владельца
- OU — organizationUnit (e.g, department or division) департамент или отдел
- O — organizationName — large organization name, e.g., «ABCSystems, Inc.»
- L — localityName — locality (city) name, e.g., «Palo Alto» местоположение (город)
- ST — stateName — state or province name, e.g., «California»
- C — country — two-letter country code, e.g., «CH»
Часть из атрибутов могут быть пропущены, в данном случае им присвоено значение Unknown. При генерации тестового keystore, значения можно присваивать любые. При получении официального сертификата, данные регламентируются и проверяются Certificate Authority организацией.
Внутри каждого сертификата в формате X.509 хранится пара Distinqueshed Names (DN), один DN принадлежит владельцу сертификата, а второй DN указывает идентификатор CA, подписавшей сертификат. В случае с self-signed сертификатом, оба эти DN указывают на владельца сертификата.
Distinquished Name задается keytool с помощью опции -dname. Если опцию dname не указать, тогда keytool запросит все необходимые поля из командной строки.
Опция keystore задает имя keystore файла. Если её пропустить, тогда keytool создаст файл с именем .keystore в домашнем директории пользователя.
Доступ к keystore защищается паролем. Соответственно опция -keypass указывает пароль для доступа к keystore целиком. Этот пароль необходим для возможности чтения или модификации keystore.
Второй пароль, как уже говорилось выше, необходим для доступа к отдельному алиасу внутри keystore. Этот второй пароль указывается с помощью опции -keypass.
Т.о. с помощью одной команды получается keystore с парой ключей и сертификатом, остается этот keystore взять и подложить в нужный каталог к своей программе. Но это уже другая история.
Обязательно стоит почитать официальную документацию на keytool, она содержит много полезного.
Keytool Oracle documentation (http://docs.oracle.com/javase/1.4.2/docs/tooldocs/windows/keytool.html) Некоторые команды для работы с сертификатами:
keytool -list -keystore server.jks Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 1 entry server-test, Apr 9, 2015, PrivateKeyEntry, Certificate fingerprint (SHA1): E3:3F:3B:D9:3B:4E:34:8E:D2:D5:D5:B6:9E:C2:86:57:DE:4D:A8:A9 keytool -export -keystore server.jks -alias server-test -storepass storepass -file server.cer Certificate stored in file keytool -import -keystore clienttrust.jks -file server.cer -storepass storepass Owner: CN=localhost, OU=dev64, O=dev64-wordpress, L=Unknown, ST=Unknown, C=RU Issuer: CN=localhost, OU=dev64, O=dev64-wordpress, L=Unknown, ST=Unknown, C=RU Serial number: 16797d2 Valid from: Thu Apr 09 11:54:14 UTC 2015 until: Wed Jul 08 11:54:14 UTC 2015 Certificate fingerprints: MD5: 72:A0:86:C9:DE:9A:E4:0C:99:B0:F9:80:F8:C4:D3:A9 SHA1: E3:3F:3B:D9:3B:4E:34:8E:D2:D5:D5:B6:9E:C2:86:57:DE:4D:A8:A9 SHA256: CC:66:89:7E:76:F4:C8:35:26:D7:E3:88:27:33:96:19:22:59:7D:63:13:D5:14:11:87:C6:80:4E:05:7B:CB:DA Signature algorithm name: SHA1withDSA Version: 3 Extensions: #1: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: E2 20 A1 7F 0C 55 A4 18 43 25 73 17 CE E4 E8 72 . . U..C%s. r 0010: 93 73 F4 00 .s.. ] ] Trust this certificate? [no]: y Certificate was added to keystore Tags: Keystore в Java
javadev.ru
Opensource проект с кодами BitBucket. Желающие могут поучавствовать в его развитии.
Группа в телеграм: javadev_ru
Хранилище ключей и сертификатов
Защита данных в приложениях имеет важное значение, защита конфиденциальной информации — первостепенное. Одним из самых распространённых способов защиты информации во все времена является шифрование данных. Криптография, симметричное и асимметричное шифрование, ключи и сертификаты непосредственно связаны с данной задачей. Используемые для защиты информации ключи и сертификаты также нужно надежно защитить. Для этих целей используется keystore — хранилище сертификатов и ключей.
keystore — это специализированное хранилище секретных данных, которое используется Java-приложениями для шифрования, аутентификации и установки HTTPS соединений. Так, для аутентификации клиента и сервера, устанавливающих SSL (Secure Sockets Layer — уровень защищённых cокетов) соединение, требуются приватные ключи и сертификаты. Если используется односторонняя аутентификация, то keystore используется только на серверной стороне. При двусторонней аутентификации клиент и сервер обмениваются сертификатами; соответственно и у сервера, и у клиента должны быть keystore с парой ключей private/public + сертификат. Иными словами keystore используется для хранения ключей и сертификатов, применяемых для идентификации владельца ключа (клиента или сервера).
Java поддерживает несколько форматов хранилищ keystore :
| • jks | — стандартный тип хранилища в виде файла с расширением jks («java key storage»); устанавливается по умолчанию и, поэтому, применяется наиболее часто. |
| • jceks | — альтернативная реализация хранилища, которая использует более сильное шифрование на основе triple DES; можно обновить имеющееся jks-хранилище до jceks соответствующей командой утилиты keytool. |
| • pkcs12 | — тип хранилища, предназначенный прежде всего для хранения или переноса закрытых ключей пользователя, сертификатов и пр. |
Каждая запись в 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 без опций :
C:\Program Files\Java\jre1.8.0_121\bin>keytool Key and Certificate Management Tool Commands: -certreq Generates a certificate request -changealias Changes an entry's alias -delete Deletes an entry -exportcert Exports certificate -genkeypair Generates a key pair -genseckey Generates a secret key -gencert Generates certificate from a certificate request -importcert Imports a certificate or a certificate chain -importpass Imports a password -importkeystore Imports one or all entries from another keystore -keypasswd Changes the key password of an entry -list Lists entries in a keystore -printcert Prints the content of a certificate -printcertreq Prints the content of a certificate request -printcrl Prints the content of a CRL file -storepasswd Changes the store password of a keystore Use "keytool -command_name -help" for usage of command_name
Чтобы получить дополнительную справку о команде необходимо указать ее наименование и волшебное слово help. Не забывайте о дефисе ‘-‘ перед опциями :
C:\Program Files\Java\jre1.8.0_121\bin>keytool -certreq -help keytool -certreq [OPTION]. Generates a certificate request Options: -alias alias name of the entry to process -sigalg signature algorithm name -file output file name -keypass key password -keystore keystore name -dname distinguished name -storepass keystore password -storetype keystore type . . . -providerarg provider argument -providerpath provider classpath -v verbose output -protected password through protected mechanism Use "keytool -help" for all available commands
Создание самоподписанного сертификата
Для создания самоподписанного сертификата также необходимо использовать команду -genkey с указанием срока действия сертификата в опции -validity. Следующая команда создаст пару 2048-битных RSA-ключей, действительных на протяжении 365 дней, с указанным псевдонимом (parent) в заданном файле/хранилище ключей (keystore.jks). Закрытый ключ в хранилище «закрывается» паролем, открытый ключ «оборачивается» в самоподписанный сертификат .
keytool -genkey -alias parent -keyalg RSA -validity 365 \ -keystore 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.
Параметры сертификата можно указывать в качестве опции команды. Так, в следующем варианте примера задаётся информация о компании, наименование алиаса, тип и размещение хранилища, срок действия, алгоритм для генерации ключей, размер ключа, пароли на хранилище и на ключ.
C:\Program Files\Java\jdk1.8.0_121\bin> \ keytool -v -genkey -dname "CN=java-online.ru, \ OU=Developers, O=IT Systems Inc., L=Moscow, C=RF" \ -alias parent -storetype jks -keystore keystore.jks \ -validity 365 -keyalg RSA -keysize 2048 \ -storepass mystorepass -keypass mykeypass Generating 2 048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 365 days for: CN=java-online.ru, OU=Developers, O=IT Systems Inc., L=Moscow, C=RF [Storing keystore.jks]
Новое хранилище было размещено в той же директории, где и располагается keytool.
Создание пары ключей
Для создания пары ключей необходимо использовать команду «-genkeypair». Следующая команда создаст пару ключей «keypair» в хранилище keystore.jks, где размещен созданный ранее сертификат.
C:\Program Files\Java\jdk1.8.0_121\bin> \ keytool -alias keypair -genkeypair -keystore keystore.jks \ -dname "CN=java-online.ru" Enter keystore password: Enter key password for (RETURN if same as keystore password):
Сертификат и закрытый ключ сохранены в виде новой keystore записи, идентифицированной псевдонимом «keypair». Открытый ключ обертывается в формат X.509 — это самоподписанный сертификат, который сохранен как одноэлементная цепочка сертификата.
Опции команды genkeypair
- [-storepass storepass]
- [-keypass keypass] — является паролем, используемым для защиты закрытого ключа
- [-dname dname] — определяет отличительное имя в формате X.500, связанное с псевдонимом и используемое в качестве issuer и subject поля в самоподписанном сертификате
- — определяет алгоритм, который будет использоваться, чтобы генерировать пару ключей
- — определяет размер каждого ключа, который будет сгенерирован
- — определяет алгоритм, который должен использоваться, чтобы подписать самоподписанный сертификат; алгоритм должен быть совместимым с keyalg
- *
- >
Создадим еще две пары ключей с псевдонимами «keypair1» и «keypair2», чтобы при просмотре содержимого хранилища (ниже) был небольшой список пар ключей :
keytool -alias keypair1 -genkeypair -keystore keystore.jks \ -dname "CN=java-online.ru" keytool -alias keypair2 -genkeypair -keystore keystore.jks \ -dname "CN=java-online.ru"
Экспорт сертификата
Сертификат можно экспортировать из хранилища и предоставить его пользователям Вашей «подписанной» программы. Тогда пользователи могут занести Ваш сертификат в свое хранилище доверенных сертификатов. Для экспорта сертификата используется команда «exportcert». Следующий пример извлекает из хранилища сертификат в файл «parent.cer» :
C:\Program Files\Java\jdk1.8.0_121\bin> \ keytool -exportcert -keystore keystore.jks \ -alias parent -file parent.cer Enter keystore password: Certificate stored in file
Импорт сертификата
Чтобы импортировать сертификат в хранилище, нужно его сначала получить каким-либо образом. Не будем мудрить и извлечем сертификат с псевдонимом veriSignclass1g3ca из хранилища доверенных сертификатов jre\lib\security\cacerts (пароль хранилища changeit). То есть выполним команду экспорта сертификата с указанием соответствующего хранилища :
Экспорт сертификата из хранилища cacerts
C:\Program Files\Java\jdk1.8.0_121\bin> keytool -exportcert -alias veriSignclass1g3ca -keystore \ «C:\Program Files\Java\jdk1.7.0_67\jre\lib\security\cacerts» \ -file veriSignclass1g3ca.cer Enter keystore password: Certificate stored in file
Импорт сертификата в хранилище
Чтобы импортировать сертификат в хранилище keystore.jks необходимо использовать команду «importcert». Если в качестве опции указать «-trustcacerts», то сертификат импортируется в хранилище доверенных сертификатов, т.е. в jre\lib\security\cacerts. При выполнении команды импорта утилита keytool попросит ввести пароль хранилища :
C:\Program Files\Java\jdk1.8.0_121\bin> \ keytool -importcert -keystore keystore.jks \ -file veriSignclass1g3ca.cer Enter keystore password: \ Owner: \ CN=VeriSign Class 1 Public Primary Certification Authority - G3, \ OU="(c) 1999 VeriSign, Inc. - For authorized use only", \ OU=VeriSign Trust Network, \ O="VeriSign, Inc.", \ C=USIssuer: \ CN=VeriSign Class 1 Public Primary Certification Authority - G3, \ OU="(c) 1999 VeriSign, Inc. - For authorized use only", \ OU=VeriSign Trust Network, \ O="VeriSign, Inc.", \ C=US \ Serial number: 8b5b75568454850b00cfaf3848ceb1a4 \ Valid from: \ Fri Oct 01 04:00:00 MSD 1999 until: Thu Jul 17 02:59:59 MSK 2036 \ Certificate fingerprints: \ MD5: B1:47:BC:18:57:D1:18:A0:78:2D:EC:71:E8:2A:95:73 \ SHA1: 20:42:85:DC:F7:EB:76:41:95:57:8E:13:6B:D4:B7:D1:E9:8E:46:A5 \ SHA256: CB:B5:AF:18:5E:94:2A:24:02:F9:EA:CB:C0:ED:5B:B8:76:EE:A3: \ C1:22:36:23:D0:04:47:E4:F3:BA:55:4B:65 Signature algorithm name: SHA1withRSA Version: 1 \ Trust this certificate? [no]: y Certificate was added to keystore
Просмотр хранилища
Для чтения содержимого хранилища необходимо использовать команду «-list». В качестве опции «-keystore» можно указать путь к хранилищу. По умолчанию команда «-list» отображает цифровой отпечаток SHA1 сертификата. Следующий код позволяет просмотреть содержимое созданного хранилища, включающего сертификат и три пары ключей :
C:\Program Files\Java\jdk1.8.0_121\bin> \ keytool -list -keystore keystore.jks Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 5 entries keypair2, 14.02.2018, PrivateKeyEntry, Certificate fingerprint (SHA1): \ C4:02:BA:D7:24:6B:84:2F:CD:F9:81:16:5F:74:E0:31:7B:C0:19:B1 keypair1, 14.02.2018, PrivateKeyEntry, Certificate fingerprint (SHA1): \ AB:BA:92:77:44:BD:B0:65:EB:29:0C:F9:86:64:0F:81:B7:4A:27:9A keypair, 14.02.2018, PrivateKeyEntry, Certificate fingerprint (SHA1): \ 8A:8B:21:83:1E:75:4F:C7:62:85:6A:31:84:45:AA:16:2B:20:06:1E parent, 13.02.2018, PrivateKeyEntry, Certificate fingerprint (SHA1): \ DB:8B:9D:9D:DF:5B:B3:82:0E:19:C6:A4:A4:3E:08:C0:AB:20:F9:85 mykey, 18.02.2018, trustedCertEntry, Certificate fingerprint (SHA1): \ 20:42:85:DC:F7:EB:76:41:95:57:8E:13:6B:D4:B7:D1:E9:8E:46:A5
Опции команды list
Если при просмотре хранилища использовать опцию «-v», то информация о сертификате выводится с дополнительной информацией, включающей владельца, порядковый номер и т.д. При использовании опции «-rfc» содержание сертификата печатается согласно интернет-стандарта RFC-1421.
На странице описания SSL сертификата представлен результат выполнения команды просмотра хранилища keytool -list для опций ‘-v’ и ‘-rfc’.
Полную англоязычную версию документации на keytool можно найти здесь.
Пример просмотра хранилища и сертификата
На скриншоте представлен пример CertificateReader, позволяющий просматривать хранилище ключей и сертификаты, а также извлекать информацию о сертификате.
Внутри сертификата хранится пара значений Distinqueshed Names. Один DN принадлежит владельцу сертификата, а второй DN указывает идентификатор цента сертификации (CA), подписавшего сертификат. В случае с самоподписанным (self-signed) сертификатом, оба эти DN указывают на владельца сертификата.
Листинг примера
Интерфейс примера выполнен с использованием библиотеки Swing. Поскольку Swing не является предметом данной статьи, то методы формирования интерфейса не представлены в листинге примера. При необходимости желающие могут скачать исходный код примера в конце страницы.
В листинге примера представлены два метода : loadKeyStore, showCertificate. Первый метод позволяет выбрать хранилище сертификатов. Второй метод выполняет чтение сертификата и представление его параметров в интерфейсе. После листинга представлен скриншот, на котором выполнено чтение созданного сертификата.
import java.security.KeyStore; import java.security.KeyStoreException; import java.security.cert.Certificate; import java.security.cert.X509Certificate; public class CertificateReader extends JFrame < final String TERMIN = "Срок действия сертификата%s"; final String VALID = "действителен" ; final String INVALID = "не действителен" ; final String CREATER = "Издатель%s" ; final String NUMBER = "Серийный номер%s" ; final String START = "Начало срока действия%s" ; final String END = "Конец срока действия%s" ; final String OWNER = "Владелец%s" ; final String ALGORITM = "Алгоритм подписи%s" ; final String SIGN = "Подпись сертификата%s" ; final String LF = "\n" ; final String LF_SPACE = " :\n " ; KeyStore keyStore = null; // хранилище JListlstAliases = null; JTextField txtFileName = null; JTextArea taCertificate = null; final int LIST_size = 140 ; public CertificateReader() < setTitle("Просмотр хранилища сертификатов"); setSize(600, 480); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); getContentPane().setLayout(new BorderLayout()); getContentPane().add(createCtrl(), BorderLayout.SOUTH); getContentPane().add(createGUI (), BorderLayout.CENTER); setVisible(true); >private JPanel createCtrl() < . . . >private JSplitPane createGUI() < . . . >void loadKeyStore() < FileInputStream fis; // Выбор хранилища сертификатов JFileChooser chooser = new JFileChooser(); if(chooser.showOpenDialog(this) == JFileChooser.APPROVE_OPTION) < txtFileName.setText(chooser.getSelectedFile().getAbsolutePath()); try < // Чтение хранилище сертификатов keyStore = KeyStore.getInstance(KeyStore.getDefaultType()); fis = new FileInputStream(txtFileName.getText()); keyStore.load(fis, null); EnumerationE = keyStore.aliases(); // Формирование набор сертификатов Vector certs = new Vector(); while (E.hasMoreElements()) certs.add( (String)E.nextElement() ); // Размещение сертификатов в компоненте lstAliases.setListData(certs); invalidate(); > catch (Exception e) < JOptionPane.showMessageDialog(this , "Ошибка чтения хранилища сертификатов:\n" + e); >> > void showCertificate(final String name) < Certificate cert = null; try < // Чтение сертификата cert = keyStore.getCertificate(name); X509Certificate xcert = (X509Certificate) cert; String valid = ""; try < xcert.checkValidity(); valid = VALID; >catch (Exception ex) < valid = INVALID; >SimpleDateFormat sdf; sdf = new SimpleDateFormat("dd.MM.yyyy HH:mm:ss"); String end = sdf.format(xcert.getNotAfter ()); String start = sdf.format(xcert.getNotBefore()); String sign = new sun.misc.BASE64Encoder() .encode(cert.getSignature()); String creater = xcert.getIssuerDN().getName(); String owner = xcert.getSubjectDN().getName(); String number = String.valueOf(xcert.getSerialNumber()); String algo = xcert.getSigAlgName(); String info; info = createLine(TERMIN , valid ); info += createLine(CREATER , creater); info += createLine(NUMBER , number ); info += createLine(START , start ); info += createLine(END , end ); info += createLine(OWNER , owner ); info += createLine(ALGORITM, algo ); info += createLine(SIGN , sign ); taCertificate.setText(info); > catch (KeyStoreException ex1) < JOptionPane.showMessageDialog(this , "Ошибка получения из хранилища сертификата с " + псевдонимом >"); > > protected String createLine (String templ, String text) < return String.format(templ, LF_SPACE + text + LF); >public static void main(String[] args) < new CertificateReader(); >>
Примечание : класс CertificateReader используется в качестве примера на странице цифровой подписи jar файлов
Скачать пример
Рассмотренный на странице пример просмотра хранилища ключей и сертификатов можно скачать здесь (2.5 Кб).
Truststore keystore что это
Информация в этом разделе поможет вам подготовить файлы KeyStore и TrustStore, которые необходимо установить, и настроить ThingWorx Navigate . Ознакомьтесь с этим разделом перед началом установки и используйте его для справки по мере надобности в процессе установки.
Введение в конфигурирование SSL
PTC рекомендует использовать протокол SSL (Secure Sockets Layer) для производственной среды. ThingWorx Navigate может использовать SSL как для взаимной аутентификации между серверами, так и для защиты обмена данными.
Конфигурации для HTTPS требуют использовать сертификаты. ThingWorx Navigate требует, чтобы сертификат был доверенным для Java. Если вы выбираете использование сертификата, которому не доверяет Java, необходимо настроить Java на доверие этому сертификату. Сертификаты, предоставленные сторонними поставщиками, такими как Verisign и Thawte, являются доверенными для Java сертификатами.
Конфигурации SSL весьма разнообразны, и здесь не делается попытки описать все опции, доступные в конфигурации SSL. Инструкции, предоставленные здесь, потребуют минимум усилий для реализации самоподписанных сертификатов для HTTPS.
ThingWorx Navigate поддерживает различные конфигурации и методы аутентификации. В результате вам потребуются различные сертификаты, файлы KeyStore и TrustStore, создаваемые и готовые к использованию перед запуском установщика Установка ThingWorx Navigate и инструмента Конфигурация ThingWorx Navigate .
В следующих разделах описаны основные шаги для создания файлов KeyStore и TrustStore с помощью утилиты Java keytool . Процедуры установки и конфигурирования содержат информацию о том, какие файлы KeyStore или TrustStore вам потребуются на каждом шаге. При необходимости используйте общие инструкции из этого раздела при генерации данных файлов.
• При задании паролей для файлов TrustStore и KeyStore убедитесь, что они содержат только буквы и цифры. Специальные символы не поддерживаются.
• Исследуйте различные возможности, доступные на рынке для создания этих файлов безопасными способами. PTC не несет ответственности за безопасность сертификатов и файлов KeyStore и TrustStore, которые вы создаете.
Создание файла KeyStore, позволяющего принимать соединения на базе SSL с использованием самоподписанного сертификата
Перед началом убедитесь, что доступна утилита Java keytool . Затем выполните следующие шаги, чтобы создать новый файл KeyStore, содержащий пару из открытого и секретного ключа.
Для следующих шагов убедитесь, что вы открыли командную строку от имени администратора. В противном случае может быть выдана следующая ошибка:
keytool error: java.io.FileNotFoundException: tomcat.keystore (Access is denied)
1. Выберите папку для файла KeyStore и сохраните его в этой папке. Например, D:\Certificates .
2. Откройте командную строку и с помощью следующей команды перейдите к папке установки Java:
cd %JAVA_HOME%/bin
3. Выполните следующую команду, чтобы создать KeyStore с закрытым ключом для сертификата.
keytool -genkey -alias testKeyStore -keyalg rsa -dname «CN=
Вы получите запрос создать пароль для файла KeyStore и пароль для закрытого ключа. Используйте один и тот же пароль в обоих местах.
Измените значение аргумента -dname соответственно вашей среде.
Задайте значение для CN соответственно типу сертификата, который вы используете:
• Транспортный уровень — задайте полное имя своего хоста. Например,
• Уровень приложения (аутентификация клиента) — задайте любое подходящее имя. Например, ThingWorx .
4. Создайте самоподписанный сертификат для ключа с помощью команды ниже. В ответ на запрос пароля KeyStore введите пароль, созданный на шаге 3.
keytool -selfcert -alias testKeyStore -validity 1825 -keystore KeyStore.jks -storetype JKS
5. Экспортируйте открытый ключ для нового сертификата с помощью следующей команды:
keytool -export -alias testKeyStore -file testKeyStore.cer -rfc -keystore KeyStore.jks -storetype JKS
Файл KeyStore, который вы создали, имеет связанный с ним закрытый ключ.
Генерация файла TrustStore
В подразделе «Пример конфигурации SSL — производственная конфигурация» раздела Начальная настройка сервиса Integration Runtime для соединителей интеграции в справочном центре ThingWorx приведены инструкции по созданию нового файла TrustStore и импорту в него сертификата сервера.
Разница между хранилищем ключей Java и хранилищем доверенных сертификатов
В этой быстрой статье мы представим обзор различий между хранилищем ключей Java и хранилищем доверенных сертификатов Java.
2. Концепции
В большинстве случаев мы используем хранилище ключей и хранилище доверенных сертификатов, когда нашему приложению необходимо обмениваться данными через SSL/TLS .
Обычно это защищенные паролем файлы, которые находятся в той же файловой системе, что и наше запущенное приложение. Формат по умолчанию, используемый для этих файлов, — JKS до Java 8 .
Однако, начиная с Java 9, формат хранилища ключей по умолчанию — PKCS12 . Самая большая разница между JKS и PKCS12 заключается в том, что JKS — это формат, специфичный для Java, а PKCS12 — это стандартизированный и независимый от языка способ хранения зашифрованных закрытых ключей и сертификатов.
3. Хранилище ключей Java
В хранилище ключей Java хранятся записи закрытых ключей, сертификаты с открытыми ключами или просто секретные ключи , которые мы можем использовать для различных криптографических целей. Он хранит каждый по псевдониму для простоты поиска.
Вообще говоря, хранилища ключей содержат ключи, принадлежащие нашему приложению, которые мы можем использовать для подтверждения целостности сообщения и подлинности отправителя, скажем, путем подписания полезных данных.
Обычно мы используем хранилище ключей, когда являемся сервером и хотим использовать HTTPS . Во время рукопожатия SSL сервер ищет закрытый ключ в хранилище ключей и предоставляет клиенту соответствующий открытый ключ и сертификат.
Соответственно, если клиенту также необходимо аутентифицировать себя — ситуация, называемая взаимной аутентификацией, — тогда клиент также имеет хранилище ключей и также предоставляет свой открытый ключ и сертификат.
Хранилища ключей по умолчанию нет, поэтому, если мы хотим использовать зашифрованный канал, нам нужно установить javax.net.ssl.keyStore и javax.net.ssl.keyStorePassword. Если формат нашего хранилища ключей отличается от используемого по умолчанию, мы можем использовать javax.net.ssl.keyStoreType для его настройки.
Конечно, мы можем использовать эти ключи и для обслуживания других нужд. Закрытые ключи могут подписывать или расшифровывать данные, а открытые ключи могут проверять или шифровать данные. Секретные ключи также могут выполнять эти функции. Хранилище ключей — это место, где мы можем хранить эти ключи.
4. Магазин доверия Java
С хранилищем доверенных сертификатов все наоборот: в то время как хранилище ключей обычно хранит сертификаты, которые идентифицируют нас, хранилище доверенных сертификатов хранит сертификаты, которые идентифицируют других.
В Java мы используем его, чтобы доверять третьей стороне, с которой собираемся общаться.
Возьмем наш предыдущий пример. Если клиент взаимодействует с сервером на основе Java через HTTPS, сервер ищет связанный ключ в своем хранилище ключей и предоставляет открытый ключ и сертификат клиенту.
Затем мы, клиент, ищем связанный сертификат в нашем хранилище доверенных сертификатов. Если сертификат или центры сертификации, представленные внешним сервером, отсутствуют в нашем хранилище доверенных сертификатов, мы получим исключение SSLHandshakeException , и соединение не будет установлено успешно.
Java включает хранилище доверенных сертификатов под названием cacerts , которое находится в каталоге $JAVA_HOME/jre/lib/security .
Он содержит доверенные центры сертификации по умолчанию:
$ keytool -list -keystore cacerts Enter keystore password: Keystore type: JKS Keystore provider: SUN Your keystore contains 92 entries verisignclass2g2ca [jdk], 2018-06-13, trustedCertEntry, Certificate fingerprint (SHA1): B3:EA:C4:47:76:C9:C8:1C:EA:F2:9D:95:B6:CC:A0:08:1B:67:EC:9D Здесь мы видим, что хранилище доверенных сертификатов содержит 92 записи доверенных сертификатов, и одна из записей — это запись verisignclass2gca . Это означает, что JVM автоматически будет доверять сертификатам, подписанным verisignclass2g2ca .
Здесь мы можем переопределить расположение хранилища доверенных сертификатов по умолчанию с помощью свойства javax.net.ssl.trustStore . Точно так же мы можем установить javax.net.ssl.trustStorePassword и javax.net.ssl.trustStoreType , чтобы указать пароль и тип хранилища доверенных сертификатов.
5. Вывод
В этом руководстве мы обсудили основные различия между хранилищем ключей Java и хранилищем доверенных сертификатов Java, а также их назначение.
Кроме того, мы показали, как можно переопределить значения по умолчанию с помощью системных свойств.
Затем мы могли бы взглянуть на следующее руководство по SSL или Справочное руководство по JSSE , чтобы узнать больше о зашифрованной связи в Java.
- 1. Обзор
- 2. Концепции
- 3. Хранилище ключей Java
- 4. Магазин доверия Java
- 5. Вывод