Android APK签名

写在文章中之前：网上当前很多关于jarsigner对APK签名的讲法，但是有些讲的很粗糙，有些还在就在抄袭他人的文章，而自己却没有去验证是否正确

一、由于自己在工作中要用到jarsigner对apk进行最后的发布签名，所以自己也去看了一下具体怎么搞，不足之处欢迎读者指出，在此感谢杨立先生的指导。

二、关于jarsigner的具体介绍请查阅：http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html

上面的官方文档的介绍，第一手资料，请详细读，也可以参考下文。

三，实例演示：

1、装有jdk,准备签名文件和apk,具体本文在此不做讲叙,当前是在Mac机环境下，windwos或许有所不同。

           2.终端命令：

 jarsigner

-verbose

-sigalg SHA1withRSA 

-digestalg SHA1 

-keypass你的密钥

-storepass你的密钥

-keystore /Users/release.keystore //签名文件为完全路径

/Users/apk/360.apk // APK文件为完全路径（签名后是替换原来的APK）

别名//签名文件的别名 Key alias

实例：jarsigner -verbose -sigalg SHA1withRSA -digestalgSHA1 -keypass你的密钥-storepass你的密钥-keystore /Users/keystore/release.keystore /Users/apk/yg_3.apk hrbb

Mac的终端演示：

签名成功后的apk演示：

    

注意：

1）签名文件，APK文件为完全路径不能有中文，空格，转译字符

2）签名前后的文件路径不能改

3）加密算法请参考官方文档自行选取，但是第一次选择了后后面不要再随意更换加密算法

跳到内容
Oracle技术网
软件下载
文档
搜索
的jarsigner
标志和验证的Java Archive（JAR）文件。

概要
的jarsigner  [  选项  ]  JAR文件别名

-verify的jarsigner  [ 选项  ] JAR文件  [ 别名... ]

选项
该命令行选项。见 选项。

-校验
该  -verify  选项JAR文件名 ​​后采取零个或多个密钥库别名。当  -verify  指定选项时，  的jarsigner  证书使用的命令检查，以验证在JAR文件中的每个签署项匹配的密钥库别名之一。该别名由指定的密钥库定义  -keystore  或默认密钥库。

如果您还指定了  -strict  选项和  的jarsigner  命令检测到严重的警告，显示消息，“罐子核定，并签名错误”。

JAR文件
要签名的JAR文件。

如果您还指定了  -strict  选项和  的jarsigner  命令检测到严重的警告，显示消息，“罐子签字，签名者的错误。”

别号
该别名由指定的密钥库定义  -keystore  或默认密钥库。

描述
该  的jarsigner  工具有两个目的：

签署的Java Archive（JAR）文件。

要验证签名的JAR文件的签名和完整性。

的JAR功能使得类文件，图像，声音，和其他数字数据的中为更快，更容易分配一个单独的文件中的包装。一个工具叫 罐子  使开发人员能够生成JAR文件。（从技术上来说，任何zip文件也可以被认为是一个JAR文件，但是当被创建 的jar  命令或在处理  的jarsigner  命令，JAR文件还包含  META-INF / MANIFEST.MF  文件）。

数字签名是从一些数据计算比特串（被签署的数据）和一个实体的私有密钥（一个人，公司，等等）。类似于手写签名，数字签名有很多有用的特性：

其真实性可通过使用对应于用来生成签名的私有密钥的公共密钥的计算来验证。

它不能被伪造，假定私钥保密。

它是签署的数据的功能，因此不能被声称是为其他数据的签名，以及。

签名的数据不能改变。如果数据被改变，则签名不能被验证为可信。

以产生一个实体的一个文件的签名，该实体必须首先与它和验证其公共密钥的一个或多个证书相关联的公钥/私钥对。证书是从说，其他实体的公钥有特定值一个实体经过数字签名的声明。

该  的jarsigner  命令使用从密钥存储密钥和证书信息生成JAR文件的数字签名。密钥仓库是私钥和认证对应的公钥及其相关的X.509证书链的数据库。该密钥工具  命令用于创建和管理密钥库。

该  的jarsigner  命令使用实体的私钥生成的签名。已签署的JAR文件包含，除其他外，从密钥库对应于用于签署文件的私钥的公钥证书的副本。该  的jarsigner命令可以验证使用它里面的证书签名的JAR文件的数字签名（在其签名块文件）。

该  的jarsigner  命令生成签名，其中包括一个时间戳，让一个系统或部署（包括Java插件）检查，同时签名证书仍然有效JAR文件是否被签名。此外，API允许应用程序以获取时间戳信息。

在这个时候，  的jarsigner  命令只能由签名创建的JAR文件  的jar  命令或zip文件。JAR文件是相同的zip文件，除非他们也有一个  META-INF / MANIFEST.MF  文件。一个  META-INF / MANIFEST.MF  文件被创建时  的jarsigner命令标志的zip文件。

