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

jarsigner - Подписание JAR и Инструмент Проверки

Генерирует подписи для Архива Java (JAR) файлы, и проверяет подписи подписанных файлов JAR.

РЕЗЮМЕ

jarsigner [ options ] jar-file alias
jarsigner -verify [ options ] jar-file [alias...]

jarsigner - проверяют, что команда может взять нуль или больше имен псевдонима keystore после имени файла фляги. Когда определено, jarsigner проверит, что сертификат, используемый, чтобы проверить каждую подписанную запись в файле фляги, соответствует один из псевдонимов keystore. Псевдонимы определяются в keystore, определенном-keystore, или значением по умолчанию keystore.

ОПИСАНИЕ

jarsigner инструмент используется в двух целях:

  1. подписать Архив Java (JAR) файлы, и
  2. проверять подписи и целостность подписанных файлов JAR.

Опция JAR позволяет упаковке файлов class, изображений, звуков, и других цифровых данных в единственном файле для более быстрого и более легкого распределения. Инструмент, названный флягой, позволяет разработчикам произвести файлы JAR. (Технически, любой файл zip можно также считать файлом JAR, хотя когда создающийся флягой или обработал jarsigner, файлы JAR также содержат файл META-INF/MANIFEST.MF.)

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

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

jarsigner использует ключ и информацию о сертификате от keystore, чтобы генерировать цифровые подписи для файлов JAR. keystore является базой данных закрытых ключей и их связанных цепочек сертификата X.509, аутентифицирующих соответствующие открытые ключи. keytool утилита используется, чтобы создать и администрировать keystores.

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

jarsigner может генерировать подписи, которые включают метку времени, таким образом включая systems/deployer (включая Плагин Java), чтобы проверить, был ли файл JAR подписан, в то время как сертификат подписания был все еще допустим. Кроме того, API позволят приложениям получать информацию о метке времени.

В это время jarsigner может только подписать файлы JAR, создаваемые инструментом фляги SDK, или архивировать файлы. (Файлы JAR являются тем же самым как файлами zip, кроме у них также есть файл META-INF/MANIFEST.MF. Такой файл будет автоматически создаваться, когда jarsigner подпишет файл zip.)

Значение по умолчанию jarsigner поведение должно подписать JAR (или zip) файл. Используйте -verify опция, чтобы вместо этого иметь это проверяет подписанный файл JAR.

Псевдонимы Keystore

Ко всем keystore объектам получают доступ через уникальные псевдонимы.

При использовании jarsigner, чтобы подписать файл JAR, следует определить, что псевдоним для keystore записи, содержащей закрытый ключ, должен был генерировать подпись. Например, следующее подпишет файл JAR по имени "MyJARFile.jar", используя закрытый ключ, связанный с псевдонимом "герцог" в keystore, названном "mystore" в "рабочем" каталоге. Так как никакой выходной файл не определяется, это перезаписывает MyJARFile.jar с подписанным файлом JAR.

    jarsigner -keystore /working/mystore -storepass <keystore password>
      -keypass <private key password> MyJARFile.jar duke

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

Расположение Keystore

у jarsigner есть a -keystore опция для того, чтобы определить URL keystore, который будет использоваться. keystore по умолчанию сохранен в названном файле .keystore в корневом каталоге пользователя, как определено user.home системное свойство. На системах Соляриса user.home значения по умолчанию к корневому каталогу пользователя.

Отметьте что входной поток в -keystore опцию передают к KeyStore.load метод. Если NONE определяется как URL, затем нулевой поток передают к KeyStore.load метод. NONE должен быть определен если KeyStore не основано на файле, например, если это находится на аппаратном маркерном устройстве.

Реализация Keystore

KeyStore class, обеспеченный в java.security пакет предоставляет четко определенные интерфейсы, чтобы получить доступ и изменить информацию в keystore. Для там возможно быть многократными различными конкретными реализациями, где каждая реализация состоит в том что для определенного типа keystore.

В настоящий момент есть два инструмента командной строки, которые используют keystore реализации (keytool и jarsigner), и также основанный на GUI инструмент под названием Средство осуществления политики. С тех пор KeyStore публично доступно, Java, который 2 пользователя SDK могут записать дополнительным приложениям безопасности, которые используют его.

Есть встроенная реализация по умолчанию, обеспеченная Sun Microsystems. Это реализует keystore как файл, используя собственный тип keystore (формат) под названием "JKS". Это защищает каждый закрытый ключ со своим отдельным паролем, и также защищает целостность всего keystore с (возможно отличающийся) пароль.

Реализации Keystore основаны на провайдере. Более определенно, интерфейсы приложения, предоставленные KeyStore реализуются с точки зрения "Интерфейса Поставщика услуг" (SPI). Таким образом, есть соответствующий краткий обзор KeystoreSpi class, также в java.security пакет, который определяет методы Service Provider Interface, которые должны реализовать "провайдеры". (Термин "провайдер" относится к пакету или ряду пакетов, которые предоставляют конкретную реализацию подмножества служб, к которым может получить доступ API Безопасности Java.) Таким образом, чтобы обеспечить keystore реализацию, клиенты должны реализовать провайдера и предоставить реализацию подкласса KeystoreSpi, как описано в том, Как Реализовать Провайдера для Архитектуры Криптографии Java.

Приложения могут выбрать различные типы keystore реализаций от различных провайдеров, используя "getInstance" метод фабрики, предоставленный в KeyStore class. Тип keystore определяет хранение и формат данных keystore информации, и алгоритмы, используемые, чтобы защитить закрытые ключи в keystore и целостности keystore непосредственно. Реализации Keystore различных типов не являются совместимыми.

keytool работает над любой основанной на файле keystore реализацией. (Это обрабатывает keystore расположение, которое передают к этому в командной строке как имя файла и преобразовывает это в FileInputStream, из которого это загружает keystore информацию.) jarsigner и policytool инструменты, с другой стороны, могут считать keystore из любого расположения, которое может быть определено, используя URL.

Для jarsigner и keytool, можно определить тип keystore в командной строке через-storetype опцию. Для Средства осуществления политики можно определить тип keystore через команду "Change Keystore" в меню Edit.

Если Вы явно не определяете тип keystore, инструменты выбирают keystore реализацию, базируемую просто на значении keystore.type свойство определяется в файле свойств безопасности. Файл свойств безопасности вызывают java.security, и это находится в каталоге свойств безопасности SDK, java.home/lib/security, где java.home является каталогом среды выполнения (каталог jre в SDK или высокоуровневый каталог Java 2 Среды выполнения).

Каждый инструмент добирается keystore.type оцените и затем исследуйте всех установленных в настоящий момент провайдеров, пока это не находит тот, который реализует keystores того типа. Это тогда использует keystore реализацию от того провайдера.

KeyStore class определяет статический названный метод getDefaultType это позволяет приложениям, и апплеты получают значение keystore.type свойство. Следующая строка кода создает экземпляр значения по умолчанию keystore тип (как определено в keystore.type свойство):

    KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());

Значение по умолчанию keystore тип является "jks" (собственный тип keystore реализации, обеспеченной Sun). Это определяется следующей строкой в файле свойств безопасности:

    keystore.type=jks

Отметьте: Случай не имеет значения в обозначениях типа keystore. Например, "JKS" считали бы тем же самым как "jks".

Чтобы иметь инструменты используют keystore реализацию кроме значения по умолчанию, изменение, которое вводит строка, чтобы определить различный keystore. Например, если у Вас есть пакет провайдера, который предоставляет keystore реализацию для типа keystore, названного "pkcs12", измените строку на

    keystore.type=pkcs12

Отметьте это, если Вы нас PKCS#11 пакет провайдера, следует обратиться к разделу KeyTool и JarSigner Java PKCS#11 Справочник для деталей.

Поддерживаемые Алгоритмы

По умолчанию jarsigner подписывает файл JAR, используя одно из следующего:

Таким образом, если открытые и закрытые ключи подписывающего лица будут ключами DSA, то jarsigner подпишет файл JAR, используя алгоритм "SHA1withDSA". Если ключи подписывающего лица будут ключами RSA, то jarsigner попытается подписать файл JAR, используя алгоритм "SHA256withRSA". Если ключи подписывающего лица будут ключами EC, то jarsigner подпишет файл JAR, используя алгоритм "SHA256withECDSA".

Эти алгоритмы подписи значения по умолчанию могут быть переопределены, используя-sigalg опцию.

Подписанный Файл JAR

Когда jarsigner используется, чтобы подписать файл JAR, вывод, подписанный файл JAR является точно тем же самым как входным файлом JAR, за исключением того, что у этого есть два дополнительных файла, помещенные в каталог META-INF:

Основные имена файлов для этих двух файлов, прибывших от значения -sigFile опция. Например, если опция появляется как

-sigFile MKSIGN

Файлы называют "MKSIGN.SF" и "MKSIGN.DSA".

Если нет -sigfile опция появляется на командной строке, основное имя файла для.SF и.DSA файлов будет первыми 8 символами имени псевдонима, определенного на командной строке, все преобразованные в верхний регистр. Если у имени псевдонима есть меньше чем 8 символов, полное имя псевдонима используется. Если имя псевдонима содержит какие-либо символы, которые не позволяются в имени файла подписи, каждый такой символ преобразовывается в подчеркивание (" _ ") символ в формировании имени файла. Юридические символы включают буквы, цифры, подчеркивания, и дефисы.

Подпись (.SF) Файл

Файл подписи (.SF файл) выглядит подобным файлу манифеста, который всегда включается в файл JAR, когда jarsigner используется, чтобы подписать файл. Таким образом, для каждого исходного файла, включенного в файл JAR, у.SF файла есть три строки, так же, как в файле манифеста, перечисляя следующее:

В файле манифеста значение обзора SHA для каждого исходного файла является обзором (хеш) двоичных данных в исходном файле. В.SF файле, с другой стороны, значение обзора для данного исходного файла является хешем этих трех строк в файле манифеста для исходного файла.

Файл подписи также, по умолчанию, включает заголовок, содержащий хеш целого файла манифеста. Присутствие заголовка включает оптимизации проверки, как описано в Проверке Файла JAR.

Файл Сигнатурного блока

.SF файл подписывается, и подпись помещается в файл сигнатурного блока. Этот файл также содержит, закодированный в этом, сертификат или цепочка сертификата от keystore, который аутентифицирует открытый ключ, соответствующий закрытому ключу, используемому для того, чтобы подписаться. У файла есть расширение.DSA.RSA, или.EC в зависимости от используемого алгоритма обзора.

Метка времени подписи

jarsigner инструмент может генерировать и сохранить метку времени подписи, подписывая файл JAR. Кроме того, jarsigner поддерживает альтернативные механизмы подписания. Это поведение является дополнительным и управляется пользователем во время подписания через эти опции:

Каждая из этих опций детализируется в разделе Опций ниже.

Проверка Файла JAR

Успешная проверка файла JAR происходит, если подпись (и) допустима, и ни один из файлов, которые были в файле JAR, когда подписи были сгенерированы, были изменены с тех пор. Проверка файла JAR включает следующие шаги:

  1. Проверьте подпись.SF файла непосредственно.

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

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

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

    Если это не так менее оптимизированная проверка обязана гарантировать, что хеш в каждом разделе информации об исходном файле в.SF файле равняется хешу своего соответствующего раздела в файле манифеста (см. Подпись (.SF) Файл).

    Одна причина хеш файла манифеста, который сохранен в.SF заголовке файла, возможно, не равняется хешу текущего файла манифеста, состояла бы в том, потому что один или более файлов были добавлены к файлу JAR (использующий jar инструмент) после того, как подпись (и таким образом.SF файл) была сгенерирована. Когда jar инструмент используется, чтобы добавить файлы, файл манифеста изменяется (разделы добавляются к этому для новых файлов), но.SF файл не. Проверку все еще считают успешной, если ни один из файлов, которые были в файле JAR, когда подпись была сгенерирована, не был изменен с тех пор, который имеет место, равняются ли хеши в разделах незаголовка.SF файла хешам соответствующих разделов в файле манифеста.

  3. Считайте каждый файл в файле JAR, у которого есть запись в.SF файле. Читая, вычислите обзор файла, и затем сравните результат с обзором для этого файла в явном разделе. Обзоры должны быть тем же самым, или сбоями проверки.

Если какие-либо серьезные отказы проверки происходят во время процесса проверки, процесс останавливается, и исключение безопасности выдается. Это поймано и выведено на экран jarsigner.

Многократные Подписи для Файла JAR

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

  jarsigner myBundle.jar susan
  jarsigner myBundle.jar kevin

Когда файл JAR подписывается многократно, есть многократный.SF и.DSA файлы в получающемся файле JAR, одной паре для каждой подписи. Таким образом, в примере выше, выходной файл JAR включает файлы со следующими именами:

  SUSAN.SF
  SUSAN.DSA
  KEVIN.SF
  KEVIN.DSA

Отметьте: Для файла JAR также возможно смешать подписи, некоторые сгенерированные JDK 1.1 javakey инструмента и другие jarsigner. Таким образом, jarsigner может использоваться, чтобы подписаться, файлы JAR уже ранее подписали использование javakey.

ОПЦИИ

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

-keystore url
Определяет URL, который говорит keystore расположение. Это принимает значение по умолчанию к файлу.keystore в корневом каталоге пользователя, как определено "user.home" системным свойством.

keystore требуется, подписываясь, таким образом, следует явно определить тот, если значение по умолчанию keystore не существует (или Вы хотите использовать один кроме значения по умолчанию).

keystore не требуется, проверяя, но если Вы определяетесь, или значение по умолчанию существует, и -verbose опция была также определена, дополнительная информация выводится относительно того, содержится ли какой-либо из сертификатов, используемых, чтобы проверить файл JAR, в этом keystore.

Отметьте: -keystore параметром может фактически быть имя файла (и путь) спецификация, а не URL, когда это будет обработано то же самое как "файл:" URL. Таким образом,

  -keystore filePathAndName

обрабатывается как эквивалентный

  -keystore file:filePathAndName

Если Sun PKCS#11 провайдер был сконфигурирован в файле свойств безопасности java.security (расположенный в каталоге $JAVA_HOME/lib/security JRE), то keytool и jarsigner могут работать на PKCS#11 маркер, определяя эти опции:

Например, это списки команд содержание сконфигурированного PKCS#11 маркер:

   jarsigner -keystore NONE -storetype PKCS11 -list
-storetype storetype
Определяет тип keystore, который инстанцируют. Значение по умолчанию keystore тип является тем, которое определяется как значение "keystore.type" свойства в файле свойств безопасности, который возвращается помехами getDefaultType метод в java.security.KeyStore.

ПИН для PCKS#11 маркер может также быть определен, используя -storepass опция. Если ни один не был определен, keytool, и jarsigner запросит маркерный ПИН. Если у маркера есть защищенный путь аутентификации (такой как выделенная клавиатура ПИН или биометрический читатель), то опция -protected должна быть определена, и никакие опции пароля не могут быть определены.

-storepass[:env | :file] параметр

Определяет пароль, который обязан получать доступ к keystore. Это только необходимо, подписываясь (не проверяющий) файл JAR. В этом случае, если a -storepass возможность не предоставляется в командной строке, пользователь запрашивается пароль.

Если модификатор env или file не определяется, тогда у пароля есть параметр значения. Иначе, пароль получается следующим образом:

Отметьте: пароль не должен быть определен на командной строке или в сценарии, если это не для тестирования, или Вы находитесь на защищенной системе.

-keypass[:env | :file] параметр

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

Если модификатор env или file не определяется, тогда у пароля есть параметр значения. Иначе, пароль получается следующим образом:

Отметьте: пароль не должен быть определен на командной строке или в сценарии, если это не для тестирования, или Вы находитесь на защищенной системе.

-sigfile файл
Определяет основное имя файла, которое будет использоваться для сгенерированного.SF и.DSA файлов. Например, если файл будет "DUKESIGN", то сгенерированный.SF и.DSA файлы назовут "DUKESIGN.SF" и "DUKESIGN.DSA", и будут помещены в каталог "META-INF" подписанного файла JAR.

Символы в файле должны прибыть из набора "a-zA-Z0-9_-". Таким образом, только обозначает буквами, числа, подчеркивание, и символы дефиса позволяются. Отметьте: Все символы нижнего регистра будут преобразованы в верхний регистр для.SF и.DSA имен файлов.

Если нет -sigfile опция появляется на командной строке, основное имя файла для.SF и.DSA файлов будет первыми 8 символами имени псевдонима, определенного на командной строке, все преобразованные в верхний регистр. Если у имени псевдонима есть меньше чем 8 символов, полное имя псевдонима используется. Если имя псевдонима содержит какие-либо символы, которые не являются законными в имени файла подписи, каждый такой символ преобразовывается в подчеркивание (" _ ") символ в формировании имени файла.

-sigalg алгоритм
Определяет имя алгоритма подписи, чтобы использовать, чтобы подписать файл JAR.

См. Приложение A Архитектуры Криптографии Java для списка стандартных имен алгоритма подписи. Этот алгоритм должен быть совместимым с закрытым ключом, используемым, чтобы подписать файл JAR. Если эта опция не определяется, SHA1withDSA, SHA256withRSA, или SHA256withECDSA будет использоваться в зависимости от типа закрытого ключа. Должен или быть статически установленный провайдер, предоставляющий реализацию указанного алгоритма или пользователя, должен определить один с-providerClass опцией, иначе команда не будет успешно выполняться.

-digestalg алгоритм
Определяет имя алгоритма обзора сообщения, чтобы использовать, переваривая записи файла фляги.

См. Приложение A Архитектуры Криптографии Java для списка стандартных имен алгоритма обзора сообщения. Если эта опция не будет определена, то SHA256 будет использоваться. Должен или быть статически установленный провайдер, предоставляющий реализацию указанного алгоритма или пользователя, должен определить один с-providerClass опцией, иначе команда не будет успешно выполняться.

-signedjar файл
Определяет имя, которое будет использоваться для подписанного файла JAR.

Если никакое имя не определяется на командной строке, используемое имя является тем же самым как входным именем файла JAR (имя файла JAR, который будет подписан); другими словами тот файл перезаписывается с подписанным файлом JAR.

-verify
Если это появится на командной строке, то указанный файл JAR будет проверен, не подписан. Если проверка будет успешна, то "фляга, проверенная", будет выведена на экран. Если Вы пытаетесь проверить файл JAR без знака, или файл JAR, подписанный с неподдерживаемым алгоритмом (например, RSA, когда Вам не устанавливали провайдера RSA), следующее, выводится на экран: "фляга без знака. (без вести пропавшие подписей или не parsable)"

Возможно проверить, что файлы JAR подписали использование или jarsigner или JDK 1.1 javakey инструмента, или оба.

Для дополнительной информации о проверке см. Проверку Файла JAR.

-certs
Если это появляется на командной строке, наряду с -verify и -verbose опции, вывод включает информацию о сертификате для каждого подписывающего лица файла JAR. Эта информация включает

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

-certchain файл
Определяет цепочку сертификата, которая будет использоваться, если цепочка сертификата, связанная с закрытым ключом keystore записи, адресуемой псевдонимом, определенным на командной строке, не полна. Это может произойти, если keystore располагается на аппаратном маркере, где есть недостаточная емкость содержать полную цепочку сертификата. Файл может быть последовательностью сертификатов X.509, связанных вместе, или сингл PKCS#7 отформатированный блок данных, или в двоичном формате кодирования или в печатаемом формате кодирования (также известный как кодирование BASE64) как определено интернет-стандартом RFC 1421.
-verbose
Если это появляется на командной строке, она указывает "на многословный" режим, который заставляет jarsigner выводить дополнительную информацию относительно продвижения подписания JAR или проверки.
-internalsf
В прошлом.DSA (сигнатурный блок) файл, сгенерированный, когда файл JAR был подписан используемый, чтобы включать полную закодированную копию.SF файла (файл подписи) также сгенерированный. Это поведение было изменено. Чтобы уменьшить полный размер выходного файла JAR.DSA файл по умолчанию не содержит копию.SF файла больше. Но если -internalsf появляется на командной строке, старое поведение используется. Эта опция главным образом полезна для тестирования; практически, это не должно использоваться, начиная с выполнения так устраняет полезную оптимизацию.
-sectionsonly
Если это кажется на командной строке.SF файл (файл подписи) сгенерированным, когда файл JAR подписывается, не включает заголовок, содержащий хеш целого файла манифеста. Это только содержит информацию и хеширует связанный с каждым отдельным исходным файлом, включенным в файл JAR, как описано в Подписи (.SF) Файл.

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

Для дополнительной информации см. Проверку Файла JAR.

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

-protected
Также true или false. Это значение должно быть определено как true если пароль должен быть дан через защищенный путь аутентификации, такой как выделенный читатель ПИН.
-providerClass provider-class-name
Используемый, чтобы определить имя основного файла class провайдера криптографических служб, когда поставщик услуг не перечисляется в файле свойств безопасности, java.security.

Используемый в соединении с -providerArg Опция ConfigFilePath, keytool и jarsigner установят провайдера динамически (где ConfigFilePath является путем к маркерному конфигурационному файлу). Вот пример команды, чтобы перечислить PKCS#11 keystore, когда Sun PKCS#11 провайдер не был сконфигурирован в файле свойств безопасности.

jarsigner -keystore NONE -storetype PKCS11 \
          -providerClass sun.security.pkcs11.SunPKCS11 \
          -providerArg /foo/bar/token.config \
          -list
-providerName providerName
Если больше чем один провайдер был сконфигурирован в файле свойств безопасности java.security, можно использовать опцию -providerName, чтобы предназначаться для определенного экземпляра провайдера. Параметром этой опции является имя провайдера.

Для Sun PKCS#11 провайдер, providerName имеет форму SunPKCS11-TokenName, где TokenName является суффиксом имени, что экземпляр провайдера был сконфигурирован с, как детализировано в таблице атрибутов конфигурации. Например, следующие списки команд содержание PKCS#11 keystore экземпляр провайдера с именем снабжают суффиксом SmartCard:

jarsigner -keystore NONE -storetype PKCS11 \
        -providerName SunPKCS11-SmartCard \
        -list
-Jjavaoption
Проходит через указанную строку javaoption непосредственно к интерпретатору Java. (jarsigner фактически "обертка" вокруг интерпретатора.) Эта опция не должна содержать пробелы. Это полезно для корректировки использования памяти или среды выполнения. Для списка возможных опций интерпретатора ввести java -h или java -X в командной строке.

-tsa url
Если "-tsa http://example.tsa.url" появляется на командной строке, подписывая файл JAR тогда, метка времени сгенерирована для подписи. URL, http://example.tsa.url, идентифицирует расположение Властей Добавления метки времени (TSA). Это переопределяет любой URL, найденный через -tsacert опция. -tsa опция не требует, чтобы сертификат TSA с открытым ключом присутствовал в keystore.

Генерировать метку времени, jarsigner связывается с TSA, используя Протокол Метки времени (TSP), определенный в RFC 3161. В случае успеха маркер метки времени, возвращенный TSA, сохранен наряду с подписью в файле сигнатурного блока.

-tsacert псевдоним
Если "-tsacert alias" появляется на командной строке, подписывая файл JAR тогда, метка времени сгенерирована для подписи. alias идентифицирует сертификат TSA с открытым ключом в keystore, который является в настоящий момент в действительности. Сертификат записи исследуется на Подчиненное информационное расширение Доступа, которое содержит URL, идентифицирующий расположение TSA.

Сертификат TSA с открытым ключом должен присутствовать в keystore при использовании -tsacert.

-altsigner class
Определяет, что используется альтернативный механизм подписания. Полностью определенное имя class идентифицирует файл class, который расширяется com.sun.jarsigner.ContentSigner abstract class. Путь к этому файлу class определяется -altsignerpath опция. Если -altsigner опция используется, jarsigner использует механизм подписания, обеспеченный указанным class. Иначе, jarsigner использует его механизм подписания значения по умолчанию.

Например, чтобы использовать механизм подписания, обеспеченный названным class com.sun.sun.jarsigner.AuthSigner, используйте jarsigner опция "-altsigner com.sun.jarsigner.AuthSigner"

-altsignerpath classpathlist
Определяет путь к файлу class (имя файла class определяется с -altsigner опция, описанная выше), и любые файлы JAR это зависит от. Если файл class находится в файле JAR, то это определяет путь к тому файлу JAR, как показано в примере ниже.

Абсолютный путь или путь относительно текущего каталога могут быть определены. Если classpathlist содержит разнообразные пути или файлы JAR, они должны быть разделены двоеточием (:) на Солярисе и точке с запятой (;) на Windows. Эта опция не необходима, если class уже находится в пути поиска.

Пример определения пути к файлу фляги, который содержит файл class:

-altsignerpath /home/user/lib/authsigner.jar

Отметьте, что имя файла JAR включается.

Пример определения пути к файлу фляги, который содержит файл class:

-altsignerpath /home/user/classes/com/sun/tools/jarsigner/

Отметьте, что имя файла JAR опускается.

-strict
Во время подписания или проверки процесса, можно показать некоторые предупреждающие сообщения. Если эта опция появится на командной строке, то код выхода инструмента отразит предупреждающие сообщения, которые находятся. Считайте раздел "ПРЕДУПРЕЖДЕНИЙ" для деталей.
-verbose:sub-опции
Для процесса проверки, -verbose опция берет подопции, чтобы определить, сколько информации покажут. Если -certs также определяется, режим по умолчанию (или подопция все) выводит на экран каждую запись, поскольку это обрабатывается и после этого, информации о сертификате для каждого подписывающего лица файла JAR. Если -certs и -verbose:grouped подопция определяется, записи с той же самой информацией подписывающего лица группируются и выводятся на экран вместе наряду с их информацией о сертификате. Если -certs и -verbose:summary подопция определяется, тогда записи с той же самой информацией подписывающего лица группируются и выводятся на экран вместе наряду с их информацией о сертификате, но детали о каждой записи получаются в итоге и выводятся на экран как "одна запись (и больше)". См. раздел в качестве примера для получения дополнительной информации.

ПРИМЕРЫ

Подписание Файла JAR

Предположите, что у Вас есть файл JAR, названный "bundle.jar", и требуется подписать его использующий закрытый ключ пользователя, псевдоним keystore которого является "jane" в keystore, названном "mystore" в "рабочем" каталоге. Можно использовать следующий, чтобы подписать файл JAR и назвать подписанный файл JAR "sbundle.jar":

    jarsigner -keystore /working/mystore -storepass <keystore password>
      -keypass <private key password> -signedjar sbundle.jar bundle.jar jane

Отметьте, что есть нет -sigfile определенный в команде выше, таким образом, у сгенерированного.SF и.DSA файлов, которые будут помещены в подписанный файл JAR, будут имена по умолчанию основанными на имени псевдонима. Таким образом, их назовут JANE.SF и JANE.DSA.

Если Вы хотите быть запрошенными пароль хранилища и пароль с закрытым ключом, Вы могли сократить вышеупомянутую команду к

    jarsigner -keystore /working/mystore
      -signedjar sbundle.jar bundle.jar jane

Если keystore, который будет использоваться, является значением по умолчанию keystore (тот, названный ".keystore" в Вашем корневом каталоге), Вы не должны определить keystore, как в:

    jarsigner -signedjar sbundle.jar bundle.jar jane

Наконец, если Вы хотите, чтобы подписанный файл JAR просто перезаписал входной файл JAR (bundle.jar), Вы не должны определить a -signedjar опция:

    jarsigner bundle.jar jane

Проверка Подписанного Файла JAR

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

    jarsigner -verify sbundle.jar

Если проверка успешна,

    jar verified.

выводится на экран. Иначе, сообщение об ошибке появляется.

Можно получить больше информации, если Вы используете -verbose опция. Демонстрационное использование jarsigner с -verbose вариант показывается ниже, наряду с демонстрационным выводом:

    jarsigner -verify -verbose sbundle.jar

           198 Fri Sep 26 16:14:06 PDT 1997 META-INF/MANIFEST.MF
           199 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.SF
          1013 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.DSA
    smk   2752 Fri Sep 26 16:12:30 PDT 1997 AclEx.class
    smk    849 Fri Sep 26 16:12:46 PDT 1997 test.class

      s = signature was verified
      m = entry is listed in manifest
      k = at least one certificate was found in keystore

    jar verified.

Проверка с информацией о Сертификате

Если Вы определяете -certs опция, проверяя, наряду с -verify и -verbose опции, вывод включает информацию о сертификате для каждого подписывающего лица файла JAR, включая тип сертификата, информация об отличительном имени подписывающего лица (если и только если это - сертификат X.509), и, в круглых скобках, псевдониме keystore для подписывающего лица, если сертификат с открытым ключом в соответствиях файла JAR это в keystore записи. Например,

    jarsigner -keystore /working/mystore -verify -verbose -certs myTest.jar

           198 Fri Sep 26 16:14:06 PDT 1997 META-INF/MANIFEST.MF
           199 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.SF
          1013 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.DSA
           208 Fri Sep 26 16:23:30 PDT 1997 META-INF/JAVATEST.SF
          1087 Fri Sep 26 16:23:30 PDT 1997 META-INF/JAVATEST.DSA
    smk   2752 Fri Sep 26 16:12:30 PDT 1997 Tst.class

      X.509, CN=Test Group, OU=Java Software, O=Sun Microsystems, L=CUP, S=CA, C=US (javatest)
      X.509, CN=Jane Smith, OU=Java Software, O=Sun, L=cup, S=ca, C=us (jane)

      s = signature was verified
      m = entry is listed in manifest
      k = at least one certificate was found in keystore

    jar verified.

Если сертификат для подписывающего лица не является сертификатом X.509, нет никакой информации об отличительном имени. В этом случае только тип сертификата и псевдоним показывают. Например, если бы сертификат является сертификатом PGP, и псевдонимом является "Боб", Вы добрались бы

      PGP, (bob)

Проверка Файла JAR, который Включает Подписывающие лица Базы данных Идентификационных данных

Если файл JAR был подписан, используя JDK 1.1 javakey инструмента, и таким образом подписывающее лицо является псевдонимом в базе данных идентификационных данных, вывод проверки включает "i" символ. Если файл JAR был подписан и псевдонимом в базе данных идентификационных данных и псевдонимом в keystore, и "k" и "i" появляются.

Когда -certs опция используется, любые псевдонимы базы данных идентификационных данных показывают в квадратных скобках, а не круглых скобках, используемых для псевдонимов keystore. Например:

    jarsigner -keystore /working/mystore -verify -verbose -certs writeFile.jar

           198 Fri Sep 26 16:14:06 PDT 1997 META-INF/MANIFEST.MF
           199 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.SF
          1013 Fri Sep 26 16:22:10 PDT 1997 META-INF/JANE.DSA
           199 Fri Sep 27 12:22:30 PDT 1997 META-INF/DUKE.SF
          1013 Fri Sep 27 12:22:30 PDT 1997 META-INF/DUKE.DSA
   smki   2752 Fri Sep 26 16:12:30 PDT 1997 writeFile.html

      X.509, CN=Jane Smith, OU=Java Software, O=Sun, L=cup, S=ca, C=us (jane)
      X.509, CN=Duke, OU=Java Software, O=Sun, L=cup, S=ca, C=us [duke]

      s = signature was verified
      m = entry is listed in manifest
      k = at least one certificate was found in keystore
      i = at least one certificate was found in identity scope

    jar verified.

Отметьте, что псевдоним "герцог" в скобках, чтобы обозначить, что это - псевдоним базы данных идентификационных данных, не псевдоним keystore.

ПРЕДУПРЕЖДЕНИЯ

Во время процесса подписания/проверки jarsigner может вывести на экран различные предупреждения. Эти коды предупреждения определяются следующим образом: 
         hasExpiringCert         2
             This jar contains entries whose signer certificate will expire within six months

         hasExpiredCert          4
             This jar contains entries whose signer certificate has expired.

         notYetValidCert         4
             This jar contains entries whose signer certificate is not yet valid.

         chainNotValidated       4
             This jar contains entries whose certificate chain cannot be correctly validated.

         badKeyUsage             8
             This jar contains entries whose signer certificate's KeyUsage extension doesn't allow code signing.

         badExtendedKeyUsage     8
             This jar contains entries whose signer certificate's ExtendedKeyUsage extension
             doesn't allow code signing.

         badNetscapeCertType     8
             This jar contains entries whose signer certificate's NetscapeCertType extension
             doesn't allow code signing.

         hasUnsignedEntry        16
             This jar contains unsigned entries which have not been integrity-checked.

         notSignedByAlias        32
             This jar contains signed entries which are not signed by the specified alias(es)

         aliasNotInStore         32
             This jar contains signed entries that are not signed by alias in this keystore

Когда -strict возможность предоставляется, ИЛИ-ЗНАЧЕНИЕ обнаруженных предупреждений будет возвращено как код выхода инструмента. Например, если сертификат, используемый, чтобы подписать запись, истечется и будет иметь keyUsage расширение, которое не позволяет ему подписывать файл, то код выхода 12 (=4+8) будет возвращен.

Отметьте: Коды выхода снова используются, потому что только 0-255 законные для Unix. В любом случае, если процесс подписания/проверки перестанет работать, то следующий код выхода будет возвращен:

failure                 1

Совместимость с JDK 1.1

keytool и jarsigner инструменты полностью заменяют javakey инструмент, обеспеченный в JDK 1.1. Эти новые инструменты обеспечивают больше функций чем javakey, включая возможность защитить keystore и закрытые ключи с паролями, и возможность проверить подписи в дополнение к генерированию их.

Новая keystore архитектура заменяет базу данных идентификационных данных что javakey, создаваемый и управляемый. Есть не назад совместимость между форматом keystore и форматом базы данных, используемым javakey в 1.1. Однако,

Следующая таблица объясняет, как файлы JAR, которые были подписаны в JDK 1.1.x, обрабатываются в Java 2 платформы.

Тип файла JAR Идентификационные данные в 1.1 базах данных Доверяемые Идентификационные данные, импортированные в Java 2 Платформы keystore от 1.1 баз данных (4) Файл политики предоставляет полномочия Идентификационным данным/Псевдониму Предоставленные полномочия

Подписанный JAR

НЕТ

НЕТ

НЕТ

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

JAR без знака

НЕТ

НЕТ

НЕТ

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

Подписанный JAR

НЕТ

ДА

НЕТ

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

Подписанный JAR

YES/Untrusted

НЕТ

НЕТ

Полномочия значения по умолчанию, предоставленные всему коду. (3)

Подписанный JAR

YES/Untrusted

НЕТ

ДА

Полномочия значения по умолчанию, предоставленные всему коду. (1,3)

Подписанный JAR

НЕТ

ДА

ДА

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

Подписанный JAR

ДА/ДОВЕРЯЕМЫЙ

ДА

ДА

Полномочия значения по умолчанию, предоставленные всему коду плюс полномочия, предоставляются в файле политики. (2)

Подписанный JAR

ДА/ДОВЕРЯЕМЫЙ

НЕТ

НЕТ

Все полномочия

Подписанный JAR

ДА/ДОВЕРЯЕМЫЙ

ДА

НЕТ

Все полномочия (1)

Подписанный JAR

ДА/ДОВЕРЯЕМЫЙ

НЕТ

ДА

Все полномочия (1)

Примечания:

  1. Если идентификационные данные/псевдоним упоминаются в файле политики, они должны быть импортированы в keystore для файла политики, чтобы иметь любой эффект на предоставленные полномочия.
  2. У политики file/keystore комбинация есть приоритет по доверяемым идентификационным данным в базе данных идентификационных данных.
  3. Недоверяемые идентификационные данные игнорируются в Java 2 платформы.
  4. Только доверяемые идентификационные данные могут быть импортированы в Java 2 SDK keystores.

СМ. ТАКЖЕ

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