杂谈X509证书, Java Keystore与Jetty

很多人对JSSE组成部分的Key Tool 工具不太明白，希望本文能有帮助

科班出身的同学应该学过课程“密码学”， 这门课详细解释了现代对称加密的算法原理， 当时学的我云里雾里。 直到现在使用过SSL加密才知道工程上用法是这样的， 老师讲的时候就不能带一点工程实践吗？ 简单来说，对称加密体系就是我有一段需要加密的字符， 我用私钥加密之后变成了无意义的密文， 只有用配对的公钥才能对这个密文进行解密还原回来。

下图是个简单的示意，注意由于公私钥是配对的，一般给信息加密的人持有此密钥对。

这套机制可以应用在网络上电子商务常用的可信任站点的证书 验证上，因为电子商务站点经常涉及到交易，所以客户需要知道这个电子商务网站是真的，可信任的， 而不是一个一摸一样的伪造网站，来钓鱼骗你账户和密码的。

简单说一下这个证书验证的过程：

1. 点击一个https的网站
2. 浏览器开始建立ssl连接
3. 浏览器请求该网站证书，该证书主要包含了公钥，及网站用私钥加密证书内容后的签名数据
4. 浏览器用公钥解密签名数据，验证该证书完整性
5. 浏览器根据签名者的名字验证证书链，反复进行直到匹配到了浏览器内自带的可信任根CA机构

为了更直观点, 以下是用java程序取出来的Google的证书，主要的内容包括：

版本(Version)，主题(Subject)，签名算法(Signature Algorithm)，有效日期(Validity)，认证机构(Issuer)，序列号(SerialNumber),公钥信息(Key)

[
[
  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。