Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

keytool - Ключ и Инструмент управления Сертификата

Управляет keystore (база данных) криптографических ключей, цепочек сертификата X.509, и доверял сертификатам.

РЕЗЮМЕ

keytool [ commands ]

keytool интерфейс команды изменил в Java SE 6. См. Раздел Изменений для подробного описания. Отметьте, что ранее определенные команды все еще поддерживаются.

ОПИСАНИЕ

keytool является ключом и утилитой управления сертификатом. Это позволяет пользователям администрировать свои собственные пары "открытый/закрытый ключ" и связанные сертификаты для использования в самоаутентификации (где пользователь аутентифицирует себя другим пользователям/службам), или целостность данных и службы аутентификации, используя цифровые подписи. Это также позволяет пользователям кэшировать открытые ключи (в форме сертификатов) их коллег передачи.

Сертификат является в цифровой форме подписанным заявлением от одного объекта (человек, компания, и т.д.), говоря, что у открытого ключа (и некоторая другая информация) некоторого другого объекта есть определенное значение. (См. Сертификаты.), Когда данные в цифровой форме подписываются, подпись может быть проверена, чтобы проверить целостность данных и подлинность. Целостность означает, что данные не были изменены или вмешались, и подлинность означает, что данные действительно прибывают из того, кто бы ни утверждает, что создал и подписал это.

keytool также позволяет пользователям администрировать секретные ключи, используемые в симметричном шифровании/дешифровании (например, ДЕС).

keytool хранит ключи и сертификаты в keystore.

КОМАНДА И ПРИМЕЧАНИЯ ОПЦИИ

Различные команды и их опции перечисляются и описываются ниже. Отметьте:

Значения по умолчанию опции

Ниже значения по умолчанию для различных значений опции.

-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 static getDefaultType method in
           java.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 символами долго. Иначе, пароль получается следующим образом:

Отметьте: Все другие опции, которые требуют паролей, такой как -keypass, -srckeypass, -destkeypass -srcstorepass, и -deststorepass, примите env и file модификаторы. (Не забудьте разделять опцию пароля и модификатор с двоеточием, (:).)

Пароль должен быть обеспечен для всех команд, которые получают доступ к keystore содержанию. Для таких команд, если a -storepass возможность не предоставляется в командной строке, пользователь запрашивается это.

Получая информацию от keystore, пароль является дополнительным; если никакой пароль не дается, целостность полученной информации не может быть проверена, и предупреждение выводится на экран.

-providerName provider_name

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

-providerClass provider_class_name

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

-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, CRL для 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.

Отметьте: Пользователи должны знать, что некоторые комбинации расширений (и другие поля сертификата), возможно, не соответствуют интернет-стандарту. См. То, чтобы попросить Расценить Соответствие Сертификата для деталей.

КОМАНДЫ

Создание или Добавление Данных к Keystore

-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.

Значение опции может быть установлено в одной из этих двух форм:

  1. ([+-] nnn [ymdHMS]) +
  2. [yyyy/mm/dd] [HH:MM:SS]

С первой формой время проблемы смещается на указанное значение с текущего времени. Значение является связью последовательности значений 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. В последнем случае кодирование должно быть ограничено вначале строкой, которая запускается с "-----, НАЧИНАЮТСЯ", и ограниченный в конце строкой, которая запускается с "-----КОНЕЦ".

Вы импортируете сертификат по двум причинам:

  1. добавить это к списку доверяемых сертификатов, или
  2. импортировать ответ сертификата, полученный от CA как результат передачи Запроса Подписания Сертификата (см.-certreq команду) к тому CA.

То, какой тип импорта предназначается, обозначается значением -alias опция:

  1. Если псевдоним не указывает на ключевую запись, то keytool предполагает, что Вы добавляете доверяемую запись сертификата. В этом случае псевдоним не должен уже существовать в keystore. Если псевдоним действительно уже существует, то keytool выводы ошибка, так как уже есть доверяемый сертификат для того псевдонима, и не импортирует сертификат.
  2. Если псевдоним указывает на ключевую запись, то keytool предполагает, что Вы импортируете ответ сертификата.

Импорт Нового Доверяемого Сертификата

Прежде, чем добавить сертификат keystore, keytool пытается проверить, что это, пытаясь создать цепочку доверия от того сертификата до самоподписанного сертификата (принадлежащий корневому CA), используя доверяло сертификатам, которые уже доступны в keystore.

Если -trustcacerts опция была определена, дополнительные сертификаты рассматривают для цепочки доверия, а именно, сертификаты в файле, названном "cacerts".

