Spec-Zone .ru
спецификации, руководства, описания, API
|
Управляет keystore (база данных) криптографических ключей, цепочек сертификата X.509, и доверял сертификатам.
keytool [ commands ]
keytool интерфейс команды изменил в Java SE 6. См. Раздел Изменений для подробного описания. Отметьте, что ранее определенные команды все еще поддерживаются.
Сертификат является в цифровой форме подписанным заявлением от одного объекта (человек, компания, и т.д.), говоря, что у открытого ключа (и некоторая другая информация) некоторого другого объекта есть определенное значение. (См. Сертификаты.), Когда данные в цифровой форме подписываются, подпись может быть проверена, чтобы проверить целостность данных и подлинность. Целостность означает, что данные не были изменены или вмешались, и подлинность означает, что данные действительно прибывают из того, кто бы ни утверждает, что создал и подписал это.
keytool также позволяет пользователям администрировать секретные ключи, используемые в симметричном шифровании/дешифровании (например, ДЕС).
keytool хранит ключи и сертификаты в keystore.
Различные команды и их опции перечисляются и описываются ниже. Отметьте:
-v
, -rfc
, и -J
опции, у которых только есть значение, если они появляются на командной строке (то есть, у них нет никаких значений "значения по умолчанию" кроме не существующими).-keypass
опция, если Вы не определяете опцию на командной строке, keytool, сначала попытается использовать keystore пароль, чтобы восстановить частный / секретный ключ, и если это перестанет работать, то тогда запросит Вас частный пароль / пароль секретного ключа.)-printcert
команда: keytool -printcert {-file cert_file} {-v}
Определяя a -printcert
команда, замена cert_file с фактическим именем файла, как в:
keytool -printcert -file VScert.cer
-help
команда является значением по умолчанию. Таким образом, командная строка keytool
эквивалентно
keytool -help
Ниже значения по умолчанию для различных значений опции.
-alias "mykey" -keyalg "DSA" (when using -genkeypair) "DES" (when using -genseckey) -keysize 2048 (when using -genkeypair and -keyalg is "RSA") 1024 (when using -genkeypair and -keyalg is "DSA") 256 (when using -genkeypair and -keyalg is "EC") 56 (when using -genseckey and -keyalg is "DES") 168 (when using -genseckey and -keyalg is "DESede") -validity 90 -keystore the file named.keystore
in the user's home directory -storetype the value of the "keystore.type" property in the security properties file, which is returned by the staticgetDefaultType
method injava.security.KeyStore
-file stdin if reading, stdout if writing -protected false
В генерировании пары "открытый/закрытый ключ" алгоритм подписи (-sigalg опция) получается из алгоритма базового закрытого ключа:
Пожалуйста, консультируйтесь со Спецификацией API Архитектуры Криптографии Java & Ссылкой для полного списка-keyalg и-sigalg, из которого можно выбрать.
-v
опция может появиться для всех команд кроме -help
. Если это появляется, это показывает "многословный" режим; больше информации будет предоставлено в выводе.
Есть также a -Jjavaoption
опция, которая может появиться для любой команды. Если это появляется, через указанную строку javaoption проходят непосредственно к интерпретатору Java. Эта опция не должна содержать пробелы. Это полезно для корректировки использования памяти или среды выполнения. Для списка возможных опций интерпретатора ввести java -h
или java -X
в командной строке.
Эти опции могут появиться для всех команд, работающих на keystore:
-storetype storetype
Этот спецификатор определяет тип keystore, который инстанцируют.
-keystore keystore
keystore расположение.
Если JKS storetype используется, и keystore файл еще не существует, то определенные keytool команды могут привести к новому keystore создаваемому файлу. Например, если keytool -genkeypair
вызывается и -keystore
опция не определяется, значение по умолчанию keystore названный файл .keystore
в корневом каталоге пользователя будет создаваться, если он не будет уже существовать. Точно так же, если -keystore ks_file
опция определяется, но ks_file не существует, тогда это будет создаваться
Отметьте что входной поток в -keystore
опцию передают к KeyStore.load
метод. Если NONE
определяется как URL, затем нулевой поток передают к KeyStore.load
метод. NONE
должен быть определен если KeyStore
не основано на файле (например, если это находится на аппаратном маркерном устройстве).
-storepass
[:env
|:file
] параметрПароль, который используется, чтобы защитить целостность keystore.
Если модификатор env
или file
не определяется, тогда у пароля есть параметр значения, который должен быть по крайней мере 6 символами долго. Иначе, пароль получается следующим образом:
env
: Получите пароль от параметра, передаваемого по имени переменной окруженияfile
: Получите пароль от параметра, передаваемого по имени файлаОтметьте: Все другие опции, которые требуют паролей, такой как -keypass
, -srckeypass
, -destkeypass
-srcstorepass
, и -deststorepass
, примите env
и file
модификаторы. (Не забудьте разделять опцию пароля и модификатор с двоеточием, (:
).)
Пароль должен быть обеспечен для всех команд, которые получают доступ к keystore содержанию. Для таких команд, если a -storepass
возможность не предоставляется в командной строке, пользователь запрашивается это.
Получая информацию от keystore, пароль является дополнительным; если никакой пароль не дается, целостность полученной информации не может быть проверена, и предупреждение выводится на экран.
-providerName provider_name
Используемый, чтобы идентифицировать имя провайдера криптографических служб когда перечислено в файле свойств безопасности.
-providerClass provider_class_name
Используемый, чтобы определить имя основного файла class провайдера криптографических служб, когда поставщик услуг не перечисляется в файле свойств безопасности.
-providerArg provider_arg
Используемый в соединении с -providerClass
. Представляет дополнительный строковый входной параметр за конструктора provider_class_name.
-protected
Также true
или false
. Это значение должно быть определено как true
если пароль должен быть дан через защищенный путь аутентификации, такой как выделенный читатель ПИН.
Отметьте: С тех пор есть два keystores, включенные в -importkeystore
команда, две опции, а именно, -srcprotected
и -destprotected
обеспечиваются для источника keystore и места назначения keystore соответственно.
-ext {name{:critical}{=value}}
Обозначает расширение сертификата X.509. Опция может использоваться в-genkeypair и-gencert, чтобы встроить расширения в сертификат, сгенерированный, или в -certreq
показать, какие расширения требуют в запросе сертификата. Опция может появиться многократно. имя может быть поддерживаемым именем расширения (см. ниже), или произвольное число OID. значение, если обеспечено, обозначает параметр для расширения; если опущено, обозначает значение по умолчанию (если определено) расширения, или расширение не требует никакого параметра. :critical
модификатор, если обеспечено, означает, что атрибут isCritical расширения является истиной; иначе, ложь. Можно использовать :c
вместо :critical
.
В настоящий момент keytool поддерживает эти именованные (нечувствительные к регистру) расширения:
Имя | Значение |
---|---|
BC или BasicConstraints | Полная форма: "приблизительно: {true|false} [pathlen: <len>]"; или, <len>, сокращение для "ca:true, pathlen: <len>"; или опущенный, "ca:true" средств |
KU или KeyUsage | использование (использование) *, использование может быть одним из digitalSignature, неотказ (contentCommitment), keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly. Использование может быть сокращено с первыми немногими буквами (скажите, выройте для digitalSignature), или в стиле Camel-регистра (говорят, dS для digitalSignature, cRLS для cRLSign), пока никакая неоднозначность не находится. Использование является нечувствительным к регистру. |
EKU или ExtendedkeyUsage | использование (использование) *, использование может быть одним из anyExtendedKeyUsage, serverAuth, clientAuth, codeSigning, emailProtection, добавление метки времени, OCSPSigning, или любая строка OID. Названное использование может быть сокращено с первым немного букв или в стиле Camel-регистра, пока никакая неоднозначность не находится. Использование является нечувствительным к регистру. |
SAN или SubjectAlternativeName | type:value (type:value) *, типом может быть ЭЛЕКТРОННАЯ ПОЧТА, URI, DNS, IP, или OID, значение является строковым значением формата для типа. |
ИЭН или IssuerAlternativeName | то же самое как SubjectAlternativeName |
СИА или SubjectInfoAccess | method:location-type:location-value (, method:location-type:location-value) *, метод может "устанавливать метку времени", "caRepository" или любой OID. тип расположения и значение расположения могут быть любым type:value, поддерживаемым расширением SubjectAlternativeName. |
AIA или AuthorityInfoAccess | то же самое как метод SubjectInfoAccess может быть "ocsp", "caIssuers" или любым OID. |
Для имени как OID значение является ШЕСТНАДЦАТЕРИЧНЫМ выведенным кодированием DER extnValue для расширения, исключая СТРОКОВЫЙ тип ОКТЕТА и байты длины. Любой дополнительный символ кроме стандартных Шестнадцатеричных чисел (0-9, a-f, A-F) игнорируется в ШЕСТНАДЦАТЕРИЧНОЙ строке. Поэтому, оба "01:02:03:04"
и "01020304"
принимаются как идентичные значения. Если нет никакого значения, у расширения есть пустое поле значения тогда.
Специальное имя 'honored'
, используемый в -gencert
только, обозначает, как расширения, включенные в запрос сертификата, нужно соблюдать. Значение для этого имени является списком разделенных запятой значений "all"
(все требуемые расширения соблюдают), "name{:[critical|non-critical]}"
(именованное расширение соблюдают, но использование различного атрибута isCritical), и "-name"
(используемый со всеми, обозначает исключение). Требуемые расширения не соблюдают по умолчанию.
Если, кроме того - расширение соблюдало опцию, другой названный или OID - возможность расширения предоставляется, это расширение будет добавлено к тем, которых уже удостаивают. Однако, если это имя (или OID) также появляется в соблюдаемом значении, его значение и критичность переопределяют тот в запросе.
subjectKeyIdentifier расширение всегда создается. Для не самоподписанные сертификаты, всегда создается authorityKeyIdentifier.
Отметьте: Пользователи должны знать, что некоторые комбинации расширений (и другие поля сертификата), возможно, не соответствуют интернет-стандарту. См. То, чтобы попросить Расценить Соответствие Сертификата для деталей.
-gencert {-rfc} {-infile infile} {-outfile outfile} {-alias alias} {-sigalg sigalg} {-dname dname} {-startdate startdate {-ext ext}* {-validity valDays} [-keypass keypass] {-keystore keystore} [-storepass storepass] {-storetype storetype} {-providername provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}
Генерирует сертификат как ответ на файл запроса сертификата (который может быть создан keytool -certreq
команда). Команда читает запрос из infile (если опущено, из стандартного ввода), подписывает это использующий закрытый ключ псевдонима, и выводила сертификат X.509 в outfile (если опущено к стандартному выводу). Если -rfc
определяется, выведите формат, BASE64-кодируется PEM; иначе, двоичный DER создается.
sigalg определяет алгоритм, который должен использоваться, чтобы подписать сертификат. startdate является временем/датой запуска, когда сертификат допустим. valDays говорит число дней, в течение которых сертификат нужно считать допустимым.
Если dname обеспечивается, он используется в качестве предмета сгенерированного сертификата. Иначе, тот от запроса сертификата используется.
расширение показывает, какие расширения X.509 будут встроены в сертификат. Считайте Общие Опции для грамматики -ext
.
-gencert
команда позволяет Вам создать цепочки сертификата. Следующий пример создает сертификат, e1
, это содержит три сертификата в его цепочке сертификата.
Следующие команды создают четыре названные пары ключей ca
, ca1
, ca2
, и e1
:
keytool -alias ca -dname CN=CA -genkeypair keytool -alias ca1 -dname CN=CA -genkeypair keytool -alias ca2 -dname CN=CA -genkeypair keytool -alias e1 -dname CN=E1 -genkeypair
Следующие две команды создают цепочку подписанных сертификатов; ca
знаки ca1 и ca1 signs ca2
, все из которых самовыпускаются:
keytool -alias ca1 -certreq | keytool -alias ca -gencert -ext san=dns:ca1 | keytool -alias ca1 -importcert keytool -alias ca2 -certreq | $KT -alias ca1 -gencert -ext san=dns:ca2 | $KT -alias ca2 -importcert
Следующая команда создает сертификат e1
и хранилища это в файле e1.cert
, который подписывается ca2
. В результате e1
должен содержать ca
, ca1
, и ca2
в его цепочке сертификата:
keytool -alias e1 -certreq | keytool -alias ca2 -gencert > e1.cert
-genkeypair {-alias alias} {-keyalg keyalg} {-keysize keysize} {-sigalg sigalg} [-dname dname] [-keypass keypass] {-startdate value} {-ext ext}* {-validity valDays} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}
Генерирует пару ключей (открытый ключ, и связал закрытый ключ). Обертывает открытый ключ в X.509 v3 самоподписанный сертификат, который сохранен как одноэлементная цепочка сертификата. Эта цепочка сертификата и закрытый ключ сохранены в новой keystore записи, идентифицированной псевдонимом.
keyalg определяет алгоритм, который будет использоваться, чтобы генерировать пару ключей, и размер ключа определяет размер каждого ключа, который будет сгенерирован. sigalg определяет алгоритм, который должен использоваться, чтобы подписать самоподписанный сертификат; этот алгоритм должен быть совместимым с keyalg.
dname определяет Отличительное имя X.500, которое будет связано с псевдонимом, и используется в качестве issuer
и subject
поля в самоподписанном сертификате. Если никакое отличительное имя не будет обеспечено в командной строке, то пользователь будет запрошен одного.
keypass является паролем, используемым, чтобы защитить закрытый ключ сгенерированной пары ключей. Если никакой пароль не обеспечивается, пользователь запрашивается это. Если Вы нажимаете ВОЗВРАТ при подсказке, ключевой пароль устанавливается в тот же самый пароль, как используемое для keystore. keypass должно быть по крайней мере 6 символами долго.
startdate определяет время проблемы сертификата, также известного как "Не Перед" значением поля Validity сертификата X.509.
Значение опции может быть установлено в одной из этих двух форм:
С первой формой время проблемы смещается на указанное значение с текущего времени. Значение является связью последовательности значений sub. В каждом значении sub знак "плюс" (" + ") означает смещаться вперед, и знак "минус" (" - ") означает смещаться назад. Время, которое будет смещено, является nnn модулями лет, месяцев, дней, часов, минут, или секунд (обозначенный единственным символом "y", "м.", "d", "H", "М.", или "S" соответственно). Точное значение времени проблемы вычисляется, используя java.util.GregorianCalendar.add(int field, int amount)
метод на каждом значении sub, слева направо. Например, определяя "-startdate -1y+1m-1d"
, время проблемы будет:
Calendar c = new GregorianCalendar(); c.add(Calendar.YEAR, -1); c.add(Calendar.MONTH, 1); c.add(Calendar.DATE, -1); return c.getTime()
Со второй формой пользователь устанавливает точное время проблемы в двух частях, год/месяц/день и hour:minute:second (использующий зону местного времени). Пользователь может обеспечить только одну часть, что означает, что другая часть является тем же самым как текущей датой (или время). Пользователь должен обеспечить точное число цифр как показано в определении формата (дополняющий 0 если короче). Когда и дата и время обеспечивается, есть один (и только один) пробел между этими двумя частями. Час должен всегда обеспечиваться в 24-часовом формате.
Когда возможность не предоставляется, дата начала является текущим временем. Возможность может быть предоставлена самое большее однажды.
valDays определяет число дней (запускающийся в дате, определенной -startdate
, или текущая дата, если -startdate
не определяется), для которого сертификат нужно считать допустимым.
Эту команду назвали -genkey в предыдущих выпусках. Это старое название все еще поддерживается в этом выпуске и будет поддерживаться в будущих выпусках, но для ясности новое имя, -genkeypair, предпочитается, продвигаясь.
-genseckey {-alias alias} {-keyalg keyalg} {-keysize keysize} [-keypass keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}
Генерирует секретный ключ и хранит это в новом KeyStore.SecretKeyEntry
идентифицированный псевдонимом.
keyalg определяет алгоритм, который будет использоваться, чтобы генерировать секретный ключ, и размер ключа определяет размер ключа, который будет сгенерирован. keypass является паролем, используемым, чтобы защитить секретный ключ. Если никакой пароль не обеспечивается, пользователь запрашивается это. Если Вы нажимаете ВОЗВРАТ при подсказке, ключевой пароль устанавливается в тот же самый пароль, как используемое для keystore. keypass должно быть по крайней мере 6 символами долго.
-importcert {-alias alias} {-file cert_file} [-keypass keypass] {-noprompt} {-trustcacerts} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}
Читает сертификат или цепочку сертификата (где последний предоставляется в PKCS#7 отформатированный ответ или последовательность сертификатов X.509) от файла cert_file, и хранит это в keystore записи, идентифицированной псевдонимом. Если никакой файл не дается, цепочка сертификата или сертификата читается из stdin.
keytool может импортировать X.509 v1, v2, и v3 сертификаты, и PKCS#7 отформатированные цепочки сертификата, состоящие из сертификатов о том типе. Данные, которые будут импортированы, должны быть обеспечены или в двоичном формате кодирования, или в печатаемом формате кодирования (также известные как кодирование Base64) как определено интернет-стандартом RFC 1421. В последнем случае кодирование должно быть ограничено вначале строкой, которая запускается с "-----, НАЧИНАЮТСЯ", и ограниченный в конце строкой, которая запускается с "-----КОНЕЦ".
Вы импортируете сертификат по двум причинам:
То, какой тип импорта предназначается, обозначается значением -alias
опция:
Прежде, чем добавить сертификат keystore, keytool пытается проверить, что это, пытаясь создать цепочку доверия от того сертификата до самоподписанного сертификата (принадлежащий корневому CA), используя доверяло сертификатам, которые уже доступны в keystore.
Если -trustcacerts
опция была определена, дополнительные сертификаты рассматривают для цепочки доверия, а именно, сертификаты в файле, названном "cacerts".
Если keytool не в состоянии установить доверительный путь от сертификата, который будет импортирован до самоподписанного сертификата (или от keystore или от "cacerts" файла), информация о сертификате распечатывается, и пользователь запрашивается проверить это, например, сравнивая выведенные на экран цифровые отпечатки сертификата с цифровыми отпечатками, полученными из некоторого другого (доверяемого) источника информации, который мог бы быть владельцем сертификата непосредственно. Очень делайте все возможное гарантировать, что сертификат допустим до импорта этого как "доверяемый" сертификат! - см. ТО, ЧТОБЫ ПОПРОСИТЬ Расценить Импорт Сертификаты, Которым доверяют. У пользователя тогда есть опция прерывания работы импорта. Если -noprompt
опция дается, однако, не будет никакого взаимодействия с пользователем.
Импортируя ответ сертификата, ответ сертификата проверяется, используя, доверял сертификатам от keystore, и дополнительно используя сертификаты, сконфигурированные в "cacerts" keystore файл (если -trustcacerts
опция была определена).
Методы определения, доверяют ли ответу сертификата, описываются в следующем:
-trustcacerts
опция была определена, keytool попытается соответствовать ее с любым из доверяемых сертификатов в keystore или "cacerts" keystore файл. Если цепочка не заканчивается самоподписанным корневым сертификатом CA и -trustcacerts
опция была определена, keytool попытается найти один от доверяемых сертификатов в keystore или "cacerts" keystore файл и добавить это до конца цепочки. Если сертификат не находится и -noprompt
опция не определяется, информация последнего сертификата в цепочке распечатывается, и пользователь запрашивается проверить это.Если открытый ключ в ответе сертификата соответствует открытый ключ пользователя, уже сохраненный под псевдонимом, старая цепочка сертификата заменяется новой цепочкой сертификата в ответе. Старая цепочка может только быть заменена, если допустимый keypass, пароль, используемый, чтобы защитить закрытый ключ записи, предоставляется. Если никакой пароль не обеспечивается, и пароль с закрытым ключом отличается от keystore пароля, пользователь запрашивается это.
Эту команду назвали -import в предыдущих выпусках. Это старое название все еще поддерживается в этом выпуске и будет поддерживаться в будущих выпусках, но для разъясняют, что новое имя, -importcert, предпочитается, продвигаясь.
-importkeystore -srckeystore srckeystore -destkeystore destkeystore {-srcstoretype srcstoretype} {-deststoretype deststoretype} [-srcstorepass srcstorepass] [-deststorepass deststorepass] {-srcprotected} {-destprotected} {-srcalias srcalias {-destalias destalias} [-srckeypass srckeypass] [-destkeypass destkeypass] } {-noprompt} {-srcProviderName src_provider_name} {-destProviderName dest_provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}
Импортирует единственную запись или все записи из источника keystore месту назначения keystore.
Когда srcalias возможность предоставляется, команда импортирует единственную запись, идентифицированную псевдонимом для места назначения keystore. Если целевому псевдониму не предоставляют destalias, то srcalias используется в качестве целевого псевдонима. Если исходная запись будет защищена паролем, то srckeypass будет использоваться, чтобы восстановить запись. Если srckeypass не будет обеспечен, то keytool попытается использовать srcstorepass, чтобы восстановить запись. Если srcstorepass не будет или обеспечен или будет неправильным, то пользователь будет запрошен пароль. Целевая запись будет защищена, используя destkeypass. Если destkeypass не будет обеспечен, то целевая запись будет защищена с исходным паролем записи.
Если srcalias возможность не предоставляется, то все записи в источнике keystore импортируются в место назначения keystore. Каждая целевая запись будет сохранена под псевдонимом от исходной записи. Если исходная запись будет защищена паролем, то srcstorepass будет использоваться, чтобы восстановить запись. Если srcstorepass не будет или обеспечен или будет неправильным, то пользователь будет запрошен пароль. Если источник keystore тип записи не будет поддерживаться в месте назначения keystore, или если ошибка произойдет, храня запись в место назначения keystore, то пользователь будет запрошен, пропустить ли запись и продолжать, или выходить. Целевая запись будет защищена с исходным паролем записи.
Если целевой псевдоним уже существует в месте назначения keystore, пользователь запрашивается или перезаписать запись, или создать новую запись под различным именем псевдонима.
Отметьте это если -noprompt
обеспечивается, пользователь не будет запрошен новый целевой псевдоним. Существующие записи будут автоматически перезаписаны с целевым именем псевдонима. Наконец, записи, которые не могут быть импортированы, автоматически пропускаются, и предупреждение выводится.
-printcertreq {-file file}
Печатает контент PKCS #10 запрос сертификата формата, который может быть сгенерирован keytool-certreq команда. Команда читает запрос из файла; если опущено, от стандартного ввода.
-certreq {-alias alias} {-dname dname} {-sigalg sigalg} {-file certreq_file} [-keypass keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}
Генерирует Запрос Подписания Сертификата (CSR), используя PKCS#10 формат.
CSR предназначается, чтобы быть отправленным центру сертификации (CA). CA будет аутентифицировать просителя сертификата (обычно офлайн) и возвратит сертификат или цепочку сертификата, используемую, чтобы заменить существующую цепочку сертификата (который первоначально состоит из самоподписанного сертификата) в keystore.
Закрытый ключ, связанный с псевдонимом, используется, чтобы создать PKCS#10 запрос сертификата. Чтобы получить доступ к закрытому ключу, соответствующий пароль должен быть обеспечен, так как закрытые ключи защищаются в keystore с паролем. Если keypass не обеспечивается в командной строке, и отличается от пароля, используемого, чтобы защитить целостность keystore, пользователь запрашивается это. Если dname обеспечивается, он используется в качестве предмета в CSR. Иначе, Отличительное имя X.500, связанное с псевдонимом, используется.
sigalg определяет алгоритм, который должен использоваться, чтобы подписать CSR.
CSR сохранен в файле certreq_file. Если никакой файл не дается, CSR выводится к stdout.
Используйте importcert команду, чтобы импортировать ответ из CA.
-exportcert {-alias alias} {-file cert_file} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-rfc} {-v} {-protected} {-Jjavaoption}
Чтения (от keystore) сертификат, связанный с псевдонимом, и хранилищами это в файле cert_file.
Если никакой файл не дается, сертификат выводится к stdout.
Сертификат выводом значения по умолчанию в двоичном кодировании, но будет вместо этого выведен в печатаемом формате кодирования, как определено интернет-стандартом RFC 1421, если -rfc
опция определяется.
Если псевдоним обращается к доверяемому сертификату, тот сертификат выводится. Иначе, псевдоним обращается к ключевой записи со связанной цепочкой сертификата. В этом случае первый сертификат в цепочке возвращается. Этот сертификат аутентифицирует открытый ключ объекта, адресуемого псевдонимом.
Эту команду назвали -export в предыдущих выпусках. Это старое название все еще поддерживается в этом выпуске и будет поддерживаться в будущих выпусках, но для разъясняют, что новое имя, -exportcert, предпочитается, продвигаясь.
-list {-alias alias} {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v | -rfc} {-protected} {-Jjavaoption}
Печатные издания (к stdout) содержание keystore записи идентифицируются псевдонимом. Если никакой псевдоним не определяется, содержание всего keystore печатается.
Эта команда значением по умолчанию печатает цифровой отпечаток SHA1 сертификата. Если -v
опция определяется, сертификат печатается в удобочитаемом формате, с дополнительной информацией, такой как владелец, выпускающий, порядковый номер, и любые расширения. Если -rfc
опция определяется, содержание сертификата печатается, используя печатаемый формат кодирования, как определено интернет-стандартом RFC 1421
Невозможно определить обоих -v
и -rfc
.
-printcert {-file cert_file | -sslserver host[:port]} {-jarfile JAR_file {-rfc} {-v} {-Jjavaoption}
Читает сертификат из файла cert_file, сервер SSL, расположенный в host:port, или подписанном файле JAR JAR_file (с опцией -jarfile
и печатает его содержание в удобочитаемом формате. Когда никакой порт не определяется, стандартный порт HTTPS 443 принимается. Отметьте это -sslserver
и -file
возможности не могут быть предоставлены одновременно. Иначе, об ошибке сообщают. Если никакая опция не дается, сертификат читается из stdin.
Если -rfc
определяется, keytool печатает сертификат в режиме PEM как определено интернет-стандартом RFC 1421.
Если сертификат читается из файла или stdin, это может быть или закодированный двоичный файл или в печатаемом формате кодирования, как определено интернет-стандартом RFC 1421
Если сервер SSL находится позади брандмауэра, -J-Dhttps.proxyHost=proxyhost
и -J-Dhttps.proxyPort=proxyport
может быть определен на командной строке для туннелирования прокси. См. Справочник JSSE для получения дополнительной информации.
Отметьте: Эта опция может использоваться независимо от keystore.
-printcrl -file crl_ {-v}
Читает список аннулированных сертификатов (CRL) из файла crl_file.
Список аннулированных сертификатов (CRL) является списком цифровых сертификатов, которые были отменены Центром сертификации (CA), который выпустил их. CA генерирует crl_file.
Отметьте: Эта опция может использоваться независимо от keystore.
-storepasswd [-new new_storepass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-Jjavaoption}
Изменяет пароль, используемый, чтобы защитить целостность keystore содержания. Новый пароль является new_storepass, который должен быть по крайней мере 6 символами долго.
-keypasswd {-alias alias} [-keypass old_keypass] [-new new_keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-Jjavaoption}
Изменяет пароль, под которым частный / секретный ключ, идентифицированный псевдонимом, защищается от old_keypass до new_keypass, который должен быть по крайней мере 6 символами долго.
Если -keypass
возможность не предоставляется в командной строке, и ключевой пароль отличается от keystore пароля, пользователь запрашивается это.
Если -new
возможность не предоставляется в командной строке, пользователь запрашивается это.
-delete [-alias alias] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}
Удаляет из keystore запись, идентифицированную псевдонимом. Пользователь запрашивается псевдоним, если никакой псевдоним не обеспечивается в командной строке.
-changealias {-alias alias} [-destalias destalias] [-keypass keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerName provider_name} {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption}
Переместите существующую keystore запись от указанного псевдонима до нового псевдонима, destalias. Если никакой целевой псевдоним не будет обеспечен, то команда запросит одного. Если исходная запись защищается с паролем записи, пароль может быть предоставлен через "-keypass" опцию. Если никакой ключевой пароль не будет обеспечен, то storepass (если дано) будет предпринят сначала. Если та попытка перестанет работать, то пользователь будет запрошен пароль.
-help
Перечисляет основные команды и их опции.
Для получения дополнительной информации об определенной команде, введите следующий, где command_name
имя команды:
keytool -command_name -help
Предположите, что Вы хотите создать keystore для того, чтобы управлять Вашей парой "открытый/закрытый ключ" и сертификатами от объектов, которым Вы доверяете.
Первая вещь, которую Вы должны сделать, создают keystore и генерируют пару ключей. Вы могли использовать команду, такую как следующее:
keytool -genkeypair -dname "cn=Mark Jones, ou=Java, o=Oracle, c=US" -alias business -keypass <new password for private key> -keystore /working/mykeystore -storepass <new password for keystore> -validity 180
(Пожалуйста, отметьте: Это должно быть введено как одна строка. Многократные строки используются в примерах только в целях четкости.)
Эта команда создает keystore, названный "mykeystore" в "рабочем" каталоге (предполагающий, что это уже не существует), и присваивает это пароль, определенный <новый пароль для keystore>. Это генерирует пару "открытый/закрытый ключ" для объекта, у "отличительного имени" которого есть общее название "Марка Джонса", организационный модуль "Java", организация "Oracle" и двухбуквенный код страны "US". Это использует алгоритм генерации ключей "DSA" значения по умолчанию, чтобы создать ключи, оба 1024 бита длиной.
Это создает самоподписанный сертификат (использующий значение по умолчанию алгоритм подписи "SHA1withDSA"), который включает открытый ключ и информацию об отличительном имени. Этот сертификат будет допустим в течение 180 дней, и связывается с закрытым ключом в keystore записи, упомянутой псевдонимом "бизнес". Закрытый ключ присваивается пароль, определенный <новый пароль для закрытого ключа>.
Команда могла быть значительно короче, если бы значения по умолчанию опции были приняты. Фактически, никакие опции не требуются; значения по умолчанию используются для неуказанных опций, у которых есть значения по умолчанию, и Вы запрашиваетесь любые необходимые значения. Таким образом у Вас могло просто быть следующее:
keytool -genkeypair
В этом случае keystore запись с псевдонимом "mykey" создается с недавно сгенерированной парой ключей и сертификатом, который допустим в течение 90 дней. Эта запись помещается в keystore, названный ".keystore" в Вашем корневом каталоге. (keystore создается, если он уже не существует.) Вы будете запрошены информацию об отличительном имени, keystore пароль, и пароль с закрытым ключом.
Остальная часть примеров предполагает, что Вы выполнились -genkeypair
команда без опций, определенных, и что Вы ответили на подсказки со значениями, равными данным в первом -genkeypair
команда, выше (например, отличительное имя "cn=Mark Джонс, ou=Java, o=Oracle, c=US").
До сих пор все, что мы имеем, является самоподписанным сертификатом. Сертификату, более вероятно, будут доверять другие, если он будет подписан Центром сертификации (CA). Чтобы получить такую подпись, Вы сначала генерируете Запрос Подписания Сертификата (CSR) через следующее:
keytool -certreq -file MarkJ.csr
Это создает CSR (для объекта, идентифицированного "mykey" псевдонима значения по умолчанию), и помещает запрос в файл по имени "MarkJ.csr". Представьте этот файл CA, такому как VeriSign, Inc. CA будет аутентифицировать Вас, проситель (обычно офлайн), и затем возвратит сертификат, подписанный ими, аутентифицируя Ваш открытый ключ. (В некоторых случаях они фактически возвратят цепочку сертификатов, каждый аутентифицирующий открытый ключ подписывающего лица предыдущего сертификата в цепочке.)
Вы должны заменить свой самоподписанный сертификат цепочкой сертификата, где каждый сертификат в цепочке аутентифицирует открытый ключ подписывающего лица предыдущего сертификата в цепочке до "корневого" CA.
Прежде, чем Вы импортируете ответ сертификата из CA, Вы нуждаетесь в одном или более "доверяемых сертификатах" в Вашем keystore или в cacerts
файл keystore (который описывается в importcert команде):
"cacerts" keystore файл поставляет с несколькими корневыми сертификатами CA VeriSign, таким образом, Вы, вероятно, не должны будете импортировать сертификат VeriSign как доверяемый сертификат в Вашем keystore. Но если Вы запросите подписанный сертификат от различного CA, и сертификат, аутентифицирующий, что открытый ключ CA не был добавлен к "cacerts", то Вы должны будете импортировать сертификат из CA как "доверяемый сертификат".
Сертификат от CA обычно или самоподписывается, или подписывается другим CA (когда Вы также нуждаетесь в сертификате, аутентифицирующем что открытый ключ CA). Предположите компанию ABC, Inc., CA, и Вы получаете файл под названием "ABCCA.cer", который является согласно заявлению самоподписанным сертификатом от ABC, аутентифицируя что открытый ключ CA.
Очень делайте все возможное гарантировать, что сертификат допустим до импорта этого как "доверяемый" сертификат! Просмотрите это сначала (использующий keytool -printcert
команда, или keytool -importcert
команда без -noprompt
опция), и удостоверяются что выведенное на экран соответствие цифрового отпечатка (ков) сертификата ожидаемые. Можно вызвать человека, который отправил сертификат, и сравните цифровой отпечаток (ки), что Вы видите с теми, что они показывают (или что безопасный репозитарий с открытым ключом показывает). Только если цифровые отпечатки равны, это, гарантировал, что сертификат не был заменен в пути с чьим-либо (например, атакующий) сертификат. Если бы такая атака имела место, и Вы не проверяли сертификат прежде, чем Вы импортировали это, то Вы закончили бы тем, что доверяли чему-либо, что атакующий подписал.
Если Вы полагаете, что сертификат допустим, то можно добавить это к своему keystore через следующее:
keytool -importcert -alias abc -file ABCCA.cer
Это создает "доверяемый сертификат" запись в keystore, с данными от файла "ABCCA.cer", и присваивает псевдоним "abc" записи.
Как только Вы импортировали сертификат, аутентифицирующий открытый ключ CA, Вы утверждали, что Ваше подписание сертификата запрашивает к (или уже есть такой сертификат в "cacerts" файле), можно импортировать ответ сертификата и таким образом заменить Ваш самоподписанный сертификат цепочкой сертификата. Эта цепочка является той, возвращенной CA в ответ на Ваш запрос (если ответ CA является цепочкой), или один созданный (если ответ CA является единственным сертификатом), использование ответа сертификата, и доверял сертификатам, которые уже доступны в keystore, куда Вы импортируете ответ или в "cacerts" keystore файл.
Например, предположите, что Вы отправили свой запрос подписания сертификата VeriSign. Можно тогда импортировать ответ через следующий, который предполагает, что возвращенный сертификат называют "VSMarkJ.cer":
keytool -importcert -trustcacerts -file VSMarkJ.cer
Предположите, что Вы использовали jarsigner инструмент, чтобы подписать Архив Java (JAR) файл. Клиенты, которые хотят использовать файл, будут хотеть заверить Вашу подпись.
Одним путем они могут сделать, это первым импортом Вашего сертификата с открытым ключом в их keystore как "доверяемая" запись. Можно экспортировать сертификат и предоставить его Вашим клиентам. Как пример, можно скопировать свой сертификат названному файлу MJ.cer
через следующий, принимая запись искажается "mykey":
keytool -exportcert -alias mykey -file MJ.cer
Учитывая, что сертификат, и подписанный файл JAR, клиент может использовать jarsigner инструмент, чтобы заверить Вашу подпись.
Команда "importkeystore" используется, чтобы импортировать весь keystore в другой keystore, что означает, что все записи из источника keystore, включая ключи и сертификаты, все импортируются в место назначения keystore в пределах единственной команды. Можно использовать эту команду, чтобы импортировать записи из различного типа keystore. Во время импорта у всех новых записей в месте назначения keystore будут те же самые имена псевдонима и пароли защиты (для секретных ключей и закрытых ключей). Если у keytool есть трудности, восстанавливают закрытые ключи или секретные ключи из источника keystore, это запросит Вас пароль. Если это обнаружит дублирование псевдонима, то это попросит у Вас новый, можно определить новый псевдоним или просто позволить keytool перезаписывать существующий.
Например, чтобы импортировать записи из нормального JKS вводят keystore key.jks в PKCS #11, вводят аппаратные средства базируемый keystore, можно использовать команду:
keytool -importkeystore -srckeystore key.jks -destkeystore NONE -srcstoretype JKS -deststoretype PKCS11 -srcstorepass <source keystore password> -deststorepass <destination keystore password>
importkeystore команда может также использоваться, чтобы импортировать единственную запись из источника keystore месту назначения keystore. В этом случае помимо опций Вы видите в вышеупомянутом примере, Вы должны определить псевдоним, который Вы хотите импортировать. С srcalias данной опцией можно также определить целевое имя псевдонима в командной строке, так же как пароль защиты для секрета/закрытого ключа и целевой пароль защиты, который Вы хотите. Следующая команда демонстрирует это:
keytool -importkeystore -srckeystore key.jks -destkeystore NONE -srcstoretype JKS -deststoretype PKCS11 -srcstorepass <source keystore password> -deststorepass <destination keystore password> -srcalias myprivatekey -destalias myoldprivatekey -srckeypass <source entry password> -destkeypass <destination entry password> -noprompt
Следующее является keytool командами, чтобы генерировать пары ключей и сертификаты для трех объектов, а именно, Корневой CA (корень), Промежуточный CA (приблизительно), и сервер SSL (сервер). Гарантируйте, что Вы храните все сертификаты в том же самом keystore. В этих примерах рекомендуется, чтобы Вы определили RSA как ключевой алгоритм.
keytool -genkeypair -keystore root.jks -alias root -ext bc:c keytool -genkeypair -keystore ca.jks -alias ca -ext bc:c keytool -genkeypair -keystore server.jks -alias server keytool -keystore root.jks -alias root -exportcert -rfc > root.pem keytool -storepass <storepass> -keystore ca.jks -certreq -alias ca | keytool -storepass <storepass> -keystore root.jks -gencert -alias root -ext BC=0 -rfc > ca.pem keytool -keystore ca.jks -importcert -alias ca -file ca.pem keytool -storepass <storepass> -keystore server.jks -certreq -alias server | keytool -storepass <storepass> -keystore ca.jks -gencert -alias ca -ext ku:c=dig,kE -rfc > server.pem cat root.pem ca.pem server.pem | keytool -keystore server.jks -importcert -alias server
keystore является складом для криптографических ключей и сертификатов.
У Keystores могут быть различные типы записей. Два самых применимых типа записи для keytool включают:
Ко всем keystore записям (ключевые и доверяемые записи сертификата) получают доступ через уникальные псевдонимы.
Псевдоним определяется, когда Вы добавляете объект к keystore использование-genseckey команды, чтобы генерировать секретный ключ,-genkeypair команда, чтобы генерировать пару ключей (и закрытый ключ с открытым ключом) или-importcert команда, чтобы добавить сертификат или цепочку сертификата к списку доверяемых сертификатов. Последующие keytool команды должны использовать этот тот же самый псевдоним, чтобы обратиться к объекту.
Например, предположите, что Вы используете псевдоним duke, чтобы генерировать новую пару "открытый/закрытый ключ" и обернуть открытый ключ в самоподписанный сертификат (см. Цепочки Сертификата) через следующую команду:
keytool -genkeypair -alias duke -keypass dukekeypasswd
Это определяет начальный пароль "dukekeypasswd", требуемого последующими командами получить доступ к закрытому ключу, связанному с псевдонимом duke
. Если Вы позже хотите изменить пароль герцога с закрытым ключом, Вы используете команду как следующее:
keytool -keypasswd -alias duke -keypass dukekeypasswd -new newpass
Это изменяет пароль от "dukekeypasswd" до "newpass".
Пожалуйста, отметьте: пароль не должен фактически быть определен на командной строке или в сценарии, если это не для тестирования, или Вы находитесь на защищенной системе. Если Вы не определите необходимую опцию пароля на командной строке, то Вы будете запрошены это.
KeyStore
class, обеспеченный в java.security
пакет предоставляет четко определенные интерфейсы, чтобы получить доступ и изменить информацию в keystore. Для там возможно быть многократными различными конкретными реализациями, где каждая реализация состоит в том что для определенного типа keystore.
В настоящий момент два инструмента командной строки (keytool и jarsigner) и основанный на GUI инструмент под названием Средство осуществления политики используют keystore реализации. С тех пор KeyStore
публично доступно, пользователи могут записать дополнительные приложения безопасности, которые используют это.
Есть встроенная реализация по умолчанию, обеспеченная Oracle. Это реализует keystore как файл, используя собственный тип keystore (формат) под названием "JKS". Это защищает каждый закрытый ключ со своим отдельным паролем, и также защищает целостность всего keystore с (возможно отличающийся) пароль.
Реализации Keystore основаны на провайдере. Более определенно, интерфейсы приложения, предоставленные KeyStore
реализуются с точки зрения "Интерфейса Поставщика услуг" (SPI). Таким образом, есть соответствующий краткий обзор KeystoreSpi
class, также в java.security
пакет, который определяет методы Service Provider Interface, которые должны реализовать "провайдеры". (Термин "провайдер" относится к пакету или ряду пакетов, которые предоставляют конкретную реализацию подмножества служб, к которым может получить доступ API Безопасности Java.) Таким образом, чтобы обеспечить keystore реализацию, клиенты должны реализовать "провайдера" и предоставить реализацию подкласса KeystoreSpi, как описано в том, Как Реализовать Провайдера для Архитектуры Криптографии Java.
Приложения могут выбрать различные типы keystore реализаций от различных провайдеров, используя "getInstance" метод фабрики, предоставленный в KeyStore
class. Тип keystore определяет хранение и формат данных keystore информации, и алгоритмы, используемые, чтобы защитить частные / секретные ключи в keystore и целостности keystore непосредственно. Реализации Keystore различных типов не являются совместимыми.
keytool работает над любой основанной на файле keystore реализацией. (Это обрабатывает keystore расположение, которое передают к этому в командной строке как имя файла и преобразовывает это в FileInputStream, из которого это загружает keystore информацию.) jarsigner и policytool инструменты, с другой стороны, могут считать keystore из любого расположения, которое может быть определено, используя URL.
Для keytool и jarsigner, можно определить тип keystore в командной строке через-storetype опцию. Для Средства осуществления политики можно определить тип keystore через меню "Keystore".
Если Вы явно не определяете тип keystore, инструменты выбирают keystore реализацию, базируемую просто на значении keystore.type
свойство определяется в файле свойств безопасности. Файл свойств безопасности вызывают java.security, и это находится в каталоге свойств безопасности, java.home/lib/security
, где java.home является каталогом среды выполнения (каталог jre в SDK или высокоуровневый каталог Java 2 Среды выполнения).
Каждый инструмент добирается keystore.type
оцените и затем исследуйте всех установленных в настоящий момент провайдеров, пока это не находит тот, который реализует keystores того типа. Это тогда использует keystore реализацию от того провайдера.
KeyStore
class определяет статический названный метод getDefaultType
это позволяет приложениям, и апплеты получают значение keystore.type
свойство. Следующая строка кода создает экземпляр значения по умолчанию keystore тип (как определено в keystore.type
свойство):
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
Значение по умолчанию keystore тип является "jks" (собственный тип keystore реализации, обеспеченной Oracle). Это определяется следующей строкой в файле свойств безопасности:
keystore.type=jks
Чтобы иметь инструменты используют keystore реализацию кроме значения по умолчанию, можно изменить ту строку, чтобы определить различный тип keystore.
Например, если у Вас есть пакет провайдера, который предоставляет keystore реализацию для типа keystore, названного "pkcs12", измените строку на
keystore.type=pkcs12
Отметьте: случай не имеет значения в обозначениях типа keystore. Например, "JKS" считали бы тем же самым как "jks".
Они - числа, связанные с определенным объектом, и предназначаются, чтобы быть известными всем, кто должен доверить взаимодействиям тот объект. Открытые ключи используются, чтобы проверить подписи.
Если некоторые данные в цифровой форме подписываются, они были сохранены "идентификационными данными" объекта, и подписью, которая доказывает, что объект знает о данных. Данные представляются нековкие, подписываясь с закрытым ключом объекта.
Известный способ адресовать объект. В некоторых системах идентификационные данные являются открытым ключом в других, это может быть что-либо от UID Unix до Адреса электронной почты к Отличительному имени X.509.
Подпись вычисляется свыше некоторых данных, используя закрытый ключ объекта (подписывающее лицо, которое в случае сертификата также известно как выпускающий).
Они - числа, каждое из которых, как предполагается, известно только определенному объекту, закрытый ключ которого это (то есть, это, как предполагается, держится в секрете). Закрытые и открытые ключи существуют в парах во всех системах шифрования с открытым ключом (также называемый "открытым ключом crypto системы"). В типичном открытом ключе crypto система, такая как DSA, закрытый ключ соответствует точно одному открытому ключу. Закрытые ключи используются, чтобы вычислить подписи.
Объект является человеком, организацией, программой, компьютером, бизнесом, банком, или чем-то еще, чему Вы доверяете до некоторой степени.
В основном шифрование с открытым ключом требует доступа к открытым ключам пользователей. В крупномасштабной сетевой среде невозможно гарантировать, что предшествующие отношения между связывающимися объектами были установлены или что доверяемое хранилище существует со всеми используемыми открытыми ключами. Сертификаты были изобретены как решение этой проблемы распределения с открытым ключом. Теперь Центр сертификации (CA) может действовать как доверенная третья сторона. АВАРИЯ является объектами (например, фирмы), которые доверяются, чтобы подписаться (выпускают) сертификаты для других объектов. Предполагается, что АВАРИЯ только создаст допустимые и надежные сертификаты, поскольку они связываются юридическими соглашениями. Есть много общедоступных Центров сертификации, таких как
Используя keytool, возможно вывести на экран, импортировать, и экспортировать сертификаты. Также возможно генерировать самоподписанные сертификаты.
keytool в настоящий момент обрабатывает сертификаты X.509.
Стандарт X.509 определяет, какая информация может войти в сертификат, и описывает, как записать это (формат данных). Все данные в сертификате кодируются, используя два связанных стандарта под названием ASN.1/DER. Абстрактная синтаксическая нотация 1 описывает данные. Определенные Правила кодирования описывают единственный способ сохранить и передать те данные.
У всех сертификатов X.509 есть следующие данные, в дополнение к подписи:
Это идентифицирует, какая версия стандарта X.509 применяется к этому сертификату, который влияет на то, какая информация может быть определена в этом. К настоящему времени три версии определяются. keytool может импортировать и экспортировать v1, v2, и v3 сертификаты. Это генерирует v3 сертификаты.
Версия 1 X.509 была доступной с 1988, широко развертывается, и является самой универсальной.
Версия 2 X.509, представленная понятие предмета и уникальных идентификаторов выпускающего, чтобы обработать возможность повторного использования предмета и/или выпускающего, называет в течение долгого времени. Большинство документов профиля сертификата строго рекомендует, чтобы имена не были снова использованы, и что сертификаты не должны использовать уникальные идентификаторы. Сертификаты версии 2 широко не используются.
Версия 3 X.509 является новым (1996) и поддерживает понятие расширений, посредством чего любой может определить расширение и включать его в сертификат. Некоторые общие расширения в использовании сегодня: KeyUsage (ограничивает использование ключей к конкретным целям такой как "только для подписания"), и AlternativeNames (позволяет другим идентификационным данным также быть связанными с этим открытым ключом, например, имена DNS, Адреса электронной почты, IP-адреса). Расширения могут быть отмечены критические, чтобы указать, что расширение должно быть проверено и осуществляло/использовало. Например, если у сертификата есть расширение KeyUsage, отмеченное критический и набор к "keyCertSign" тогда, если этот сертификат представляется во время передачи SSL, это должно быть отклонено, поскольку расширение сертификата указывает, что связанный закрытый ключ должен только использоваться для того, чтобы подписать сертификаты а не для использования SSL.
Объект, который создал сертификат, ответственен за присвоение его порядковый номер, чтобы отличить его от других сертификатов, которые он выпускает. Эта информация используется многочисленными способами, например когда сертификат отменяется, его порядковый номер помещается в Список аннулированных сертификатов (CRL).
Это идентифицирует алгоритм, используемый CA, чтобы подписать сертификат.
Отличительное имя X.500 объекта, который подписал сертификат. Это обычно - CA. Используя этот сертификат подразумевает доверие объекту, который подписал этот сертификат. (Отметьте, что в некоторых случаях, такие как сертификаты CA корневого или верхнего уровня, выпускающий подписывает его собственный сертификат.)
Каждый сертификат допустим только для ограниченного количества времени. Этот период описывается датой начала и время и дата окончания и время, и может быть столь же коротким как несколько секунд или почти пока столетие. Выбранный срок действия зависит в ряде факторов, таких как сила закрытого ключа, используемого, чтобы подписать сертификат или количество, которое каждый готов заплатить за сертификат. Это - ожидаемый период, что объекты могут положиться на общедоступное значение, если связанный закрытый ключ не поставился под угрозу.
Имя объекта, открытый ключ которого сертификат идентифицирует. Это имя использует стандарт X.500, таким образом, это предназначается, чтобы быть уникальным через Интернет. Это - Отличительное имя X.500 (DN) объекта, например,
CN=Java Duke, OU=Java Software Division, O=Oracle Corporation, C=US
(Они обращаются к Общему названию предмета, Организационному Модулю, Организации, и Стране.)
Это - открытый ключ называемого объекта, вместе с идентификатором алгоритма, который определяет, какой открытый ключ crypto система этот ключ принадлежит и любые связанные основные параметры.
keytool может создать и управлять keystore "ключевыми" записями, что каждый содержит закрытый ключ и связанный сертификат "цепочка". Первый сертификат в цепочке содержит открытый ключ, соответствующий закрытому ключу.
Когда ключи сначала сгенерированы (см.-genkeypair команду), цепочка начинается содержащий единственный элемент, самоподписанный сертификат. Самоподписанный сертификат один, для которого выпускающий (подписывающее лицо) является тем же самым как предметом (объект, открытый ключ которого аутентифицируется сертификатом). Всякий раз, когда -genkeypair
команду вызывают, чтобы генерировать новую пару "открытый/закрытый ключ", она также обертывает открытый ключ в самоподписанный сертификат.
Позже, после того, как Запрос Подписания Сертификата (CSR) был сгенерирован (см.-certreq команду), и отправленный Центру сертификации (CA), ответ от CA импортируется (см.-importcert), и самоподписанный сертификат заменяется цепочкой сертификатов. У основания цепочки сертификат (ответ), выпущенный CA, аутентифицирующим открытый ключ предмета. Следующий сертификат в цепочке является тем, который аутентифицирует открытый ключ CA.
Во многих случаях это - самоподписанный сертификат (то есть, сертификат от CA, аутентифицирующего его собственный открытый ключ) и последний сертификат в цепочке. В других случаях CA может возвратить цепочку сертификатов. В этом случае нижний сертификат в цепочке является тем же самым (сертификат, подписанный CA, аутентифицируя открытый ключ ключевой записи), но второй сертификат в цепочке является сертификатом, подписанным различным CA, аутентифицируя открытый ключ CA, которому Вы отправили CSR. Затем, следующий сертификат в цепочке будет сертификатом, аутентифицирующим ключ второго CA, и так далее, пока самоподписанный "корневой" сертификат не будет достигнут. Каждый сертификат в цепочке (после первого) таким образом аутентифицирует открытый ключ подписывающего лица предыдущего сертификата в цепочке.
Многие АВАРИЯ только возвращает выпущенный сертификат без поддержки цепочки, особенно когда есть плоская иерархия (никакая промежуточная АВАРИЯ). В этом случае цепочка сертификата должна быть установлена от доверяемой информации сертификата, уже хранившей в keystore.
Различный формат ответа (определенный PKCS#7 стандарт) также включает цепочку сертификата поддержки, в дополнение к выпущенному сертификату. Оба формата ответа могут быть обработаны keytool.
Верхний уровень (корень) сертификат CA самоподписывается. Однако, доверие в открытый ключ корня не прибывает из корневого сертификата непосредственно (любой мог генерировать самоподписанный сертификат с отличительным именем, говорят, корневой CA VeriSign!), но из других источников как газета. Корневой открытый ключ CA широко известен. Единственная причина это сохранено в сертификате, состоит в том, потому что это - формат, понятый под большинством инструментов, таким образом, сертификат в этом случае только используется в качестве "механизма", чтобы транспортировать открытый ключ корневого CA. Прежде, чем Вы добавите корневой сертификат CA своему keystore, следует просмотреть это (использование -printcert
опция), и сравнивают выведенный на экран цифровой отпечаток с известным цифровым отпечатком (полученный из газеты, Веб-страницы корневого CA, и т.д.).
Файл сертификатов, названный "cacerts", находится в каталоге свойств безопасности, java.home/lib/security
, где java.home является каталогом среды выполнения (каталог jre в SDK или высокоуровневый каталог Java 2 Среды выполнения).
"cacerts" файл представляет keystore в масштабе всей системы с сертификатами CA. Системные администраторы могут сконфигурировать и управлять тем файлом, используя keytool, определяя "jks" как тип keystore. "cacerts" keystore файл поставляет с набором значения по умолчанию корневых сертификатов CA; перечислите их со следующей командой:
keytool -list -keystore java.home/lib/security/cacerts
Начальный пароль "cacerts" keystore файл является "changeit". Системные администраторы должны изменить тот пароль и право доступа значения по умолчанию того файла после установки SDK.
ВАЖНЫЙ: Проверьте Ваш cacerts
Файл: Так как Вы доверяете АВАРИИ cacerts
файл как объекты для подписания и издания сертификатов другим объектам, следует управлять cacerts
зарегистрируйте тщательно. cacerts
файл должен содержать только сертификаты об АВАРИИ, которой Вы доверяете. Это - Ваша обязанность проверить доверяемые корневые сертификаты CA, связанные в cacerts
файл и принимает Ваши собственные доверительные решения. Удалить недоверяемый сертификат CA из cacerts
файл, используйте удалить опцию keytool
команда. Можно найти cacerts
файл в каталоге установки JRE. Свяжитесь со своим системным администратором, если у Вас нет разрешения, чтобы отредактировать этот файл.
Сертификаты часто сохранены, используя печатаемый формат кодирования, определенный интернет-стандартом RFC 1421 вместо их двоичного кодирования. Этот формат сертификата, также известный как "Кодировка Base 64", облегчает сертификаты экспорта другим приложениям по электронной почте или через некоторый другой механизм.
Сертификаты, считанные -importcert
и -printcert
команды могут быть или в этом формате или в закодированном двоичном файле.
-exportcert
команда значением по умолчанию выводит сертификат в двоичном кодировании, но вместо этого выведет сертификат в печатаемом формате кодирования, если -rfc
опция определяется.
-list
команда значением по умолчанию печатает цифровой отпечаток SHA1 сертификата. Если -v
опция определяется, сертификат печатается в удобочитаемом формате, в то время как если -rfc
опция определяется, сертификат выводится в печатаемом формате кодирования.
В его печатаемом формате кодирования закодированный сертификат ограничивается вначале
-----BEGIN CERTIFICATE-----
и в конце
-----END CERTIFICATE-----
Отличительные имена X.500 используются, чтобы идентифицировать объекты, такие как те, которых называют subject
и issuer
(подписывающее лицо) поля сертификатов X.509. keytool поддерживает следующие подразделения:
Когда предоставление отличительного имени представляет в виде строки как значение a -dname
опция, что касается -genkeypair
команда, строка должна быть в следующем формате:
CN=cName, OU=orgUnit, O=org, L=city, S=state, C=countryCode
где все курсивные элементы представляют фактические значения, и вышеупомянутые ключевые слова являются сокращениями для следующего:
CN=commonName OU=organizationUnit O=organizationName L=localityName S=stateName C=country
Демонстрационная строка отличительного имени
CN=Mark Smith, OU=Java, O=Oracle, L=Cupertino, S=California, C=US
и демонстрационная команда, используя такую строку
keytool -genkeypair -dname "CN=Mark Smith, OU=Java, O=Oracle, L=Cupertino, S=California, C=US" -alias mark
Случай не имеет значения для сокращений ключевого слова. Например, "CN", "cn", и "Cn" все обрабатываются то же самое.
Вопросы порядка; каждый субкомпонент должен появиться в определяемом порядке. Однако, не необходимо иметь все субкомпоненты. Можно использовать подмножество, например:
CN=Steve Meier, OU=Java, O=Oracle, C=US
Если строковое значение отличительного имени содержит запятую, запятой нужно оставить "\" символ, когда Вы определяете строку на командной строке, как в
cn=Peter Schuster, ou=Java\, Product Development, o=Oracle, c=US
Никогда не необходимо определить строку отличительного имени на командной строке. Если это необходимо для команды, но не предоставляется на командной строке, пользователь запрашивается каждый из субкомпонентов. В этом случае запятой не должны оставить "\".
ВАЖНЫЙ: Убедитесь, что проверили сертификат очень тщательно прежде, чем импортировать это как доверяемый сертификат!
Просмотрите это сначала (использующий -printcert
команда, или -importcert
команда без -noprompt
опция), и удостоверяются что выведенное на экран соответствие цифрового отпечатка (ков) сертификата ожидаемые. Например, предположите, что кто-то отправляет или посылает Вам по электронной почте сертификат, и Вы помещаете его в названный файл /tmp/cert
. Прежде, чем Вы рассмотрите добавление сертификата Вашему списку доверяемых сертификатов, можно выполнить a -printcert
команда, чтобы просмотреть ее цифровые отпечатки, как в
keytool -printcert -file /tmp/cert Owner: CN=ll, OU=ll, O=ll, L=ll, S=ll, C=ll Issuer: CN=ll, OU=ll, O=ll, L=ll, S=ll, C=ll Serial Number: 59092b34 Valid from: Thu Sep 25 18:01:13 PDT 1997 until: Wed Dec 24 17:01:13 PST 1997 Certificate Fingerprints: MD5: 11:81:AD:92:C8:E5:0E:A2:01:2E:D4:7A:D7:5F:07:6F SHA1: 20:B6:17:FA:EF:E5:55:8A:D0:71:1F:E8:D6:9D:C0:37:13:0E:5E:FE SHA256: 90:7B:70:0A:EA:DC:16:79:92:99:41:FF:8A:FE:EB:90: 17:75:E0:90:B2:24:4D:3A:2A:16:A6:E4:11:0F:67:A4
Затем вызовите или иначе свяжитесь с человеком, который отправил сертификат, и сравните цифровой отпечаток (ки), что Вы видите с теми, что они показывают. Только если цифровые отпечатки равны, это, гарантировал, что сертификат не был заменен в пути с чьим-либо (например, атакующий) сертификат. Если бы такая атака имела место, и Вы не проверяли сертификат прежде, чем Вы импортировали это, то Вы закончили бы тем, что доверяли чему-либо, что атакующий подписал (например, файл JAR со злонамеренными файлами class внутри).
Отметьте: не требуется, что Вы выполняете a -printcert
команда до импорта сертификата, прежде, чем добавить сертификат списку доверяемых сертификатов в keystore, -importcert
команда распечатывает информацию о сертификате и запрашивает Вас проверять это. У Вас тогда есть опция прерывания работы импорта. Отметьте, однако, это только имеет место, вызываете ли Вы -importcert
команда без -noprompt
опция. Если -noprompt
опция дается, нет никакого взаимодействия с пользователем.
Большинство команд, работающих на keystore, требует пароля хранилища. Некоторые команды требуют частного пароля / пароля секретного ключа.
Пароли могут быть определены на командной строке (в -storepass
и -keypass
опции, соответственно). Однако, пароль не должен быть определен на командной строке или в сценарии, если это не для тестирования, или Вы находитесь на защищенной системе.
Если Вы не определите необходимую опцию пароля на командной строке, то Вы будете запрошены это.
Интернет-стандарт -dname
, -ext
, и т.д..
Интерфейс команды для keytool, измененного в Java SE 6.
keytool больше не выводит на экран ввод пароля когда вводящийся пользователями. Так как ввод пароля больше не может быть просмотрен когда вводящийся, пользователи будут запрошены повторно войти в пароли любое время, пароль устанавливается или изменяется (например, устанавливая начальную букву keystore пароль, или изменяя ключевой пароль).
Некоторые команды были просто переименованы, и другие команды, которые считают устаревшим, больше не перечисляются в этом документе. Все предыдущие команды (и переименованный и устаревший) все еще поддерживаются в этом выпуске и будут продолжать поддерживаться в будущих выпусках. Следующее суммирует все изменения, произведенные в keytool интерфейсе команды:
Переименованные команды:
-export
, переименованный к -exportcert
-genkey
, переименованный к -genkeypair
-import
, переименованный к -importcert
Команды, которые считают устаревшим и больше задокументированный: