криптопро keytool

Генерация ключевой пары

Генерация ключевой пары (открытый ключ / закрытый ключ) является одной из наиболее распространенных задач, для которых используется утилита Keytool. Сгенерированная пара ключей вставляется в файл KeyStore как пара ключей с собственной подписью. Вот общий формат командной строки для генерации пары ключей:

-genkeypair
    -alias alias
    -keyalg keyalg
    -keysize keysize
    -sigalg sigalg
    -dname dname
    -keypass keypass
    -validity valDays
    -storetype storetype
    -keystore keystore
    -storepass storepass
    -providerClass provider_class_name
    -providerArg provider_arg
    -v
    -protected
    -Jjavaoption

Аргументы объяснены в разделе Аргументы Keytool. Не все эти аргументы нужны и многие являются не обязательными. Утилита сообщит вам, если вы пропустили обязательный аргумент. Вот пример команды, которая импортирует сертификат в KeyStore.

"C:\Program FilesJavajdk1.8.0_111binkeytool"
    -importcert
    -alias testkey
    -keypass 123456
    -storetype JKS
    -keystore keystore2.jks
    -file cert.cert
    -rfc
    -storepass abcdef

Як подати документ через сервіс центрального засвідчувального органу?

Сервіс підтримує особисті ключі та сертифікати відкритих ключів усіх кваліфікованих надавачів електронних довірчих послуг. Для створення кваліфікованого електронного підпису або печатки необхідно мати чинні особисті ключі та сертифікати, видані кваліфікованим надавачем електронних довірчих послуг.

Удаление записи хранилища ключей

Так же в в утилите keytool имеется команда, которая может удалить запись из хранилища ключей: delete. Вот формат этой команды:

-delete
    -alias alias
    -storetype storetype
    -keystore keystore
    -storepass storepass
    -providerName provider_name
    -providerClass provider_class_name
    -providerArg provider_arg
    -v
    -protected
    -Jjavaoption

Вот пример вызова команды delete. Не забудьте удалить разрывы строк перед запуском!

"C:\Program FilesJavajdk1.8.0_111binkeytool"
    -delete
    -alias testkey
    -storetype JKS
    -keystore keystore.jks
    -storepass abcdef

Эта команда удаляет запись хранилища с псевдонимом testkey хранящегося в файле keystore.jks.

КОМАНДЫ

Создание или Добавление Данных к 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 опция была определена).

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

• Если ответ является единственным сертификатом X.509, keytool пытается установить доверительную цепочку, запускающуюся при ответе сертификата и заканчивающуюся в самоподписанном сертификате (принадлежащий корневому CA). Ответ сертификата и иерархия сертификатов, используемых, чтобы аутентифицировать ответ сертификата, формируют новую цепочку сертификата псевдонима. Если доверительная цепочка не может быть установлена, ответ сертификата не импортируется. В этом случае keytool не распечатывает сертификат и запрашивает пользователя проверять это, потому что очень трудно (если не невозможный) для пользователя решить, что подлинность сертификата отвечает.
• Если ответ PKCS#7 отформатированная цепочка сертификата или последовательность сертификатов X.509, цепочка упорядочивается с пользовательским сертификатом, сначала сопровождаемым нулем или большим количеством сертификатов CA. Если цепочка заканчивается самоподписанным корневым сертификатом CA и -trustcacerts опция была определена, keytool попытается соответствовать ее с любым из доверяемых сертификатов в keystore или “cacerts” keystore файл. Если цепочка не заканчивается самоподписанным корневым сертификатом CA и -trustcacerts опция была определена, keytool попытается найти один от доверяемых сертификатов в keystore или “cacerts” keystore файл и добавить это до конца цепочки. Если сертификат не находится и -noprompt опция не определяется, информация последнего сертификата в цепочке распечатывается, и пользователь запрашивается проверить это.

Если открытый ключ в ответе сертификата соответствует открытый ключ пользователя, уже сохраненный под псевдонимом, старая цепочка сертификата заменяется новой цепочкой сертификата в ответе. Старая цепочка может только быть заменена, если допустимый keypass, пароль, используемый, чтобы защитить закрытый ключ записи, предоставляется. Если никакой пароль не обеспечивается, и пароль с закрытым ключом отличается от keystore пароля, пользователь запрашивается это.

Эту команду назвали -import в предыдущих выпусках. Это старое название все еще поддерживается в этом выпуске и будет поддерживаться в будущих выпусках, но для разъясняют, что новое имя, -importcert, предпочитается, продвигаясь.

-selfcert
{-alias alias}
{-sigalg sigalg} {-dname dname}
{-validity valDays} [-keypass keypass]
{-storetype storetype}
{-keystore keystore} [-storepass storepass]
{-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}

Generates an X.509 v3 self-signed certificate,
using keystore information including the private key and
public key associated with alias. If dname is
supplied at the command line, it is used as the
X.500 Distinguished Name for
both the issuer and subject of the
certificate. Otherwise, the X.500 Distinguished Name associated
with alias (at the bottom of its existing certificate
chain) is used.

The generated certificate is stored as a single-element certificate chain
in the keystore entry identified by alias, where it replaces the
existing certificate chain.

sigalg specifies the algorithm that should be used to
sign the certificate.

In order to access the private key, the appropriate password must be
provided, since private keys
are protected in the keystore with a password. If keypass is not
provided at the command line, and is different from the password used to
protect the integrity of the keystore, the user is prompted for it.

valDays tells the number of days for which the certificate
should be considered valid.

-identitydb
{-file idb_file}
{-storetype storetype}
{-keystore keystore} [-storepass storepass]
{-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}

Reads the JDK 1.1.x-style identity database from the file
idb_file, and adds its entries to the keystore.
If no file is given, the identity database is read from stdin.
If a keystore does not exist, it is created.

Only identity database entries (“identities”) that were marked as
trusted will
be imported in the keystore. All other identities will be ignored.
For each trusted identity, a keystore entry will be created.
The identity’s name is used as the “alias” for the keystore entry.

The private keys from trusted identities will all be encrypted
under the same password, storepass. This is the same password that
is used to protect the keystore’s integrity.
Users can later assign individual passwords to those private keys
by using the “-keypasswd” keytool command option.

An identity in an identity database may hold more than one
certificate, each certifying the same public key. But a keystore
key entry for a private key has that private key and
a single “certificate chain” (initially just a single certificate),
where the first certificate in the chain
contains the public key corresponding to the private key.
When importing the information from an identity, only the first
certificate of the identity is stored in the keystore.
This is because an identity’s name in an
identity database is used as the alias for
its corresponding keystore entry, and alias names are unique
within a keystore,

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

Если -rfc определяется, keytool печатает сертификат в режиме PEM как определено интернет-стандартом RFC 1421.

Если сертификат читается из файла или stdin, это может быть или закодированный двоичный файл или в печатаемом формате кодирования, как определено интернет-стандартом RFC 1421

Отметьте: Эта опция может использоваться независимо от keystore.

-printcrl -file crl_ {-v}

Читает список аннулированных сертификатов (CRL) из файла crl_file.

Список аннулированных сертификатов (CRL) является списком цифровых сертификатов, которые были отменены Центром сертификации (CA), который выпустил их. CA генерирует crl_file.

Отметьте: Эта опция может использоваться независимо от keystore.

Управление Keystore

-keyclone
{-alias alias}
[-dest dest_alias]
[-keypass keypass] [-new new_keypass]
{-storetype storetype}
{-keystore keystore} [-storepass storepass]
{-providerName provider_name}
{-providerClass provider_class_name {-providerArg provider_arg}}
{-v} {-protected} {-Jjavaoption}

Creates a new keystore entry, which has the same private key and
certificate chain as the original entry if it’s a private key entry, or has
the same secret key if it’s a secret key entry.

The original entry is identified by alias (which defaults
to “mykey” if not provided).
The new (destination) entry is identified by dest_alias.
If no destination alias is supplied at the command
line, the user is prompted for it.

If the private/secret key password is different from the keystore password,
then the entry will only be cloned if a valid keypass is
supplied. This is the password used to protect the key
associated with alias. If no key password is supplied at the command
line, and the key password is different from the keystore password,
the user is prompted for it.

The key in the cloned entry
may be protected with a different password, if desired. If no
-new option is supplied at the command line, the
user is prompted for the new entry’s password (and may choose to
let it be the same as for the cloned entry’s private/secret key).

-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

Руководство по настройке

После установки токена JaCarta PKI в USB порт сервера и запуска системы проверяем, что новое устройство обнаружено и появилось в списке:

lsusb

В нашем случае это Bus 004 Device 003: ID 24dc:0101

Для диагностики считывателей можно воспользоваться утилитой pcsc-tools из проекта security:chipcard (software.opensuse.org).

Запускается командой:

pcsc_scan

Пока не установлены все необходимые пакеты, информация о токене не отобразится.

Установка драйверов и ПО для работы с JaCarta PKI

На странице Поддержки сайта «Аладдин Р.Д.» загружаем Документацию и программное обеспечение для работы только с JaCarta PKI

Согласно Руководству по внедрению «JaCarta для Linux» пункт 4.2., первым делом требуется установить пакеты pcsc-lite, ccid и libusb.

Для работы утилиты управления JaCarta необходимо установить следующие компоненты:

• PC/SC Lite — промежуточный слой для обеспечения доступа к смарт-картам по стандарту PC/SC, пакет pcsc-lite.
• Библиотеки ccid и libusb для работы с USB-ключами, смарт-картами и считывателями смарт-карт.

Выполняем проверку наличия этих пакетов и установку:

zypper search pcsc-lite

zypper search libusb

zypper install pcsc-lite

zypper search CCID

zypper install pcsc-ccid

zypper search CCID

zypper install libusb

В итоге пакет pcsc-lite был обновлен, CCID установлен, libusb никаких действия не требовалось.

Следующими двумя командами выполняем установку пакета с драйверами и программным обеспечением непосредственно для работы с JaCarta PKI:

zypper install idprotectclientlib-637.03-0.x86_64.rpm

zypper install idprotectclient-637.03-0.x86_64.rpm

Проверяем, что драйверы и ПО для JaCarta PKI установились:

zypper search idprotectclient

При попытках заставить работать SafeNet eToken PRO я нашел информацию, что предустановленный в SLES пакет openct — Library for Smart Card Readers может конфликтовать с pcsc-lite — PCSC Smart Cards Library, установку которого требует руководство Аладдин Р.Д.

zypper search openct

Поэтому пакет openct удаляем:

rpm -e openct

Теперь все необходимые драйверы и ПО для работы с токеном установлены.

Выполняем диагностику с помощью утилиты pcsc-tools и убеждаемся, что JaCarta определяется в операционной системе:

pcsc_scan

Установка пакетов КриптоПро CSP

При установке КриптоПро CSP по умолчанию нужные пакеты для работы с токенами и смарт-картами отсутствуют.

zypper search cprocsp

Выполняем установку в CSP компонента поддержки JaCarta components for CryptoPro CSP

zypper install cprocsp-rdr-jacarta-64-3.6.408.683-4.x86_64.rpm

Некоторые компоненты имеют зависимости. Так, например, если попытаться выполнить установку пакета поддержки SafeNet eToken PRO cprocsp-rdr-emv-64-4.0.9944-5.x86_64.rpm — EMV/Gemalto support module, то получим сообщение о необходимости сначала установить базовый компонент CSP поддержки считывателей cprocsp-rdr-pcsc-64-4.0.9944-5.x86_64.rpm — PC/SC components for CryptoPro CSP readers:

zypper install cprocsp-rdr-emv-64-4.0.9944-5.x86_64.rpm
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides cprocsp-rdr-pcsc-64 >= 4.0 needed by cprocsp-rdr-emv-64-4.0.9944-5.x86_64
 Solution 1: do not install cprocsp-rdr-emv-64-4.0.9944-5.x86_64
 Solution 2: break cprocsp-rdr-emv-64-4.0.9944-5.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c] (c): c

Устанавливаем базовые пакеты поддержки считывателей и ключевых носителей:

zypper install cprocsp-rdr-pcsc-64-4.0.9944-5.x86_64.rpm

zypper install lsb-cprocsp-pkcs11-64-4.0.9944-5.x86_64.rpm

Теперь можно установить модули для работы с остальными видами носителей и компонент GUI:

zypper install cprocsp-rdr-emv-64-4.0.9944-5.x86_64.rpm

zypper install cprocsp-rdr-novacard-64-4.0.9944-5.x86_64.rpm
zypper install cprocsp-rdr-mskey-64-4.0.9944-5.x86_64.rpm
zypper install cprocsp-rdr-gui-gtk-64-4.0.9944-5.x86_64.rpm

Проверяем итоговую конфигурацию КриптоПро CSP:

zypper search cprocsp
Loading repository data...
Reading installed packages...

S | Name | Summary | Type
---+-----------------------------+----------------------------------------------------+--------
i+ | cprocsp-curl-64 | CryptoPro Curl shared library and binaris. Build 9944. | package
i+ | cprocsp-rdr-emv-64 | EMV/Gemalto support module | package
i+ | cprocsp-rdr-gui-gtk-64 | GUI components for CryptoPro CSP readers. Build 9944. | package
i+ | cprocsp-rdr-jacarta-64 | JaCarta components for CryptoPro CSP. Build 683. | package
i+ | cprocsp-rdr-mskey-64 | Mskey support module | package
i+ | cprocsp-rdr-novacard-64 | Novacard support module | package
i+ | cprocsp-rdr-pcsc-64 | PC/SC components for CryptoPro CSP readers. Build 9944.| package
i+ | lsb-cprocsp-base | CryptoPro CSP directories and scripts. Build 9944. | package
i+ | lsb-cprocsp-ca-certs | CA certificates. Build 9944. | package
i+ | lsb-cprocsp-capilite-64 | CryptoAPI lite. Build 9944. | package
i+ | lsb-cprocsp-kc2-64 | CryptoPro CSP KC2. Build 9944. | package
i+ | lsb-cprocsp-pkcs11-64 | CryptoPro PKCS11. Build 9944. | package
i+ | lsb-cprocsp-rdr-64 | CryptoPro CSP readers. Build 9944. | package


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

/etc/init.d/cprocsp restart
/etc/init.d/cprocsp status

Настройка и диагностика КриптоПро CSP

Проверим, видит ли криптографический провайдер наш токен и другие доступные типы носителей следующими командами:

/opt/cprocsp/bin/amd64/csptest -card -enum -v –v

/opt/cprocsp/bin/amd64/csptest -enum -info -type PP_ENUMREADERS | iconv -f cp1251

/opt/cprocsp/sbin/amd64/cpconfig -hardware reader -view -f cp1251

Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00 — это наш носитель.

Следуя инструкции КриптоПро CSP для Linux. Настройка, выполняем его регистрацию в криптографическом провайдере:

/opt/cprocsp/sbin/amd64/cpconfig -hardware reader -add "Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00"

В результате выполнения в конфигурационный файл /etc/opt/cprocsp/config64.ini
в раздел [KeyDevices\PCSC] будет добавлена запись:

[KeyDevices\PCSC\"Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00"\Default]


Чтобы выполнить требования Формуляра, Правил пользования и Руководства администратора безопасности КриптоПро CSP:

Использование СКЗИ «КриптоПро CSP» версии 4.0 с выключенным режимом усиленного контроля использования ключей не допускается. Включение данного режима описано в документах ЖТЯИ.00087-01 91 02. Руководство администратора безопасности.

Необходимо включить режим усиленного контроля использования ключей:

/opt/cprocsp/sbin/amd64/cpconfig -ini '\config\parameters' -add long StrengthenedKeyUsageControl 1

Проверяем, что режим включен:

cat /etc/opt/cprocsp/config64.ini | grep StrengthenedKeyUsageControl

Выполняем перезапуск службы криптографического провайдера:

/etc/init.d/cprocsp restart
/etc/init.d/cprocsp status

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

/opt/cprocsp/bin/amd64/csptest -keyset –verifycontext

/opt/cprocsp/bin/amd64/csptest -keyset -verifycontext -enum –unique

CSP (Type:80) v4.0.9017 KC2 Release Ver:4.0.9944 OS:Linux CPU:AMD64 FastCode:REA
AcquireContext: OK. HCRYPTPROV: 16052291
alfa_shark1                        |SCARD\JACARTA_4E3900154029304C\CC00\E9F6
OK.
Total: SYS: 0.000 sec USR: 0.000 sec UTC: 4.560 sec
[ErrorCode: 0x00000000]

Работа с токеном JaCarta PKI

Запустим программу Xming (X11 forwarding) на своей станции, чтобы по SSH иметь возможность открывать и работать с графическими интерфейсами нужных утилит.

После установки IDProtectClient — программного обеспечения для работы с JaCarta PKI, на сервере в папке /usr/share/applications появились два файла:

Athena-IDProtectClient.desktop
Athena-IDProtectManager.desktop

Это ярлыки, в которых можно посмотреть параметры запуска утилит Exec=/usr/bin/SACTools

Запустим утилиту IDProtectPINTool.

С помощью нее задаются и меняются PIN-коды доступа к токену.

/usr/bin/IDProtectPINTool

При первой инициализации токена будет полезна ссылка, содержащая PIN-коды (пароли) ключевых носителей по умолчанию

Программа IDProtect_Manager позволяет просматривать информацию о токене и контейнере с ключами и сертификатом:

/usr/bin/IDProtect_Manager

Для доступа к контейнеру с ключами нужно ввести пароль:

Для работы с SafeNet Authentication Client eToken PRO существуют аналогичные программы — SafeNet Authentication Client Monitor и SafeNet Authentication Client Tools, которые запускаются так:

/usr/bin/SACMonitor
/usr/bin/SACTools

Выполнять операции непосредственно с ключевыми контейнерами удобнее в интерфейсе криптографического провайдера КриптоПро JavaCSP:

/jdk1.8.0_181/jre/bin/java ru.CryptoPro.JCP.ControlPane.MainControlPane


Для отображения информации о содержимом контейнера с ключами можно выполнить команду:

/opt/cprocsp/bin/amd64/csptest -keyset -cont '\\.\Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00\alfa_shark1' -info

Для диагностики контейнера используется эта же команда с ключом –check

/opt/cprocsp/bin/amd64/csptest -keyset -cont '\\.\Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00\alfa_shark' –check

Потребуется ввести пароль от контейнера:

Программное извлечение ключей

В общем виде пример извлечения закрытого ключа и сертификата открытого ключа из контейнера на токене с помощью КриптоПро Java CSP следующий:

import ru.CryptoPro.JCP.KeyStore.JCPPrivateKeyEntry;
import ru.CryptoPro.JCP.params.JCPProtectionParameter;


 KeyStore keyStore = KeyStore.getInstance("Aladdin R.D. JaCarta [SCR Interface] (000000000000) 00 00", "JCSP");
            keyStore.load(null, null);

        JCPPrivateKeyEntry entry = null;
        X509Certificate certificate = null;
        PrivateKey privateKey = null;

        try {
         
            entry = (JCPPrivateKeyEntry) keyStore.getEntry(keyAlias,
                    new JCPProtectionParameter(pwd));
            
            certificate = (X509Certificate) entry.getCertificate();
            privateKey = entry.getPrivateKey();
         
        } catch (UnrecoverableEntryException | NullPointerException e) {
            LOGGER.log(Level.WARNING, PRIVATE_KEY_NOT_FOUND + keyAlias + ExceptionUtils.getFullStackTrace(e));
        }

Если действовать так:

Key key = keyStore.getKey(keyAlias, pwd);

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

Результаты

Отторгаемый ключевой носитель-токен установлен во внутренний USB-порт сервера.

Само серверное оборудование опломбировано и размещается в помещении с ограниченным доступом.

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

Полезные ссылки

1. Документация Aladdin-RD JaCarta
2. wiki.astralinux.ru — Работа с КриптоПро CSP
3. Перечень кодов ошибок объектной модели компонентов Microsoft COM Error Codes (Security and Setup)
4. СКЗИ КриптоПро CSP 4.0 ФКН (Gemalto)
5. Утилита диагностики считывателей pcsc-tools из проекта security:chipcard (software.opensuse.org)
6. КриптоПро CSP для Linux. Настройка.
7. Aladdin-RD PIN-коды (пароли) ключевых носителей по умолчанию

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

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