默认  的jarsigner  命令的行为是签名JAR或zip文件。使用  -verify  选项来验证一个签名的JAR文件。

该 的jarsigner  命令还试图签署或验证后验证签名者的证书。如果有一个验证错误或任何其他问题，命令生成警告消息。如果指定 -strict  选项，则该命令把严重警告视为错误。请参见  错误和警告。

密钥仓库别名
所有的密钥存储实体与唯一的别名​​访问。

当您使用  的jarsigner  命令签署JAR文件，必须指定包含生成签名所需的私钥的密钥仓库项的别名。例如，下面的命令标志名为JAR文件  myJarFile.jar中  与别名相关联的私钥  公爵  在指定密钥库  的MyStore  在  工作  目录。由于未指定输出文件，它将覆盖  myJarFile.jar中  与签名的JAR文件。

-keystore的jarsigner /工作/的MyStore -storepass <存储密码>
      -keypass <私钥密码>与myJarFile.jar公爵
密钥库密码保护，因此必须指定存储密码。系统提示您输入它时，你没有指定它的命令行上。同样，私钥与密码的密钥存储保护，因此必须指定私钥的密码，并提示您输入密码时，您不指定它的命令行上，这是不一样的存储密码。

密钥仓库位置
该  的jarsigner  命令有一个  -keystore  指定密钥库的URL中使用的选项。密钥库是存储在一个文件名 ​​为默认  的.keystore  在用户的主目录，由确定  的user.home  系统属性。

从输入流  -keystore  选项传递给  KeyStore.load  方法。如果  无  被指定为URL，然后空流被传递到  KeyStore.load  方法。  NONE  应当被指定  的KeyStore  类不是基于文件的，例如，当它驻留在硬件令牌设备上。

密钥仓库实现
该  密钥库  中提供的类  java.security  包提供了一些定义良好的接口，以在密钥库访问和修改的信息。你可以有多个不同的具体实现，其中每个实现为特定类型的密钥仓库。

目前，有使用密钥仓库实现（两个命令行工具密钥工具  和 的jarsigner），并命名为政策工具的基于GUI的工具。因为 密钥库  类是公开的，JDK用 ​​户可利用它来 ​​编写额外的安全应用。

还有就是密钥仓库实现为一个文件，即使用名为JKS一个专用密钥仓库类型（格式），Oracle提供内置的默认实现。内置的实施与保护个人口令的每个私有密钥并保护整个密钥仓库用（可能是不同的）密码的完整性。

密钥仓库的实现基于提供，这意味着由所提供的应用程序接口 的KeyStore  类是在一个服务提供者接口（SPI）来实现的。有一个对应的抽象 的KeyStoreSpi  类，也是在java.security包，它定义了供应商必须实现服务提供者接口方法。术语供应商是指一个包或一组提供一个具体的实施服务的一个子集，可以通过Java安全API访问的包。为了提供密钥仓库实现，客户必须实现供应商和供应 的KeyStoreSpi  子类实现，如如何实现在Java加密体系结构实现Provider中所述
http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/HowToImplAProvider.html

应用程序可以选择不同类型从不同的供应商密钥仓库实现，用  的getInstance  在工厂方法  密钥库  类。密钥仓库类型定义的存储和密钥仓库信息数据格式和用于保护密钥库中的私有密钥算法和密钥库本身的完整性。不同类型的密钥仓库实现是不兼容的。

该  的jarsigner  和  用policytool  命令可以从任何可以使用URL指定的位置读取基于文件的密钥库。此外，这些命令可以读取非基于文件的密钥库，例如通过MSCAPI在所有平台上提供的Windows和PKCS11那些。

对于  的jarsigner  和  keytool的  命令，可以在指定的命令行密钥仓库类型  -storetype  选项。对于政策工具，您可以指定与密钥仓库类型  编辑  在命令  密钥库  菜单。

如果没有明确指定密钥仓库类型，然后在工具选择基础上的价值的密钥仓库实现 keystore.type的  安全属性文件中指定的属性。该安全属性文件名 ​​为 java.security，它位于JDK安全属性目录  java.home / lib / security中，其中  java.home  是运行时环境的目录。该  JRE  的JDK或Java运行时环境的顶级目录（JRE）的目录。

每个工具都先获取  keystore.type的  值，然后检查所有已安装的提供者直到找到一个实现该类型的密钥库。然后，它使用从该提供者的密钥仓库实现。

该  密钥库  类定义了一个静态方法名为  getDefaultType  ，让应用程序或applet检索值  keystore.type的  属性。下面的代码行创建作为指定的默认密钥库类型的实例keystore.type属性：

密钥库的keyStore = KeyStore.getInstance（KeyStore.getDefaultType（））;
默认密钥库类型为  JKS  （专用型Oracle提供的密钥仓库实现的）。这是由在安全属性文件以下行指定的：

keystore.type的= JKS
案例并不密钥仓库类型的命名关系。例如，  JKS  相同  JKS。

要让工具使用默认值以外的密钥仓库实现，可更改此行以指定不同的密钥仓库类型。例如，如果你有一个供应商包，它被称为密钥仓库类型的密钥仓库实现 PKCS12，然后将该行更改为以下几点：

keystore.type的= PKCS12
注：  如果您使用的PKCS 11提供者包，然后请参阅“密钥工具”和“的jarsigner”使用Java PKCS＃11参考指南http://docs.oracle.com/javase/7/docs/technotes/guides/security/ p11guide.html

支持的算法
默认情况下，  的jarsigner  命令标志使用以下算法之一JAR文件：

数字签名算法（DSA）与SHA1摘要算法

RSA算法的SHA256摘要算法

用椭圆曲线数字签名算法（ECDSA）的SHA256椭圆曲线（EC）密码算法。

如果签名人的公钥和私钥是DSA密钥，然后  的jarsigner  签名的JAR文件  带DSA的SHA1  算法。如果签名人的密钥是RSA密钥，然后  的jarsigner  尝试登录的JAR文件  SHA256withRSA  算法。如果签名人的密钥是EC键，然后  的jarsigner  签名的JAR文件  SHA256withECDSA  算法。

这些默认签名算法可以使用覆盖  -sigalg  选项。

该签名的JAR文件
当  的jarsigner  命令用于签署一个JAR文件，输出签名的JAR文件是完全一样的输入JAR文件，除了它具有设置在META-INF目录两个附加文件：

与签名文件  .SF  扩展

一个签名块文件  .DSA，  .RSA或  .EC  扩展

这两个文件的基本文件名 ​​来自价值  -sigFile  选项。例如，当该选项  -sigFile MKSIGN，该文件被命名为  MKSIGN.SF  和  MKSIGN.DSA

如果没有  -sigfile  选项出现在命令行上，然后为基本文件名  ​​.SF  和  .DSA  文件是命令行中指定的别名的前8个字符，全部转换为大写。如果别名少于8个字符，则使用全别名。如果别名包含未在签名文件名 ​​允许任何字符，则每个这种字符转换为下划线字符（_）中形成的文件名 ​​。有效字符包括字母，数字，下划线和连字符。

签名文件

签名文件（.SF  文件）看起来类似于总是包含在一个JAR文件时，清单文件 的jarsigner  命令用于签署该文件。对于包含在JAR文件中的每个源文件中，  .SF  文件有三条线，比如在清单文件，列出如下：

文件名

摘要算法的名称（SHA）

SHA摘要值

在清单文件，为每个源文件的SHA摘要值是源文件中二进制数据的摘要（散列）。在 .SF  文件中，指定的源文件的摘要值是三行在源文件的清单文件的散列。

签名文件，在默认情况下，包括与整个清单文件的散列的头。头部还包含清单头的哈希值。首部的存在使得验证优化。参见 JAR文件校验。

签名块文件

该  .SF  文件进行签名和签名被放置在签名块文件。该文件还包含，它里面的编码，从认证与用于签名的私钥公钥密钥库的证书或证书链。该文件的扩展  .DSA，  .RSA或  .EC，取决于所使用的摘要算法。

签名时间戳
该 的jarsigner  命令可以生成并签署JAR文件时存储签名时间戳。此外， 的jarsigner  支持替代签名机制。此行为是可选的，并且由用户在通过这些选项签署的时间来控制。见  选项。

-tsa网址
-tsacert别名
-altsigner类
-altsignerpath classpathlist
-tsapolicyid策略ID
JAR文件校验
当签名是有效的进行了一次成功的JAR文件验证，并没有说是的时候生成签名的JAR文件中的文件自那时以来已经改变。JAR文件验证包括以下步骤：

验证签名  .SF  文件。

验证可以确保存储在每个签名块（签名.DSA使用对应的公钥其证书（或证书链）也出现在了私钥生成的）文件 .DSA  文件。它也保证了签名是相应的签名（的有效的签名.SF）文件，并且因此 .SF  文件不被篡改。

验证在每个条目中列出的摘要  .SF  与清单每个相应的部分文件。

该  .SF  默认文件包括了包含整个清单文件的散列的头。当首标存在，验证可以检查头中的散列是否清单文件的散列相匹配。如果有一个匹配，则验证前进到下一个步骤。

如果没有匹配，则不太优化的验证要求，以确保在每个源文件信息部分的散列 .SF  文件等于清单文件的相应部分的散列。见签名文件。

原因之一被存储在清单文件的哈希  .SF  文件头可能不等于当前清单文件的散列是一个或多个文件被添加到JAR文件（与  罐子  的签名和后工具）  。 SF  生成文件。当罐子  工具用于添加文件，清单文件通过加入部分以它为新的文件改变，但 .SF  文件不被改变。一个验证仍然被认为是成功的，当无一发生的时候生成签名的JAR文件中的文件已从那时起改变。发生这种情况时，在的非报头部分中的散列 .SF  文件等于相应段的散列在清单文件。

读在具有在一个条目中的JAR文件的每个文件  .SF  文件。在阅读，计算文件的摘要，并将结果与比较摘要此文件在清单部分。摘要应是相同的或验证失败。

如果在核查过程中出现任何严重的验证失败，则该过程停止并安全异常。该  的jarsigner  命令捕获并显示异常。

注：  （如果您指定的或错误，你应该阅读的另外警告 -strict  选项），以及证书的内容（通过指定 -verbose  和  -certs  期权），以确定是否签名是可以信任的。

一个JAR文件多个签名
JAR文件可以由多人通过运行签署  的jarsigner  文件上多次命令并指定为每个时间不同的人的别名，如下：

的jarsigner myBundle.jar苏珊
的jarsigner myBundle.jar凯文
当一个JAR文件签名多次，有多个  .SF  和  .DSA  在所得的JAR文件中的文件，一对用于每个签名。在前面的例子中，输出的JAR文件包括具有以下名称的文件：

SUSAN.SF
SUSAN.DSA
KEVIN.SF
KEVIN.DSA
注意：  也可以为一个JAR文件具有混合的签名，一些由由JDK 1.1生成 javakey所  命令和其他通过 的jarsigner。该  的jarsigner  命令可以用来签署已经与签名的JAR文件  javakey所  命令。

选项
下面的章节描述了各种  的jarsigner  选项。请注意以下标准：

所有选项名称用减号（ - ）。

选项​​可以以任意顺序来提供。

这是斜体或加下划线（选项值）项目表示必须提供的实际值。

该  -storepass，  -keypass，  -sigfile，  -sigalg，  -digestalg，  -signedjar和TSA有关签署JAR文件时，选项只有相关; 核实签名的JAR文件时，他们是不相关的。该  -keystore  选项有关的签署和验证JAR文件。此外，别名签署和验证JAR文件时指定。

-keystore网址
指定告诉密钥库位置的URL。默认为文件  的.keystore  在用户的主目录，由确定  的user.home  系统属性。

签署密钥库是必需的。必须明确指定一个密钥库时默认密钥库不存在，或者，如果你想使用一个默认值以外。

验证时不需要密钥仓库，但如果是指定的或默认存在，并且  -verbose  也被指定选项，则附加信息是关于是否任何用于验证JAR文件的证书都包含在该密钥库输出。

该  -keystore  参数可以是一个文件名 ​​和路径说明而不是URL，在这种情况下，它被视为相同的文件：URL，例如，下面是等效的：

-keystore filePathAndName 
-keystore文件：filePathAndName
如果太阳PKCS＃11提供者是在配置  java.security  安全属性文件（位于JRE的  $ JAVA_HOME / lib / security目录），那么  密钥工具  和  的jarsigner  工具可以在PKCS通过指定这些选项的操作＃11令牌：

-keystore NONE
-storetype PKCS11
例如，下面的命令列出了配置PKCS＃11令牌的内容：

密钥工具-keystore NONE -storetype PKCS11 -list
-storetype的storetype
指定密钥库的类型被实例化。缺省的密钥仓库类型是被指定为价值一  keystore.type的  财产安全属性文件，该文件由静态返回  getDefaultType  的方法java.security.KeyStore中。

对于PCKS＃11令牌的PIN也可与指定  -storepass  选项。如果未指定，则  密钥工具  和  的jarsigner  命令提示输入令牌PIN。如果令牌具有受保护的认证路径（例如专用密码键盘或生物测定读取器），则  受保护的  必须指定选项，可指定没有密码选项。

-storepass [：ENV | ：文件]参数
指定要访问密钥库所需的密码。这个签名（未验证）的JAR文件时，才需要。在这种情况下，如果 -storepass  在命令行没有提供选项，则系统会提示用户输入密码。

如果修改  ENV  或  文件  没有指定，则密码具有价值  的说法。否则，该密码被检索如下：

ENV：检索从指定的环境变量的密码 参数。

文件：检索从文件命名为密码 参数。

注：  密码不应在命令行或脚本中指定，除非它是用于测试目的，或者你是一个安全的系统上。

-keypass [：ENV | ：文件]参数
指定用于保护通过在命令行上指定的别名解决密钥库条目的私钥的密码。该密码是使用时，需要 的jarsigner  签名JAR文件。如果提供了命令行上没有密码，以及所需的口令与仓库口令不同，则用户被提示。

如果修改  ENV  或  文件  没有指定，则密码具有价值  的说法。否则，该密码被检索如下：

ENV：检索从指定的环境变量的密码 参数。

文件：检索从文件命名为密码 参数。

注：  密码不应在命令行或脚本中指定，除非它是用于测试目的，或者你是一个安全的系统上。

-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加密体系结构（JCA）参考指南在
http://docs.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA

该算法必须与用于签署JAR文件的私钥兼容。如果未指定此选项，然后  带DSA的SHA1，  SHA256withRSA或  SHA256withECDSA  取决于私钥的类型使用。有必须是一个静态安装提供商供给指定的算法或用户的实现必须指定一个与  -providerClass  选项; 否则，该命令将不会成功。

-digestalg算法
指定该消息的名称摘要算法消化JAR文件的条目时使用。

在“标准名称”附录A的Java加密体系结构（JCA）参考指南中的标准信息的清单摘要算法的名字，见http://docs.oracle.com/javase/7/docs/technotes/guides/security /crypto/CryptoSpec.html#AppA

如果未指定此选项，则  SHA256  使用。有必须是一个静态安装提供商供给指定的算法或用户的实现必须指定一个与  -providerClass  选项; 否则，该命令将不会成功。

-certs
如果  -certs  选项出现在命令行上  -verify  和  -verbose  选项，然后输出包括JAR文件的每个签名证书信息。此信息包括证书（存储在类型的名称  .DSA  文件），该认证签名者的公钥，并且如果证书是X.509证书（的一个实例  java.security.cert.X509Certificate），则签名者的专有名称。

密钥库也被检查。如果在命令行中没有指定密钥仓库值，那么默认密钥库文件（如果有的话）被选中。如果一个签名者的公钥证书相匹配的密钥库中的条目，然后为该签名密钥仓库项的别名名称显示在括号中。如果签名者来自JDK 1.1标识数据库而不是从一个密钥库，然后在括号而非括号中的别名显示。

-certchain文件
指定当与通过在命令行上指定的别名解决密钥库条目的私钥相关联的证书链不完整使用的证书链。当密钥库位于一个硬件令牌那里没有足够的能力来容纳一个完整的证书链会发生这种情况。该文件可以是级联X.509证书的序列，或一个单一的PKCS＃7格式的数据块，或者在二进制编码格式或由因特网RFC 1421标准中定义的可打印的编码格式（也称为Base64编码）。请参见互联网RFC 1421证书编码标准的 密钥工具  和  http://tools.ietf.org/html/rfc1421。

-verbose
当  -verbose  选项出现在命令行中，表示详细模式，这将导致  的jarsigner  约在JAR签名或验证的进度输出额外的信息。

-internalsf
在过去，  .DSA  当一个JAR文件的签署产生（签名块）文件包含了完整的编码副本  .SF  还会生成文件（签名文件）。此行为已改变。减小输出JAR文件的总体大小，  .DSA默认文件不包含的副本  .SF  文件了。如果  -internalsf  出现在命令行上，则旧的行为被利用。此选项是用于测试。在实践中，不使用  -internalsf  ，因为它会带来更高的开销选项。

-sectionsonly
如果  -sectionsonly  选项出现在命令行上，则  .SF  文件（签名文件）时产生的JAR文件进行签名不包括含有整个清单文件的散列的头。它仅包含有关包含在JAR文件中的每个单独的源文件中的信息和散列。见签名文件。

默认情况下，这头被添加，作为优化。当头部出现，每当JAR文件进行验证，验证可以先检查头中的散列是否整个清单文件的散列匹配。当存在匹配，验证前进到下一个步骤。如果没有匹配，有必要做一个次优的校验是在每个源文件信息部分的散列 .SF  文件等于清单文件的相应部分的散列。参见 JAR文件校验。

该  -sectionsonly  选项主要用于测试。因为使用它招致更高的开销它不应该被用于比用于测试其他。

-protected
值可以是  真  或  假的。指定  真实  时，必须通过一个受保护的认证路径指定密码，比如专用的PIN读卡器。

-providerClass商类名
用于指定加密服务提供程序的主类文件的名称时，该服务提供者未在上市  java.security  安全属性文件。

用于与  -providerArg ConfigFilePath  选项，  密钥工具  和  的jarsigner  工具动态安装提供商和使用  ConfigFilePath  为路径令牌配置文件。下面的例子显示了一个命令列出  PKCS＃11  密钥存储在Oracle PKCS＃11提供商在安全属性文件中没有配置。

-keystore的jarsigner NONE -storetype PKCS11 \
          -providerClass删除sun.security.pkcs11.SunPKCS11 \
          -providerArg /mydir1/mydir2/token.config \
          -list
-providerName的providerName
如果有多个供应商是在配置  java.security  安全属性文件，那么你可以使用  -providerName  选项来指定一个特定的提供程序实例。这个选项的参数是供应商的名称。

对于Oracle PKCS＃11提供商  的providerName  的形式为  SunPKCS11- TokenName，其中 TokenName  是提供程序实例已配置，在配置详表属性的名称后缀。例如，下面的命令列出的内容 PKCS＃11  有后缀名的密钥库提供程序实例  智能卡：

-keystore的jarsigner NONE -storetype PKCS11 \
        -providerName SunPKCS11，智能卡\
        -list
-J 的javaoption
通过指定的传递  的javaoption  直接串到Java解释器。该  的jarsigner  命令是围绕解释的包装。该选项不应含有任何空格。它是用于调节执行环境或内存使用是有用的。对于可能的解释器选项类型的列表  的java -h  或  java的-X  在命令行。

-tsa网址
如果  -tsa HTTP：//example.tsa.url  签署的JAR文件然后签名会产生一个时间标记时出现在命令行上。该网址，  HTTP：//example.tsa.url，标识时间戳管理局（TSA）的位置，并覆盖与发现的任何URL  -tsacert  选项。该  -tsa  选项不要求TSA的公钥证书存在于密钥库。

来生成时间戳，  的jarsigner  当成功时，通过该协议返回的时间标记令牌存储在签名块文件中的签名与所述时间标记协议在RFC 3161中定义的TSA（TSP）连通。

-tsacert别名
当  -tsacert别名  签署JAR文件时，在命令行上出现，为签名生成的时间戳。别名标识是有效密钥库TSA的公钥证书。条目的证书检查包含URL标识TSA的位置的主题信息访问扩展。

使用时，TSA的公钥证书必须存在于密钥库  -tsacert  选项。

-tsapolicyid策略ID
指定标识策略ID的对象标识符（OID）被发送到该协议的服务器。如果未指定此选项，没有政策的ID发送和TSA服务器将选择一个默认的策略ID。

对象标识符由X.696，其是国际电信联盟电信标准化部门（ITU-T）的标准定义。这些标识符通常是周期分隔套非负位数一样 1.2.3.4，例如。

-altsigner类
此选项指定一个替代签名机制。完全合格的类名标识扩展一个类文件  com.sun.jarsigner.ContentSigner  抽象类。这个类文件的路径是由定义  -altsignerpath  选项。如果-altsigner  选项使用，那么 的jarsigner  命令使用指定的类提供的签名机制。否则 的jarsigner  命令使用其默认签名机制。

例如，使用由一个名为类提供的签约机制  com.sun.sun.jarsigner.AuthSigner，使用的jarsigner选项  -altsigner com.sun.jarsigner.AuthSigner。

-altsignerpath classpathlist
指定的路径，类文件，它依赖于任何JAR文件。类文件名 ​​与指定  -altsigner  选项。如果类文件是在JAR文件中，那么这个选项指定的路径JAR文件。

可以指定一个绝对路径，或相对于当前目录的路径。如果  classpathlist  在Windows上）;包含多个路径或JAR文件，那么就应该用冒号（:)在Oracle Solaris和分号（分隔。当类已经在搜索路径，此选项是没有必要的。

下面的示例演示如何指定的路径包含类文件的JAR文件。JAR文件名是包括在内。

-altsignerpath /home/user/lib/authsigner.jar
下面的示例演示如何指定的路径包含类文件JAR文件。JAR文件名被省略。

-altsignerpath /家庭/用户/班/ COM /阳光/工具/的jarsigner /
-严格
在签字或验证过程中，该命令可能会发出警告消息。如果指定了此选项，工具的退出码反映了这个命令找到了严厉的警告消息。请参见 错误和警告。

-verbose子选项
对于验证过程中，  -verbose  选项将子选项以确定有多少信息显示。如果  -certs  还指定了选项，那么默认模式（或子选项  所有）显示，因为它正在处理的每个条目，并在这之后，对JAR文件的每个签名的证书信息。如果  -certs  和  -verbose：分组  被指定的子选项，然后以相同的签名者信息条目进行分组，并与他们的证书信息一起显示。如果  -certs  和  -verbose：摘要  指定子选项，然后以相同的签名者信息条目进行分组，并与他们的证书信息一起显示。有关每个条目详情概括并作为显示  一个条目（和更多）。见例子。

错误和警告
在签字或验证的过程中，  的jarsigner  命令可能会发出各种错误或警告。

如果出现故障，  的jarsigner  代码为1，如果没有失败命令退出，但有一个或多个严重的警告，将  的jarsigner  命令退出代码为0的时候  -strict  选项时  未  指定，或使用或退出当报警码-值  -strict  指定。如果只有信息警告或没有警告可言，命令总是以代码0退出。

例如，如果一个证书用于签署一个条目是过期的，并具有扩展的KeyUsage不允许它签署文件时， 的jarsigner  当代码为12（= 4 + 8）命令退出 -strict  指定选项。

注意：  因为只有从0到255的值是合法的在基于Unix的操作系统的退出代码重用。

下面的章节描述了名称，代码，以及错误和警告的描述  的jarsigner  命令发出。

失败
原因导致  的jarsigner  命令失败包括（但不限于）一个命令行解析错误，则无法找到一个密钥对签名JAR文件，或者一个签名的JAR失败验证。

失败
代码1.签字或验证失败。

严重警告
注：  严重警告报告为错误如果指定 -strict  选项。

原因导致  的jarsigner  命令发出严厉的警告包括用于签名JAR文件有错误或签名的JAR文件有其他问题的证书。

hasExpiredCert
4.代码这个jar包含其签名证书已过期的条目。

notYetValidCert
4.代码这个jar包含其签名证书尚未生效条目。

chainNotValidated
4.代码这个jar包含其证书链无法正确验证条目。

badKeyUsage
8.代码这个jar包含其签名证书的密钥使用扩展不允许代码签名条目。

badExtendedKeyUsage
8.代码这个jar包含其签名证书的执行extendedKeyUsage扩展不允许代码签名条目。

badNetscapeCertType
8.代码这个jar包含其签名证书的NetscapeCertType扩展不允许代码签名条目。

hasUnsignedEntry
16.代码这个jar包含符号项还没有被完整性检查。

notSignedByAlias
32.代码这个jar包含签名的并非由指定别名（ES）签署的条目。

aliasNotInStore
32.代码这个jar包含签约不受别名在这个密钥库签署的条目。

警报提示
信息警告包括那些没有错误，但认为是不好的做法。他们没有一个代码。

hasExpiringCert
这个jar包含其签名证书将在6个月内到期的条目。

noTimestamp
这个jar包含签名不包括时间戳。如果没有时间戳，用户可能无法验证签名证书的有效期限（在此之后JAR文件YYYY-MM-DD）或任何未来的撤销日期之后。

例子
注册一个JAR文件
使用以下命令用其密钥库的别名是用户的私钥签名bundle.jar  简  在一个名为密钥库  的MyStore  在  工作  目录下并命名签名的JAR文件  sbundle.jar：

-keystore的jarsigner /工作/的MyStore
    -storepass <存储密码>
    -keypass <私钥密码>
    -signedjar sbundle.jar bundle.jar简
没有  -sigfile  在前面的命令中指定因此产生的  .SF  和  .DSA  文件被放置在签名的JAR文件具有基于别名默认名称。它们被命名为  JANE.SF  和  JANE.DSA。

如果你想被提示输入密码存储和私有密钥密码，则可以缩短先前的命令如下：

-keystore的jarsigner /工作/的MyStore
    -signedjar sbundle.jar bundle.jar简
如果密钥库是默认密钥库（在你的主目录下的.keystore），那么你并不需要指定一个密钥库，如下所示：

的jarsigner -signedjar sbundle.jar bundle.jar简
如果你想签名的JAR文件覆盖输入的JAR文件（bundle.jar），那么你并不需要指定一个 -signedjar  选项，如下所示：

的jarsigner bundle.jar简
验证一个签名的JAR文件
来验证已签名的JAR文件，以确保签名是有效的和JAR文件不被篡改，使用命令，如以下内容：

-verify的jarsigner sbundle.jar
当验证成功时，  罐子核实  被显示。否则，则显示错误消息。当你使用，你可以得到更多的信息  -verbose  选项。样本使用  的jarsigner  与  -verbose  选项如下：

-verify的jarsigner -verbose sbundle.jar
 
           198周​​五09月26日16时14分06秒PDT 1997年META-INF / MANIFEST.MF
           199周五09月26日16时22分10秒PDT 1997年META-INF / JANE.SF
          1013周五09月26日十六点22分10秒PDT 1997年META-INF / JANE.DSA
    SMK 2752周五09月26日16点12分30秒PDT 1997年AclEx.class
    SMK 849周五09月26日16点12分46秒PDT 1997年的Test.class
 
      S =签字确认
      M =条目在清单中列出
      K =至少有一个证书密钥库被发现
 
    罐子验证。
验证与认证信息
如果指定  -certs  的选项  -verify  和  -verbose  选项，然后输出包括JAR文件的每个签名证书信息。这些信息包括证书类型，签名人专有名称信息（当它是X.509证书），并在括号中，当JAR文件中的公钥证书相匹配的签名密钥库别名之一的密钥仓库项，例如：

-keystore的jarsigner /工作/的MyStore -verify -verbose -certs myTest.jar
 
           198周​​五09月26日16时14分06秒PDT 1997年META-INF / MANIFEST.MF
           199周五09月26日16时22分10秒PDT 1997年META-INF / JANE.SF
          1013周五09月26日十六点22分10秒PDT 1997年META-INF / JANE.DSA
           208周五09月26日16点23分三十零秒PDT 1997年META-INF / JAVATEST.SF
          1087周五09月26日十六点23分30秒PDT 1997年META-INF / JAVATEST.DSA
    SMK 2752周五09月26日16点12分30秒PDT 1997年Tst.class
 
      X.509，CN =测试组，OU = Java软件，O = Oracle中，L =银联，S = CA，C = US（javatest）
      X.509，CN =简·史密斯，OU = Java软件，O = Oracle中，L =杯，S = CA，C = US（简）
 
      S =签字确认
      M =条目在清单中列出
      K =至少有一个证书密钥库被发现
 
    罐子验证。
如果一个签名者的证书不是X.509证书，那么就没有专有名称的信息。在这种情况下，就在证书类型和别名被示出。例如，如果证书为PGP证书，别名是 鲍勃，那么你将得到： PGP（BOB） 。

验证，包括标识数据库签名者
如果一个JAR文件时使用了JDK 1.1签订  javakey所  工具和签名者身份数据库中的别名，然后验证输出包括  我。如果JAR文件被身份数据库中双方的别名和密钥仓库的别名，然后双方签字  ķ  和  我出现。

当  -certs  使用选项，任何身份数据库别名示于括号而非用于密钥存储别名括号，例如：

    -keystore的jarsigner /工作/的MyStore -verify -verbose -certs writeFile.jar
 
           198周​​五09月26日16时14分06秒PDT 1997年META-INF / MANIFEST.MF
           199周五09月26日16时22分10秒PDT 1997年META-INF / JANE.SF
          1013周五09月26日十六点22分10秒PDT 1997年META-INF / JANE.DSA
           199周五09月27日12点22分三十〇秒PDT 1997年META-INF / DUKE.SF
          1013周五09月27日12时22分30秒PDT 1997年META-INF / DUKE.DSA
   smki 2752周五09月26日16点12分三十秒PDT 1997年writeFile.html
 
      X.509，CN =简·史密斯，OU = Java软件，O = Oracle中，L =杯，S = CA，C = US（简）
      X.509，CN =公爵，OU = Java软件，O = Oracle中，L =杯，S = CA，C = US [公爵]
 
      S =签字确认
      M =条目在清单中列出
      K =至少有一个证书密钥库被发现
      I =至少有一个证书身份范围内被发现
 
    罐子验证。
注：  别名  公爵  是在括号中表示，这是一种身份数据库别名，而不是密钥库别名。

JDK 1.1的兼容性
该  密钥工具  及  的jarsigner  工具取代了  javakey所  在JDK 1.1工具。这些新工具提供了比更多的功能  javakey所，其中包括保护密钥仓库和密码私钥的能力，除了验证签名，以产生它们的能力。

新的密钥仓库体系结构取代了身份数据库  javakey所  创建和管理。有使用的密钥存储格式和数据库格式之间没有向后兼容性  javakey所  在JDK 1.1。但是，要注意以下几点：

它可以导入从身份数据库中的信息转换成通过一个密钥存储  密钥工具-identitydb  命令。

该  的jarsigner  命令可以签署与签订的JAR文件  javakey所  命令。

该  的jarsigner  命令可以验证已签署的JAR文件  javakey所。该  的jarsigner  命令识别，并能与签名者的别名是从JDK 1.1标识数据库而不是JDK密钥库工作。

未签名的JAR
未签名的JAR文件有授予所有代码的缺省权限。

签名的JAR
签名的JAR他们有基于JDK 1.1权限配置ñ  身份和政策文件状态的描述。只有受信任的身份可以导入到JDK密钥库。

缺省权限授予所有代码

在身份数据库1.1：  没有
导入Java密钥库从1.1可信身份。数据库：  没有
政策文件授予权限身份/别名：  不
认同1.1数据库：  没有
导入Java密钥库从1.1可信身份。数据库：  是的
策略文件授予的特权身份/别名：  不
认同1.1数据库：是/不可信
导入到Java密钥库从1.1可信身份。数据库：  没有
政策文件授予权限身份/别名：  没有
见3注中关于签名的JAR文件的权限。
在1.1数据库的身份：是/不可信
导入到Java密钥库从1.1可信身份。数据库：  没有
政策文件授予权限身份/别名：  是
见1和3的注意事项中关于签名的JAR文件的权限。
默认权限和策略文件授予权限

在身份数据库1.1：  没有
导入Java密钥库从1.1可信身份。数据库：  是的
策略文件授予的特权身份/别名：  是的
认同1.1数据库：  是/可信任
导入到Java密钥库从1.1可信身份。数据库：  是的
策略文件授予的特权身份/别名：  是
见第2注中关于签名的JAR文件的权限。
所有权限授予

在身份数据库1.1：  是/可信任
导入到Java密钥库从1.1可信身份。数据库：  没有
政策文件授予权限身份/别名：  不
认同1.1数据库：  是/信任的
可信身份导入到Java密钥库1.1。数据库：  是的
策略文件授予的特权身份/别名：  没有
见1注中关于签名的JAR文件的权限。
在1.1数据库的身份：  是/可信任
导入到Java密钥库从1.1可信身份。数据库：  没有
政策文件授予权限身份/别名：  是
见1注中关于签名的JAR文件的权限。
注意关于签名的JAR文件的权限

如果一个标识或别名在政策文件中提到，那么它必须导入到密钥库的政策文件，对授予的权限有任何影响。

策略文件/密钥仓库组合拥有在身份数据库中的可信身份的优先级。

不可信的身份在Java平台上被忽略。

也可以看看
罐

密钥工具

线索：在Java SE安全特色：
http://docs.oracle.com/javase/tutorial/security/index.html

版权所有©  1993年，2016年，Oracle和/或其附属公司。版权所有。
联系我们
————————————————
版权声明：本文为CSDN博主「Susan8888」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/susan8888/article/details/51671774