文章出處

很多人對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。


文章列表


不含病毒。www.avast.com
arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()