• Всей команде и именам опции предшествует знак “минус” (-).
• Возможности для каждой команды могут быть предоставлены в любом порядке.
• Все элементы, не выделенные курсивом или в фигурных скобках или квадратных скобках, обязаны появляться, как.
• Фигурные скобки, окружающие опцию обычно, показывают, что значение по умолчанию будет использоваться, если опция не будет определена на командной строке. Фигурные скобки также используются вокруг -v, -rfc, и -J опции, у которых только есть значение, если они появляются на командной строке (то есть, у них нет никаких значений “значения по умолчанию” кроме не существующими).
• Скобки, окружающие опцию, показывают, что пользователь запрашивается значение (я), если опция не определяется на командной строке. (Для a -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 static getDefaultType method in
           java.security.KeyStore

-file stdin if reading, stdout if writing

-protected false

В генерировании пары “открытый/закрытый ключ” алгоритм подписи (-sigalg опция) получается из алгоритма базового закрытого ключа:

• Если базовый закрытый ключ имеет тип “DSA”,-sigalg значения по умолчанию опции к “SHA1withDSA”
• Если базовый закрытый ключ имеет тип “RSA”,-sigalg значения по умолчанию опции к “SHA256withRSA”.
• Если базовый закрытый ключ имеет тип “EC”,-sigalg значения по умолчанию опции к “SHA256withECDSA”.

Пожалуйста, консультируйтесь со Спецификацией API Архитектуры Криптографии Java & Ссылкой для полного списка-keyalg и-sigalg, из которого можно выбрать.

Общие Опции

-v опция может появиться для всех команд кроме -help. Если это появляется, это показывает “многословный” режим; больше информации будет предоставлено в выводе.

Есть также a -Jjavaoption опция, которая может появиться для любой команды. Если это появляется, через указанную строку javaoption проходят непосредственно к интерпретатору Java. Эта опция не должна содержать пробелы. Это полезно для корректировки использования памяти или среды выполнения. Для списка возможных опций интерпретатора ввести java -h или java -X в командной строке.

Эти опции могут появиться для всех команд, работающих на keystore:

-storetype storetype

Этот спецификатор определяет тип 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 поддерживает эти именованные (нечувствительные к регистру) расширения:

Для имени как 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.

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

Примеры сценариев при импорте и экспорте сертификата

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

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

Словарный запас

Определение X.509 сертификатов есть в архиве ITU-T

Certificate  ::=  SEQUENCE  {
     tbsCertificate       TBSCertificate,
     signatureAlgorithm   AlgorithmIdentifier,
     signatureValue       BIT STRING  }

TBSCertificate  ::=  SEQUENCE  {
     version         [0]  EXPLICIT Version DEFAULT v1,
     serialNumber         CertificateSerialNumber,
     signature            AlgorithmIdentifier,
     issuer               Name,
     validity             Validity,
     subject              Name,
     subjectPublicKeyInfo SubjectPublicKeyInfo,
     issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                          -- If present, version MUST be v2 or v3

Для того, чтобы досконально понять обозначения и синтаксис, придется читать спеки X.680 редакции 2008 г., где есть полное описание ASN.1. В понятиях ASN.1SEQUENCE обозначает примерно то же самое, что и struct в Си. Это может сбить с толку, ведь по семантике оно должно было соответствовать скорее массиву. И тем не менее.

Стандарт X.690 определяет следующие правила кодирования структур данных, созданных в соответствии с ASN.1: BER (Basic Encoding Rules), CER (Canonical Encoding Rules), DER (Distinguished Encoding Rules). Есть даже XER (XML Encoding Rules), который на практике мне никогда не встречался.

Да, но для чего нужны сертификаты X.509, которые доставляют столько головной боли? Первая и основная функция сертификатов X.509 — служить хранилищем открытого или публичного ключа PKI (public key infrastructure). К этой функции нареканий нет, а вот со второй не все так однозначно.

Вторая функция сертификатов X.509 заключается в том, чтобы предъявитель сего был принят человеком, либо программой в качестве истинного владельца некоего цифрового актива: доменного имени, веб сайта и пр. Это получается по-разному, далеко не все сертификаты имеют высокую ликвидность, если пользоваться финансовой терминологией.

Как конвертировать ключи приват банка в m. doc?

В программе M.E.Doc все документы мы подписываем электронными цифровыми подписями. ЭЦП Вы можете получить в аккредитованных центрах, но стоит обратить внимание, что программа M.E.Doc может работать с определенными АЦСК, а именно:

• АЦСК «Україна»;
• АЦСК ІДД ДФС;
• АЦСК «MasterKey»;
• АЦСК органів юстиції України;
• АЦСК Укрзалізниці;
• АЦСК ПАТ «УкрСиббанк»;
• АЦСК ДП «УСС»;
• АЦСК «Приват Банк».

Сейчас мы рассмотрим, как успешно использовать ключи Приват Банка в программе (мы будем использовать ключи для юридического лица). Ключ приват банка – это файл с расширением JKS. Для подписания отчетов в программе нам необходимо конвертировать ключ для понятного программе расширения zs2. Запускаем M.E.Doc, далее «Адміністрування» – «Сертифікати».

В открывшемся окне открываем вкладку «Сервіс» – «Конвертація ключа JKS».

Программа предложит выбрать файл ключа (он должен быть у Вас на компьютере или на флешке). Затем необходимо указать путь куда хотим сохранить конвертированный вариант ключа, в нашем случае, это: «C:UsersVadimDocumentsKey_convert». В нижнем поле вводим пароль ключа JKS и нажимаем «Конвертувати».

Если все сделано верно, то M.E.Doc сообщит об успешной конвертации.

В папке конечного результата, у нас должно появиться 2 файла с расширением. zs2 (это непосредственно наши конвертированные ключи) и 4 файла сертификатов .crt. Если вы делали конвертацию ключей для физического лица без печати, то у Вас будет 1 файл .zs2, и 2 сертификата .crt. Возвращаемся в вкладку “Сертифікати”, нажимаем на кнопку добавить (на рисунке пункт 1.), выбираем все полученные сертификаты из папки в которую конвертировали ключи и нажимаем кнопку открыть.

После загрузятся сертификаты Вашего предприятия и программа предложит Вам «Змінити налаштування комплекту підписів», в предложенном запросе выберете «Так».

В меню настройки подписей, нажав на стрелочку напротив типа документов (к примеру «Звітність») выберите перечень подписей, которые необходимо ставить на данный тип документов – нажмите «Ок».

Личные данные для заполнения

Сразу после регистрации в “Дія” рекомендуется указать персональную информацию о себе. Это такие данные, как:

• ФИО;
• идентификационный номер налогоплательщика;
• дата рождения;
• номер мобильного телефона;
• адрес электронной почты;
• пол.

В зависимости от выбранного способа регистрации, паспортные данные, а также информация о прописке или подтягиваются автоматически, или это нужно выполнить самостоятельно. Аналогичную информацию понадобится указать и при регистрации через мобильное приложение.

Послідовність дій користувача

1. В першому кроці зробіть наступне:

2. В наступному кроці зробіть таке:

3. Третім кроком буде надання результату підписання документа.

Кнопку “Зберегти” використовують для збереження підписаного файлу у файловій системі комп’ютера користувача. Принцип збереження відбувається так само, як й у звичайному випадку завантаження файлу переглядачем.

Кнопку “Назад” використовують для повернення на початкову сторінку сервісу. При цьому завантаження підписаних файлів не відбувається, результати створення підпису скасовуються.

Зауважте, що під час роботи сервісу інформація, яка міститься у файлах користувача, оброблюється в переглядачі, та не передається на сторону ЦЗО.

Сценарий №1 — найти следующего в связке

Связка сертификатов — Объединение нескольких X.509 сертификатов в один файл, чаще всего в формате PEM. Связка передается по сети в момент протокола рукопожатия SSL/TLS.

Самый сок начинается, когда имеете дело со связкой сертификатов, a. k. a certificate chain. Часто просматривая лапшу в связке ключей jks непросто понять как найти родительский сертификат, когда там россыпь новых и старых сертификатов на несколько доменных имен.

Регистрация в мобильном приложении

Чтобы войти в приложение, необходимо для начала пройти идентификацию через технологии Bank ID:

Процесс регистрации в мобильном приложении “Дія” занимает считанные минуты. На каждом этапе можно воспользоваться подробными подсказками, поэтому зарегистрироваться не составит особого труда.

Преобразование

Сертификаты, сгенерированные keytool и openssl, не могут идентифицировать друг друга. Keytool создает файл jsk, а openssl по умолчанию создает файл формата PEM. Сначала его необходимо преобразовать в формат pkcs12, а затем преобразовать в требуемый формат с помощью команд другой стороны.

Преобразуйте сертификат, созданный keytool, в формат PEM

~/tmp/cert# keytool -importkeystore -srcstoretype JKS -srckeystore ServerCert.jks -srcstorepass 123456 -srcalias server -srckeypass 123456 -deststoretype PKCS12 -destkeystore client.p12 -deststorepass 123456 -destalias client -destkeypass 123456 -noprompt
[email protected]:~/tmp/cert# ll
total 24
-rw-r--r-- 1 root root  664 Jun 14 20:43 cert.csr
-rw-r--r-- 1 root root 1708 Jun 14 21:01 client.p12
-rw-r--r-- 1 root root  963 Jun 14 20:27 private.pem
-rw-r--r-- 1 root root  871 Jun 14 20:44 public.crt
-rw-r--r-- 1 root root 1372 Jun 14 20:57 ServerCert.jks
-rw-r--r-- 1 root root 1682 Jun 14 20:55 server.p12

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

~/tmp/cert# openssl pkcs12 -in client.p12 -passin pass:$passwd -nokeys -out client.pem
MAC verified OK

Экспорт закрытого ключа:

~/tmp/cert# openssl pkcs12 -in client.p12 -passin pass:$passwd -nocerts -out client.crt
MAC verified OK
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
[email protected]:~/tmp/cert# ll
total 32
-rw-r--r-- 1 root root  664 Jun 14 20:43 cert.csr
-rw-r--r-- 1 root root 1184 Jun 14 21:10 client.crt
-rw-r--r-- 1 root root 1708 Jun 14 21:01 client.p12
-rw-r--r-- 1 root root 1127 Jun 14 21:07 client.pem
-rw-r--r-- 1 root root  963 Jun 14 20:27 private.pem
-rw-r--r-- 1 root root  871 Jun 14 20:44 public.crt
-rw-r--r-- 1 root root 1372 Jun 14 20:57 ServerCert.jks
-rw-r--r-- 1 root root 1682 Jun 14 20:55 server.p12

Преобразование сертификата формата PEM в файл jks

Преобразовать в формат pkcs12:

~/tmp/cert# openssl pkcs12 -export -in public.crt -inkey private.pem -out server.p12 -name server -passin pass:${passwd} -passout pass:${passwd}
~/tmp/cert# ll
total 16
-rw-r--r-- 1 root root  664 Jun 14 20:43 cert.csr
-rw-r--r-- 1 root root  963 Jun 14 20:27 private.pem
-rw-r--r-- 1 root root  871 Jun 14 20:44 public.crt
-rw-r--r-- 1 root root 1682 Jun 14 20:55 server.p12

Импортировать в jks:

~/tmp/cert# keytool -importkeystore -srckeystore server.p12 -srcstoretype PKCS12 -srcstorepass ${passwd} -alias server -deststorepass ${passwd} -destkeypass ${passwd} -destkeystore ServerCert.jks
~/tmp/cert# ll
total 20
-rw-r--r-- 1 root root  664 Jun 14 20:43 cert.csr
-rw-r--r-- 1 root root  963 Jun 14 20:27 private.pem
-rw-r--r-- 1 root root  871 Jun 14 20:44 public.crt
-rw-r--r-- 1 root root 1372 Jun 14 20:57 ServerCert.jks
-rw-r--r-- 1 root root 1682 Jun 14 20:55 server.p12