很多人对JSSE组成部分的Key Tool 工具不太明白，希望本文能有帮助
科班出身的同学应该学过课程“密码学”， 这门课详细解释了现代对称加密的算法原理， 当时学的我云里雾里。 直到现在使用过SSL加密才知道工程上用法是这样的， 老师讲的时候就不能带一点工程实践吗？ 简单来说，对称加密体系就是我有一段需要加密的字符， 我用私钥加密之后变成了无意义的密文， 只有用配对的公钥才能对这个密文进行解密还原回来。
下图是个简单的示意，注意由于公私钥是配对的，一般给信息加密的人持有此密钥对。
这套机制可以应用在网络上电子商务常用的可信任站点的证书 验证上，因为电子商务站点经常涉及到交易，所以客户需要知道这个电子商务网站是真的，可信任的， 而不是一个一摸一样的伪造网站，来钓鱼骗你账户和密码的。
简单说一下这个证书验证的过程：
- 点击一个https的网站
- 浏览器开始建立ssl连接
- 浏览器请求该网站证书，该证书主要包含了公钥，及网站用私钥加密证书内容后的签名数据
- 浏览器用公钥解密签名数据，验证该证书完整性
- 浏览器根据签名者的名字验证证书链，反复进行直到匹配到了浏览器内自带的可信任根CA机构
为了更直观点, 以下是用java程序取出来的Google的证书，主要的内容包括：
版本(Version)，主题(Subject)，签名算法(Signature Algorithm)，有效日期(Validity)，认证机构(Issuer)，序列号(SerialNumber),公钥信息(Key)
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
[
[
Version: V3
Subject: CN=www.google.com, O=Google Inc, L=Mountain View, ST=California, C=US
Signature Algorithm: SHA1withRSA, OID =
1.2
.
840.113549
.
1.1
.
5
Key: Sun RSA
public
key,
2048
bits
modulus:
21234013066307499395457251007591480564049457586531682634102688105320414778844675214782297227108785101225473929899552731501456168053582903590770359069026387607503146650068399613049641154687616403518890644657095548686866113952705014503928651307072537712940705497213473591529858208623561782445051685850298532560404133534066309955969883121384862800482489711770827176592928627367189401567119209235611091403472756628910838905587679781334745044724147912894428457975079919303874339456674143408932927112368761924943362190459243823969871830702191962312600960355323190050761278795233954274164962425829947843114462063705745562381
public
exponent:
65537
Validity: [From: Wed Jul
02
21
:
38
:
55
CST
2014
,
To: Tue Sep
30
08
:
00
:
00
CST
2014
]
Issuer: CN=Google Internet Authority G2, O=Google Inc, C=US
SerialNumber: [ 5b7fd907 7ce7148c]
Certificate Extensions:
8
[
1
]: ObjectId:
1.3
.
6.1
.
5.5
.
7.1
.
1
Criticality=
false
AuthorityInfoAccess [
[
accessMethod: caIssuers
accessLocation: URIName: http:
//pki.google.com/GIAG2.crt
,
accessMethod: ocsp
accessLocation: URIName: http:
//clients1.google.com/ocsp
]
]
[
2
]: ObjectId:
2.5
.
29.35
Criticality=
false
AuthorityKeyIdentifier [
KeyIdentifier [
0000
: 4A DD
06
16
1B BC F6
68
B5
76
F5
81
B6 BB
62
1A J......h.v....b.
0010
: BA 5A
81
2F .Z./
]
]
[
3
]: ObjectId:
2.5
.
29.19
Criticality=
true
BasicConstraints:[
CA:
false
PathLen: undefined
]
[
4
]: ObjectId:
2.5
.
29.31
Criticality=
false
CRLDistributionPoints [
[DistributionPoint:
[URIName: http:
//pki.google.com/GIAG2.crl]
]]
[
5
]: ObjectId:
2.5
.
29.32
Criticality=
false
CertificatePolicies [
[CertificatePolicyId: [
1.3
.
6.1
.
4.1
.
11129.2
.
5.1
]
[] ]
]
[
6
]: ObjectId:
2.5
.
29.37
Criticality=
false
ExtendedKeyUsages [
serverAuth
clientAuth
]
[
7
]: ObjectId:
2.5
.
29.17
Criticality=
false
SubjectAlternativeName [
DNSName: www.google.com
]
[
8
]: ObjectId:
2.5
.
29.14
Criticality=
false
SubjectKeyIdentifier [
KeyIdentifier [
0000
:
79
DF 1E A5 4C
46
0D
45
EE
18
41
68
F0
83
CA 4F y...LF.E..Ah...O
0010
: C7 2C B4 C2 .,..
]
]
]
Algorithm: [SHA1withRSA]
Signature:
0000
: 7E B3
33
11
DC
10
16
C2
99
A0
53
BD
24
03
4D
79
..
3
.......S.$.My
0010
:
92
A5
15
61
F1 4E C6 F6 C5
10
BB D0 8D
70
F6
53
...a.N.......p.S
0020
: AA FE
25
EA
33
39
2F 9C DA C2
69
94
A4
34
1D
57
..%.
39
/...i..
4
.W
0030
: A7 E4 D5
75
94
03
8B
61
86
2A A6
82
FA C9
43
37
...u...a.*....C7
0040
:
28
28
F6 3F 0E DA
88
42
74
2E
79
0C 3E D1 4E 2A ((.?...Bt.y.>.N*
0050
: C7
25
D7 E1
44
1A
30
D1 C6
33
F4 E4 4E 5E B7
78
.%..D.
0
..
3
..N^.x
0060
: C3 1D C2 BE
47
0E 3D D3 CF
09
74
5C 7F
84
C8
55
....G.=...t\...U
0070
: EA B0
00
A2 7B CA D2 7A B3
03
1D
22
AB
64
D1 F6 .......z...".d..
0080
:
78
5F
16
D2
54
7D
48
9A 6B
27
FD 2F BD
00
1F 0A x_..T.H.k'./....
0090
: A8
00
7B CF 7B B8 F0
32
7A
25
1E 6A 6B B2 A1
69
.......2z%.jk..i
00A0:
62
1B B6 C0 6D
52
6A D8 C6 C8 C3
68
C8
28
D5
75
b...mRj....h.(.u
00B0:
66
C9
66
12
CB A5 0F
68
39
3D D5
32
90
ED
13
5B f.f....h9=.
2
...[
00C0: C8 5A
89
EB FA
74
B7 F7 EC FB AB A2 8C
84
BF
75
.Z...t.........u
00D0: 2A D0
23
36
DD 5B C3 1A DB D9
06
94
C0
23
BC
44
*.#
6
.[.......#.D
00E0: F2 F3 9A B0 FB
85
1D F0
48
25
2A 3B B9 9B
02
DE ........H%*;....
00F0: 4B
17
4F
63
7A
66
0F 7E 3B
03
31
81
86
AA
57
5D K.Oczf..;.
1
...W]
]
|
关于这些信息的更详细解释可以看规范RFC3280 , http://www.ietf.org/rfc/rfc3280.txt ,这里就不扯得太远了。上面的信息跟下面规范里的信息是一一对应的
Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL, -- If present, version MUST be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL -- If present, version MUST be v3 }
操作系统在出厂的时候已经预装了CA的可信任证书，浏览器在通过证书拿到证书链后，最终都会追溯到一个根路径与操作系统自带的出厂CA可信证书进行比对，如果成功了证明是可信任的证书。Chrome在windows系统下直接用windows系统自带root证书进行验证， 而Firefox则自己带了一套可信证书，不与操作系统共用。
经过上面的解释，大家直到JDK为什么要弄一个keytool工具了， 这个工具就是用来生成key store文件的，这个文件保存了两种entry，一种是公私钥对(key entries)， 一种是公钥证书(trusted certificate entries)， 前者由于涉及到私钥，保密要求更高。 key store 文件保存了java版的可信任证书，Java 的SSL客户端要进行SSL握手时需要从对方证书的签名者追溯到自己的可信任机构， 就是跟此文件中保存的CA证书进行比对。
下面语句可以建一个keystore 并且生成一个公私钥对，并把公钥生成为公钥证书：
keytool -genkey -alias duke -keypass dukekeypasswd
导入证书语句如下：
keytool -import -alias abc -file ABCCA.cer
Java程序在SSL连接建立相关操作时都需要操作这个key store文件，来取得自己的私钥或者拿自己信任的证书，简单流程如下：
以上讲的是客户端的流程，下面看一下Java的web服务器Jetty的一些这方面的设置，同样，Jetty也需要一个这个文件，就保存在Jetty目录的/etc/keystore中。
再看下Jetty 9 的ssl配置文件Jetty-ssl.xml:
<Configure id="sslContextFactory" class="org.eclipse.jetty.util.ssl.SslContextFactory">
<Set name="KeyStorePath"><Property name="jetty.home" default="." />/<Property name="jetty.keystore" default="etc/keystore"/></Set>
<Set name="KeyStorePassword"><Property name="jetty.keystore.password" default="OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4"/></Set>
<Set name="KeyManagerPassword"><Property name="jetty.keymanager.password" default="OBF:1u2u1wml1z7s1z7a1wnl1u2g"/></Set>
<Set name="TrustStorePath"><Property name="jetty.home" default="." />/<Property name="jetty.truststore" default="etc/keystore"/></Set>
<Set name="TrustStorePassword"><Property name="jetty.truststore.password" default="OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4"/></Set>
<Set name="EndpointIdentificationAlgorithm"></Set>
明确指明了keystore和truststore文件的路径，其实就是同一个名为keystore的文件， 并指明了密码，下面我们用他的密码看一下keystore中保存了什么，但Jetty的这个密码如果是OBF开头的则说明密码被混淆过，运行
target git:(master) java -cp jetty-util-9.2.2-SNAPSHOT.jar org.eclipse.jetty.util.security.Password OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4 2014-07-17 21:08:19.241:INFO::main: Logging initialized @57ms storepwd OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4 MD5:841aa4ca19e9fe3010369a60781c7630
得到这个keystore的实际明文密码 storepwd，然后到jetty/etc目录下查看Jetty的keystore文件中都存了什么证书：
keytool -list -keystore keystore -storepass storepwd -v
etc git:(master) keytool -list -keystore keystore -storepass storepwd -v 密钥库类型: JKS 密钥库提供方: SUN 您的密钥库包含 1 个条目 别名: jetty 创建日期: 2008-11-7 条目类型: PrivateKeyEntry 证书链长度: 1 证书[1]: 所有者: CN=jetty.mortbay.org, OU=Jetty, O=Mort Bay Consulting Pty Ltd, L=Unknown, ST=Unknown, C=Unknown 发布者: CN=jetty.mortbay.org, OU=Jetty, O=Mort Bay Consulting Pty Ltd, L=Unknown, ST=Unknown, C=Unknown 序列号: 4913c3f4 有效期开始日期: Fri Nov 07 12:28:36 CST 2008, 截止日期: Tue Mar 25 12:28:36 CST 2036 证书指纹: MD5: 59:80:DB:FA:2F:9D:5C:87:88:1B:9A:9F:BF:FA:DE:92 SHA1: 66:62:5A:2B:2F:96:E1:88:E7:27:19:E0:0E:C6:60:B0:FC:86:B2:64 SHA256: 3D:75:8E:56:77:42:01:C7:D3:C3:E9:DF:8C:1B:21:03:19:70:78:A9:27:9E:F1:E4:78:B9:73:F5:F6:CA:EF:C2 签名算法名称: MD5withRSA 版本: 1 ******************************************* *******************************************
Jetty 9的 中，部分组装SSLConext的代码如下：
KeyStore keyStore = loadKeyStore(); KeyStore trustStore = loadTrustStore(); KeyManager[] keyManagers = getKeyManagers(keyStore); TrustManager[] trustManagers = getTrustManagers(trustStore,crls); SecureRandom secureRandom = (_secureRandomAlgorithm == null)?null:SecureRandom.getInstance(_secureRandomAlgorithm); SSLContext context = _sslProvider == null ? SSLContext.getInstance(_sslProtocol) : SSLContext.getInstance(_sslProtocol,_sslProvider); context.init(keyManagers,trustManagers,secureRandom); _context = context; //组装好context //下面是用context组装SSLServerSocketFactory SSLServerSocketFactory factory = _context.getServerSocketFactory(); SSLServerSocket socket = (SSLServerSocket) (host==null ? factory.createServerSocket(port,backlog): factory.createServerSocket(port,backlog,InetAddress.getByName(host))); if (getWantClientAuth()) socket.setWantClientAuth(getWantClientAuth()); if (getNeedClientAuth()) socket.setNeedClientAuth(getNeedClientAuth()); socket.setEnabledCipherSuites(selectCipherSuites( socket.getEnabledCipherSuites(), socket.getSupportedCipherSuites())); socket.setEnabledProtocols(selectProtocols(socket.getEnabledProtocols(),socket.getSupportedProtocols()));
return socket;
SSLContext构建需要keyManager 和trustManager，Manager来自 keystore文件中保存的Entries。
