Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
Генерирует подписи для Архива Java (JAR) файлы, и проверяет подписи подписанных файлов JAR.
jarsigner [ options ] jar-file alias jarsigner -verify [ options ] jar-file [alias...]
jarsigner - проверяют, что команда может взять нуль или больше имен псевдонима keystore после имени файла фляги. Когда определено, jarsigner проверит, что сертификат, используемый, чтобы проверить каждую подписанную запись в файле фляги, соответствует один из псевдонимов keystore. Псевдонимы определяются в keystore, определенном-keystore, или значением по умолчанию keystore.
jarsigner инструмент используется в двух целях:
Опция 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 объектам получают доступ через уникальные псевдонимы.
При использовании 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 с паролем, таким образом, пароль закрытого ключа должен быть определен, и Вы будете запрошены это, если Вы не определите это на командной строке, и это не то же самое как пароль хранилища.
у jarsigner есть a -keystore опция для того, чтобы определить URL keystore, который будет использоваться. keystore по умолчанию сохранен в названном файле .keystore в корневом каталоге пользователя, как определено user.home системное свойство. На системах Соляриса user.home значения по умолчанию к корневому каталогу пользователя.
Отметьте что входной поток в -keystore опцию передают к KeyStore.load метод. Если NONE определяется как URL, затем нулевой поток передают к KeyStore.load метод. NONE должен быть определен если 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 опцию.
Когда jarsigner используется, чтобы подписать файл JAR, вывод, подписанный файл JAR является точно тем же самым как входным файлом JAR, за исключением того, что у этого есть два дополнительных файла, помещенные в каталог META-INF:
Основные имена файлов для этих двух файлов, прибывших от значения -sigFile опция. Например, если опция появляется как
-sigFile MKSIGN
Файлы называют "MKSIGN.SF" и "MKSIGN.DSA".
Если нет -sigfile опция появляется на командной строке, основное имя файла для.SF и.DSA файлов будет первыми 8 символами имени псевдонима, определенного на командной строке, все преобразованные в верхний регистр. Если у имени псевдонима есть меньше чем 8 символов, полное имя псевдонима используется. Если имя псевдонима содержит какие-либо символы, которые не позволяются в имени файла подписи, каждый такой символ преобразовывается в подчеркивание (" _ ") символ в формировании имени файла. Юридические символы включают буквы, цифры, подчеркивания, и дефисы.
Файл подписи (.SF файл) выглядит подобным файлу манифеста, который всегда включается в файл JAR, когда jarsigner используется, чтобы подписать файл. Таким образом, для каждого исходного файла, включенного в файл JAR, у.SF файла есть три строки, так же, как в файле манифеста, перечисляя следующее:
В файле манифеста значение обзора SHA для каждого исходного файла является обзором (хеш) двоичных данных в исходном файле. В.SF файле, с другой стороны, значение обзора для данного исходного файла является хешем этих трех строк в файле манифеста для исходного файла.
Файл подписи также, по умолчанию, включает заголовок, содержащий хеш целого файла манифеста. Присутствие заголовка включает оптимизации проверки, как описано в Проверке Файла JAR.
jarsigner инструмент может генерировать и сохранить метку времени подписи, подписывая файл JAR. Кроме того, jarsigner поддерживает альтернативные механизмы подписания. Это поведение является дополнительным и управляется пользователем во время подписания через эти опции:
Каждая из этих опций детализируется в разделе Опций ниже.
Успешная проверка файла JAR происходит, если подпись (и) допустима, и ни один из файлов, которые были в файле JAR, когда подписи были сгенерированы, были изменены с тех пор. Проверка файла JAR включает следующие шаги:
jar инструмент) после того, как подпись (и таким образом.SF файл) была сгенерирована. Когда jar инструмент используется, чтобы добавить файлы, файл манифеста изменяется (разделы добавляются к этому для новых файлов), но.SF файл не. Проверку все еще считают успешной, если ни один из файлов, которые были в файле JAR, когда подпись была сгенерирована, не был изменен с тех пор, который имеет место, равняются ли хеши в разделах незаголовка.SF файла хешам соответствующих разделов в файле манифеста.Если какие-либо серьезные отказы проверки происходят во время процесса проверки, процесс останавливается, и исключение безопасности выдается. Это поймано и выведено на экран jarsigner.
Файл 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, -storepass, -keypass, -sigfile, -sigalg, -digestalg, и -signedjar опции только релевантны, подписывая файл JAR, не, проверяя подписанный файл JAR. Точно так же псевдоним только определяется на командной строке, подписывая файл JAR.-keystore url-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 маркер, определяя эти опции:
-keystore NONE-storetype PKCS11jarsigner -keystore NONE -storetype PKCS11 -list
-storetype storetypegetDefaultType метод в java.security.KeyStore.-storepass опция. Если ни один не был определен, keytool, и jarsigner запросит маркерный ПИН. Если у маркера есть защищенный путь аутентификации (такой как выделенная клавиатура ПИН или биометрический читатель), то опция -protected должна быть определена, и никакие опции пароля не могут быть определены.-storepass[:env | :file] параметр-storepass возможность не предоставляется в командной строке, пользователь запрашивается пароль.env или file не определяется, тогда у пароля есть параметр значения. Иначе, пароль получается следующим образом: env: Получите пароль от параметра, передаваемого по имени переменной окруженияfile: Получите пароль от параметра, передаваемого по имени файла-keypass[:env | :file] параметрenv или file не определяется, тогда у пароля есть параметр значения. Иначе, пароль получается следующим образом: env: Получите пароль от параметра, передаваемого по имени переменной окруженияfile: Получите пароль от параметра, передаваемого по имени файла-sigfile файл-sigfile опция появляется на командной строке, основное имя файла для.SF и.DSA файлов будет первыми 8 символами имени псевдонима, определенного на командной строке, все преобразованные в верхний регистр. Если у имени псевдонима есть меньше чем 8 символов, полное имя псевдонима используется. Если имя псевдонима содержит какие-либо символы, которые не являются законными в имени файла подписи, каждый такой символ преобразовывается в подчеркивание (" _ ") символ в формировании имени файла.-sigalg алгоритм-digestalg алгоритм-signedjar файл-verify-certs-verify и -verbose опции, вывод включает информацию о сертификате для каждого подписывающего лица файла JAR. Эта информация включает java.security.cert.X509Certificate): отличительное имя подписывающего лица-certchain файл-verbose-internalsf-internalsf появляется на командной строке, старое поведение используется. Эта опция главным образом полезна для тестирования; практически, это не должно использоваться, начиная с выполнения так устраняет полезную оптимизацию.-sectionsonly-protectedtrue или false. Это значение должно быть определено как true если пароль должен быть дан через защищенный путь аутентификации, такой как выделенный читатель ПИН.-providerClass
provider-class-name-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
jarsigner -keystore NONE -storetype PKCS11 \
-providerName SunPKCS11-SmartCard \
-list
-Jjavaoptionjava -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), определенный в . В случае успеха маркер метки времени, возвращенный TSA, сохранен наряду с подписью в файле сигнатурного блока. -tsacert псевдоним"-tsacert alias" появляется на командной строке, подписывая файл JAR тогда, метка времени сгенерирована для подписи. alias идентифицирует сертификат TSA с открытым ключом в keystore, который является в настоящий момент в действительности. Сертификат записи исследуется на Подчиненное информационное расширение Доступа, которое содержит URL, идентифицирующий расположение TSA.-tsacert. -altsigner classcom.sun.jarsigner.ContentSigner abstract class. Путь к этому файлу class определяется -altsignerpath опция. Если -altsigner опция используется, jarsigner использует механизм подписания, обеспеченный указанным class. Иначе, jarsigner использует его механизм подписания значения по умолчанию.com.sun.sun.jarsigner.AuthSigner, используйте jarsigner опция "-altsigner com.sun.jarsigner.AuthSigner" -altsignerpath classpathlist-altsigner опция, описанная выше), и любые файлы JAR это зависит от. Если файл class находится в файле JAR, то это определяет путь к тому файлу JAR, как показано в примере ниже.classpathlist содержит разнообразные пути или файлы JAR, они должны быть разделены двоеточием (:) на Солярисе и точке с запятой (;) на Windows. Эта опция не необходима, если class уже находится в пути поиска.-altsignerpath /home/user/lib/authsigner.jarОтметьте, что имя файла JAR включается.
-altsignerpath /home/user/classes/com/sun/tools/jarsigner/Отметьте, что имя файла JAR опускается.
-strict-verbose:sub-опции-verbose опция берет подопции, чтобы определить, сколько информации покажут. Если -certs также определяется, режим по умолчанию (или подопция все) выводит на экран каждую запись, поскольку это обрабатывается и после этого, информации о сертификате для каждого подписывающего лица файла JAR. Если -certs и -verbose:grouped подопция определяется, записи с той же самой информацией подписывающего лица группируются и выводятся на экран вместе наряду с их информацией о сертификате. Если -certs и -verbose:summary подопция определяется, тогда записи с той же самой информацией подписывающего лица группируются и выводятся на экран вместе наряду с их информацией о сертификате, но детали о каждой записи получаются в итоге и выводятся на экран как "одна запись (и больше)". См. раздел в качестве примера для получения дополнительной информации.Предположите, что у Вас есть файл 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 не вмешались, используйте команду, такую как следующее:
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 был подписан, используя 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.
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
keytool и jarsigner инструменты полностью заменяют javakey инструмент, обеспеченный в JDK 1.1. Эти новые инструменты обеспечивают больше функций чем javakey, включая возможность защитить keystore и закрытые ключи с паролями, и возможность проверить подписи в дополнение к генерированию их.
Новая keystore архитектура заменяет базу данных идентификационных данных что javakey, создаваемый и управляемый. Есть не назад совместимость между форматом keystore и форматом базы данных, используемым javakey в 1.1. Однако,
-identitydb команда.Следующая таблица объясняет, как файлы 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) |
Примечания:
