密钥和证书管理工具.docx

密钥和证书管理工具.docx

《密钥和证书管理工具.docx》由会员分享，可在线阅读，更多相关《密钥和证书管理工具.docx（28页珍藏版）》请在冰豆网上搜索。

密钥和证书管理工具

keytool-密钥和证书管理工具

keytool-密钥和证书管理工具

keytool-密钥和证书管理工具

管理由私钥和认证相关公钥的X.509证书链组成的密钥仓库（数据库）。

还管理来自可信任实体的证书。

结构

keytool[命令]

说明

keytool是个密钥和证书管理工具。

它使用户能够管理自己的公钥/私钥对及相关证书，用于（通过数字签名）自我认证（用户向别的用户/服务认证自己）或数据完整性以及认证服务。

它还允许用户储存他们的通信对等者的公钥（以证书形式）。

证书是来自一个实体（个人、公司等）的经数字签名的声明，它声明某些其它实体的公钥（及其它信息）具有某一的特定值（参见证书）。

当数据被数字化签名后，校验签名即可检查数据的完整性和真实性。

完整性的意思是数据没有被修改或损坏过，真实性的意思是数据的确是来自声称创建了该数据和对它进行了签名的实体。

keytool将密钥和证书储存在一个所谓的密钥仓库中。

缺省的密钥仓库实现将密钥仓库实现为一个文件。

它用口令来保护私钥。

jarsigner工具利用密钥仓库中的信息来产生或校验Java存档（JAR）文件的数字签名（JAR文件将类文件、图象、声音和/或其它数字化数据打包在一个文件中）。

jarsigner用JAR文件所附带的证书（包含于JAR文件的签名块文件中）来校验JAR文件的数字签名，然后检查该证书的公钥是否“可信任”，即是否包括在指定的密钥仓库中。

请注意：

keytool和jarsigner工具完全取代了JDK1.1中提供的javakey工具。

这些新工具所提供的功能比javakey提供的多，包括能够用口令来保护密钥仓库和私钥，以及除了能够生成签名外还可以校验它们。

新的密钥仓库体系结构取代了javakey所创建和管理的身份数据库。

可以利用-identitydbkeytool命令将信息从身份数据库导入密钥仓库。

密钥仓库项

在密钥仓库中有两种不同类型的项：

密钥项-每项存放极为敏感的加密密钥信息，这种信息以一种受保护的格式储存以防止未授权的访问。

通常，储存在这类项中的密钥是机密密钥，或是伴有用于认证相应公钥用的证书“链”的私钥。

keytool和jarsigner工具只处理后一类型的项，即私钥及其关联的证书链。

可信任的证书项-每项包含一个属于另一团体的公钥证书。

它之所以叫做“可信任的证书”，是因为密钥仓库的拥有者相信证书中的公钥确实属于证书“主体”（拥有者）识别的身份。

证书签发人通过对证书签名来保证这点。

密钥仓库使用的别名

对所有的密钥仓库项（密钥项和可信任的证书项）的访问都要通过唯一的别名来进行。

别名不区分大小写，即别名Hugo和hugo指的是同一密钥仓库项。

当用-genkey命令来生成密钥对（公钥和私钥）或用-import命令来将证书或证书链加到可信任证书的清单中，以增加一个实体到密钥仓库中，必须指定了一个别名。

后续keytool命令必须使用这一相同的别名来引用该实体。

例如，假设您用别名duke生成了新的公钥/私钥密钥对并将公钥用以下命令打包到自签名证书中（参见证书链）：

keytool-genkey-aliasduke-keypassdukekeypasswd

这指定了一个初始口令“dukekeypasswd”，接下来的命令都要使用该口令才能访问与别名duke相关联的私钥。

以后如果您想更改duke的私钥口令，可用类似下述的命令：

keytool-keypasswd-aliasduke-keypassdukekeypasswd-newnewpass

这将把口令从“dukekeypasswd”改为“newpass”。

请注意：

实际上，除非是作为测试目的或是在安全的系统上，否则不应在命令行或脚本中指定口令。

如果没有在命令行上指定所要求的口令选项，您将会得到要求输入口令的提示。

当在口令提示符下键入口令时，口令将被即时显示出来（键入什么就显示什么），因此，要小心，不要当着任何人的面键入口令。

密钥仓库位置

每个keytool命令都有一个-keystore选项，用于指定keytool管理的密钥仓库的永久密钥仓库文件名称及其位置。

缺省情况下，密钥仓库储存在用户宿主目录（由系统属性的“user.home”决定）中名为.keystore的文件中。

在Solaris系统中“user.home”缺省为用户的宿主目录。

密钥仓库的创建

当用-genkey、-import或-identitydb命令向某个尚不存在的密钥仓库添加数据时，就创建了一个密钥仓库。

具体地说，如果在-keystore选项中指定了一个并不存在的密钥仓库，则该密钥仓库将被创建。

如果不指定-keystore选项，则缺省密钥仓库将是宿主目录中名为.keystore的文件。

如果该文件并不存在，则它将被创建。

密钥仓库实现

java.security包中提供的KeyStore类为访问和修改密钥仓库中的信息提供了相当固定的接口。

可以有多个不同的具体实现，其中每个实现都是对某个特定类型的密钥仓库的具体实现。

目前，有两个命令行工具（keytool和jarsigner）以及一个名为PolicyTool的基于GUI的工具使用密钥仓库实现。

由于密钥仓库是公用的，JDK用户可利用它来编写其它的安全性应用程序。

SunMicrosystems公司提供了一个内置的缺省实现。

它利用名为“JKS”的专用密钥仓库类型（格式），将密钥仓库实现为一个文件。

它用个人口令保护每个私钥，也用口令（可能为另一个口令）保护整个密钥仓库的完整性。

密钥仓库的实现基于提供者（provider）。

更具体地说，由密钥仓库所提供的应用程序接口是借助于“服务提供者接口”（SPI）来实现的。

也就是说，在java.security包中还有一个对应的抽象KeystoreSpi类，它定义了“提供者”必须实现的服务提供者接口方法。

（术语“提供者”指的是一个或一组包，这个或这组包提供了一部份可由Java安全API访问的服务子集的具体实现。

因此，要提供某个密钥仓库实现，客户机必须实现一个“提供者”并实现KeystoreSpi子类，如如何为Java加密体系结构实现Provider中所述。

通过使用KeyStore类中提供的“getInstance”工厂方法，应用程序可从不同的提供者中挑选不同类型的密钥仓库实现。

密钥仓库类型定义密钥仓库信息的存储和数据格式，以及用于保护密钥仓库中的私钥和密钥仓库自身完整性的算法。

不同类型的密钥仓库实现是不兼容的。

keytool使用基于文件的密钥仓库实现（它把在命令行中传递给它的密钥仓库位置当成文件名处理并将之转换为文件输入流，从该文件输入流中加载密钥仓库信息）。

另一方面，jarsigner和policytool工具可从任何可用URL指定的位置读取某个密钥仓库。

对于keytool和jarsigner，可在命令行用-storetype选项指定密钥仓库类型。

对于PolicyTool，可通过“编辑”菜单中的“更改密钥仓库”命令来指定密钥仓库类型。

如果没有明确指定一个密钥仓库类型，这些工具将只是根据安全属性文件中指定的keystore.type属性值来选择密钥仓库实现。

安全属性文件名为java.security，它位于JDK安全属性目录java.home/lib/security中，其中java.home为JDK的安装目录。

每个工具都先获取keystore.type的值，然后检查所有当前已安装的提供者直到找到一个实现所要求类型的密钥仓库的实现为止。

然后就使用该提供者的密钥仓库实现。

KeyStore类定义了一个名为getDefaultType的静态方法，它可让应用程序或applet检索keystore.type属性的值。

以下代码将创建缺省密钥仓库类型（此类型由keystore.type属性所指定。

）的一个实例：

KeyStorekeyStore=KeyStore.getInstance（KeyStore.getDefaultType（））;

缺省的密钥仓库类型是“jks”（这是由“SUN”提供者提供的密钥仓库实现的专用类型）。

它在安全性属性文件中由下行进行指定：

keystore.type=jks

要让工具使用不同于缺省类型的密钥仓库实现，可更改此行，指定不同的密钥仓库类型。

例如，如果您有一个这样的提供者包，它给出一个名为“pkcs12”的密钥仓库类型的密钥仓库实现，则可将上面那行改为：

keystore.type=pkcs12

注意：

密钥仓库类型的命名中大小写无关紧要。

例如，“JKS”将被认为是与“jks”相同的。

支持的算法和密钥大小

keytool允许用户指定任何注册了的加密服务提供者所提供的密钥对生成和签名算法。

也就是说，各种命令中的keyalg和sigalg选项必须得到提供者的实现的支持。

缺省的密钥对生成算法是“DSA”。

签名算法是从所涉及私钥的算法推导来的：

如果所涉及的私钥是“DSA”类型，则缺省的签名算法为“SHA1withDSA”，如果所涉及的私钥是“RSA”类型，则缺省的签名算法为“MD5withRSA”。

在生成DSA密钥对时，密钥大小的范围必须在512到1024位之间，且必须是64的倍数。

缺省的密钥大小为1024位。

证书

证书（也叫公钥证书）是来自某个实体（签发人）的经数字签名的声明，它声明另一实体（主体）的公钥（及其它信息）具有某一特定的值。

下面详细解释本句中使用的主要术语：

公钥

是与特定实体相关联的数字。

所有需要与该实体进行信任交互的人都应知道该数字。

公钥用于校验签名。

经数字签名

如果某些数据经数字签名，说明它们已与某一实体的“身份”存储在一起，而且证明该实体的签名知道这些数据。

通过用该实体的私钥进行绘制，这些数据就是不可伪造的了。

身份

用于声明实体的一种手段。

某些系统中，身份是公钥，而在另一些系统中则可以是UnixUID、电子邮件地址或X.509特征名等等。

签名

所谓签名，就是用实体的（签名人，在证书中也称为签发人）私钥对某些数据进行计算。

私钥

是一些数字，每个数字都应仅被以该数字作为私钥的特定实体所知（即该数字应保密）。

在所有公钥密码系统中，私钥和公钥均成对出现。

在DSA等具体的公钥密码系统中，一个私钥只对应一个公钥。

私钥用于计算签名。

实体

实体是您在某种程度上对其加以信任的个人、组织、程序、计算机、企业、银行等。

通常，公钥密码系统需要访问用户的公钥。

在大型联网环境中，并不能确保通信实体之间已经预先建立起关系，也无法确保受信任的储存库与所用的公钥都存在。

于是人们发明了证书作为公钥分配问题的解决办法。

现在，认证机构（CA）可充当可信任的第三方。

CA是可信任的向其它实体签名（发放）证书的实体（例如企业）。

由于CA受法律协议约束，因此可认为它们只提供可靠有效的证书。

公共认证机构数量很多，例如VeriSign、Thawte、Entrust等等。

您还可以使用诸如Netscape/MicrosoftCertificateServers或EntrustCA等产品来自己运营认证机构。

使用keytool可以显示、导入和导出证书。

还可以产生自签名证书。

keytool目前处理X.509证书。

X.509证书

X.509标准规定了证书可以包含什么信息，并说明了记录信息的方法（数据格式）。

除了签名外，所有X.509证书还包含以下数据：

版本

识别用于该证书的X.509标准的版本，该版本影响证书中所能指定的信息。

迄今为止，已定义的版本有三个。

keytool可导入和导出v1、v2和v3版的证书。

它只能生成v1版证书。

序列号

发放证书的实体有责任为证书指定序列号，以使其区别于该实体发放的其它证书。

此信息用途很多。

例如，如果某一证书被撤消，其序列号将放到证书撤消清单（CRL）中。

签名算法标识符

用于标识CA签名证书时所用的算法。

签发人名称

签名证书的实体的X.500特征名。

它通常为一个CA。

使用该证书意味着信任签名该证书的实体。

注意：

有些情况下（例如根或顶层CA证书），签发人会签名自己的证书。

有效期

每个证书均只能在一个有限的时间段内有效。

该有效期以起始日期和时间及终止日期和时间表示，可以短至几秒或长至一世纪。

所选有效期取决于许多因素，例如用于签名证书的私钥的使用频率及愿为证书支付的金钱等。

它是在没有危及相关私钥的条件下，实体可以依赖公钥值的预计时间。

主体名

证书可以识别其公钥的实体名。

此名称使用X.500标准，因此在Internet中应是唯一的。

它是实体的X.500特征名（DN），例如，

CN=JavaDuke,OU=JavaSoftwareDivision,O=SunMicrosystemsInc,C=US

（这些指主体的通用名、组织单位、组织和国家。

）

主体公钥信息

这是被命名实体的公钥，同时包括指定该密钥所属公钥密码系统的算法标识符及所有相关的密钥参数。

X.5091版1988年发布，已得到广泛使用，是最常用的版本。

X.5092版引入了主体和签发人唯一标识符的概念，以解决主体和/或签发人名称在一段时间后可能重复使用的问题。

大多数证书监视文档都极力建议不要重复使用主体或签发人名称，而且建议证书不要使用唯一标识符。

版本2证书尚未得到广泛使用。

X.5093版是最新的版本（1996年）。

它支持扩展的概念，因此任何人均可定义扩展并将其纳入证书中。

现在常用的扩展包括：

KeyUsage（仅限密钥用于特殊目的，例如“只签名”）和AlternativeNames（允许其它身份也与该公钥关联，例如DNS名、电子邮件地址、IP地址）。

扩展可标记为“极重要”，以表示该扩展应被检查并执行或使用。

例如，如果某一证书将KeyUsage扩展标记为“极重要”，而且设置为“keyCertSign”，则在SSL通讯期间该证书出现时将被拒绝，因为该证书扩展表示相关私钥应只用于签名证书，而不应该用于SSL。

证书中的所有数据均用两个名为ASN.1/DER的相关标准进行编码。

抽象语法注释1（AbstractSyntaxNotation1）描述数据。

确定性编码规则（DefiniteEncodingRules）描述储存和传输该数据的唯一方式。

X.500特征名

X.500特征名用于标识实体，例如X.509证书的主体和签发人（签名人）域所命名的实体。

keytool支持以下的子组件：

commonName-个人常用名，例如“SusanJones”

organizationUnit-小型组织（例如部门或分部）的名称，例如“Purchasing”

organizationName-大型组织的名称，例如“ABCSystems,Inc.”

localityName-地方（城市）名，例如“PaloAlto”

stateName-州或省份名，例如“California”

country-两个字母的国家代码，例如“CH”

当给出一个特征名字符串作为-dname选项的值时，例如-genkey或-selfcert命令中的该选项，字符串必须为以下格式：

CN=cName,OU=orgUnit,O=org,L=city,S=state,C=countryCode

其中所有的斜体字代表实际值而上面的关键字是以下缩写：

CN=commonName

OU=organizationUnit

O=organizationName

L=localityName

S=stateName

C=country

以下是特征名字符串样本：

CN=MarkSmith,OU=JavaSoft,O=Sun,L=Cupertino,S=California,C=US

以下是使用这一字符串的样本命令：

keytool-genkey-dname"CN=MarkSmith,OU=JavaSoft,O=Sun,L=Cupertino,

S=California,C=US"-aliasmark

大小写对关键字缩写无关紧要。

例如，“CN”、“cn”和“Cn”都将被当作是一样的。

但顺序是有关系的；每个子组件必须按设计好的顺序出现。

但是，不是所有子组件都必须有。

可以只用一部分，例如：

CN=SteveMeier,OU=SunSoft,O=Sun,C=US

如果特征名字符串的值含有逗号，当在命令行指定该字符串时，逗号必须用“\”字符来进行转义，如下所示：

cn=peterschuster,o=SunMicrosystems\,Inc.,o=sun,c=us

在命令行中指定特征名字符串是不必要的。

如果某一命令需要指定特征名字符串，而在命令行中又未提供，则用户将得到每个子组件的提示。

这种情况下，逗号不需要用“\”来转义。

InternetRFC1421证书编码标准

证书常用InternetRFC1421标准中定义的可打印的编码格式来存储，而不是用其二进制编码来存储。

这种证书格式，也称“Base64编码”，便于通过电子邮件或其它机制将证书导出到别的应用程序中。

用-import和-printcert命令读入的证书可以是这种格式的编码或是二进制格式的编码。

缺省情况下，-export命令将以二进制编码格式输出证书，但如果指定了-rfc选项，则将以可打印的编码格式输出证书。

缺省情况下，-list命令打印证书的MD5指纹。

而如果指定了-v选项，将以可读格式打印证书，如果指定了-rfc选项，将以可打印的编码格式输出证书。

在其可打印的编码格式中，已编码证书的起始行是：

-----BEGINCERTIFICATE-----

结束行是：

-----ENDCERTIFICATE-----

证书链

keytool可创建和管理密钥仓库的“密钥”项，每个密钥项都含有私钥和相关证书“链”。

链中的第一个证书含有与私钥对应的公钥。

当第一次产生密钥时（参见-genkey命令），链中只含有一个元素，即自签名证书。

自签名证书是一个这样的证书：

其签发人（签名人）与主体（证书所认证的公钥所属的实体）相同。

当调用-genkey命令来生成新的公钥/私钥对时，它同时也把公钥打包进自签名证书中。

之后，当证书签名请求（CSR）（参见-certreq命令）被生成并送至认证机构（CA）后，CA的答复将被导入（参见-import），证书链将取代自签名证书。

在链的底部是认证主体公钥的CA所发放的证书（答复）。

链中下一个证书是用于认证CA公钥的证书。

在许多情况下，这是个自签名证书（即来自认证其自身公钥的CA的证书）且是链中的最后一个证书。

在其它情况下，CA也许将返回证书链。

这种情况下，链中底部的证书是相同的（由CA签名的证书，对密钥项的公钥进行认证），但链中第二个证书是由不同的CA所签名的，对您向其发送CSR的CA的公钥进行认证。

然后，链中的下一个证书将是对第二个CA的公钥进行认证的证书，以此类推，直至到达自签名的“根”证书为止。

因此，链中的每个证书（从第一个以后）都对链中前一个证书的签名人的公钥进行认证。

许多CA只返回所发放的证书，而不支持链，特别是当层次结构较简单时（无中介CA）。

这种情况下，必须用储存在密钥仓库中的可信任的证书信息来建立证书链。

另一种答复格式（由PKCS#7标准所定义）除了包含所签发的证书外，还支持证书链。

两种答复格式都可由keytool处理。

顶层（根）CA证书是自签名的。

但是，对根公钥的信任并非来自根证书本身（任何人都可用特征名来产生自签名证书！

譬如说用VeriSign根CA的特征名）,而是来自报纸之类的其它来源。

根CA的公钥是广为人知的。

它被储存在证书中的唯一原因是因为这是大多数工具所能理解的格式，因此这种情况下的证书只是作为一种传输根CA的公钥用的“交通工具”。

在将根CA证书加到您的密钥仓库中之前，应该先对它进行查看（用-printcert选项）并将所显示的指纹与已知的指纹（从报纸、根CA的网页等中获取）进行比较。

导入证书

要从一个文件中导入某个证书，可用-import命令，如下所示：

keytool-import-aliasjoe-filejcertfile.cer

此样本命令导入文件jcertfile.cer中的证书并将其存储在由别名joe标识的密钥仓库项中。

导入证书的两个理由如下：

为将其添加到可信任的证书清单中，或

为导入因向CA提交证书签名请求（参见-certreq命令）而收到的来自该CA的认证答复。

-alias选项的值指明要进行何种类型的导入。

如果数据库中存在别名，且该别名标识具有私钥的项，则将假定您要导入认证答复。

keytool将检查认证答复中的公钥是否与用别名储存的私钥相匹配，如果两者不同，则程序退出。

如果别名标识另一种类型的密钥仓库项，则不导入该证书。

如果该别名不存在，则它将被创建并与导入的证书关联。

有关导入可信任证书的警告

重要：

将证书作为可信任的证书导入之前，请务必先仔细检查该证书！

先查看一下（用-printcert命令，或用不带-noprompt选项的-import命令），确保所显示的证书指纹与所预计的相匹配。

例如，假设某人给您送来或用电子邮件发来一个证书，您将它放在名为/tmp/cert的文件中。

在将它加到可信任证书的清单中之前，可通过执行-printcert命令来查看它的指纹，如下所示：

keytool-printcert-file/tmp/cert

Owner:

CN=ll,OU=ll,O=ll,L=ll,S=ll,C=ll

Issuer:

CN=ll,OU=ll,O=ll,L=ll,S=ll,C=ll

SerialNumber:

59092b34

Validfrom:

ThuSep2518:

01:

13PDT1997until:

WedDec2417:

01:

13PST1997

CertificateFingerprints:

MD5：

11:

81:

AD:

92:

C8:

E5:

0E:

A2:

01:

2E:

D4:

7A:

D7:

5F:

07:

6F

SHA1:

20:

B6:

17:

FA:

EF:

E5:

55:

8A:

D0:

71:

1F:

E8:

D6:

9D:

C0:

37:

13:

0E:

5E:

FE

然后给向您发送证书的人打电话或用其它方式联系，将您将您所看到的指纹与他们所提供的比较。

只有两者相等才可保证证书在传送途中没有被其它人（例如，攻击者）的证书所更换。

如果发生了这样的攻击，而您未检查证书即将其导入，您就会信任攻击者所签名的任何