Если keytool не в состоянии установить доверительный путь от сертификата, который будет импортирован до самоподписанного сертификата (или от keystore или от "cacerts" файла), информация о сертификате распечатывается, и пользователь запрашивается проверить это, например, сравнивая выведенные на экран цифровые отпечатки сертификата с цифровыми отпечатками, полученными из некоторого другого (доверяемого) источника информации, который мог бы быть владельцем сертификата непосредственно. Очень делайте все возможное гарантировать, что сертификат допустим до импорта этого как "доверяемый" сертификат! - см. ТО, ЧТОБЫ ПОПРОСИТЬ Расценить Импорт Сертификаты, Которым доверяют. У пользователя тогда есть опция прерывания работы импорта. Если -noprompt опция дается, однако, не будет никакого взаимодействия с пользователем.

Импорт Ответа Сертификата

Импортируя ответ сертификата, ответ сертификата проверяется, используя, доверял сертификатам от keystore, и дополнительно используя сертификаты, сконфигурированные в "cacerts" keystore файл (если -trustcacerts опция была определена).

Методы определения, доверяют ли ответу сертификата, описываются в следующем:

Если открытый ключ в ответе сертификата соответствует открытый ключ пользователя, уже сохраненный под псевдонимом, старая цепочка сертификата заменяется новой цепочкой сертификата в ответе. Старая цепочка может только быть заменена, если допустимый 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.

Управление 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.

Прежде, чем Вы импортируете ответ сертификата из 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

Как только Вы импортировали сертификат, аутентифицирующий открытый ключ 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 инструмент, чтобы заверить Вашу подпись.

Импорт Keystore

Команда "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

Генерирование Сертификатов для Типичного Сервера SSL

Следующее является 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

keystore является складом для криптографических ключей и сертификатов.

Сертификат

Сертификат (также известный как сертификат с открытым ключом) является в цифровой форме подписанным заявлением от одного объекта (выпускающий), говоря, что у открытого ключа (и некоторая другая информация) другого объекта (предмет) есть некоторое определенное значение.

Отличительные имена X.500

Отличительные имена 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 со злонамеренными файлами класса внутри).

Отметьте: не требуется, что Вы выполняете a -printcert команда до импорта сертификата, прежде, чем добавить сертификат списку доверяемых сертификатов в keystore, -importcert команда распечатывает информацию о сертификате и запрашивает Вас проверять это. У Вас тогда есть опция прерывания работы импорта. Отметьте, однако, это только имеет место, вызываете ли Вы -importcert команда без -noprompt опция. Если -noprompt опция дается, нет никакого взаимодействия с пользователем.

Предупреждение Относительно Паролей

Большинство команд, работающих на keystore, требует пароля хранилища. Некоторые команды требуют частного пароля / пароля секретного ключа.

Пароли могут быть определены на командной строке (в -storepass и -keypass опции, соответственно). Однако, пароль не должен быть определен на командной строке или в сценарии, если это не для тестирования, или Вы находитесь на защищенной системе.

Если Вы не определите необходимую опцию пароля на командной строке, то Вы будете запрошены это.

Предупреждение Относительно Соответствия Сертификата

Интернет-стандарт RFC 5280 определил профиль при приспосабливании сертификатам X.509, который включает, какие значения и комбинации значения допустимы для полей сертификата и расширений. keytool не осуществил все эти правила, таким образом, он может генерировать сертификаты, которые не соответствуют стандарту, и эти сертификаты могли бы быть отклонены JRE или другими приложениями. Пользователи должны удостовериться, что они предоставляют корректные возможности для -dname, -ext, и т.д..

СМ. ТАКЖЕ

ИЗМЕНЕНИЯ

Интерфейс команды для keytool, измененного в Java SE 6.

keytool больше не выводит на экран ввод пароля когда вводящийся пользователями. Так как ввод пароля больше не может быть просмотрен когда вводящийся, пользователи будут запрошены повторно войти в пароли любое время, пароль устанавливается или изменяется (например, устанавливая начальную букву keystore пароль, или изменяя ключевой пароль).

Некоторые команды были просто переименованы, и другие команды, которые считают устаревшим, больше не перечисляются в этом документе. Все предыдущие команды (и переименованный и устаревший) все еще поддерживаются в этом выпуске и будут продолжать поддерживаться в будущих выпусках. Следующее суммирует все изменения, произведенные в keytool интерфейсе команды:

Переименованные команды:

Команды, которые считают устаревшим и больше задокументированный:

Oracle и/или его филиалы Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами