捕風(fēng)之巢

openssl簡介（二）－－證書

?

一.???? 證書

證書就是數(shù)字化的文件，里面有一個實體 ( 網(wǎng)站，個人等 ) 的公共密鑰和其他的屬性，如名稱等。該公共密鑰只屬于某一個特定的實體，它的作用是防止一個實體假裝成另外一個實體。

證書用來保證不對稱加密算法的合理性。想想吧，如果沒有證書記錄，那么假設(shè)某倆人 A 與 B 的通話過程如下：

這里假設(shè) A 的 publickey 是 K1,privatekey 是 K2 ， B 的 publickey 是 K3,privatekey 是 K4

xxxxxx(kn) 表示用 kn 加密過的一段文字 xxxxxx

A----- 〉 hello(plaintext)------------- 〉 B
A 〈 ---------hello(plaintext) 〈 ---------B
A 〈 ---------Bspublickey 〈 ------------B
A--------- 〉 spublickey(K1)-------- 〉 B
......

如果 C 想假裝成 B, 那么步驟就和上面一樣。
A----- 〉 hello(plaintext)------------- 〉 C
A 〈 ---------hello(plaintext) 〈 ---------C

注意下一步，因為 A 沒有懷疑 C 的身份，所以他理所當(dāng)然的接受了 C 的 publickey, 并且使用這個 key 來繼續(xù)下面的通信。

A 〈 ---------Cspublickey 〈 ------------C
A--------- 〉 Aspublickey(K1)-------- 〉 C
......

這樣的情況下 A 是沒有辦法發(fā)覺 C 是假的。如果 A 在通話過程中要求取得 B 的證書，并且驗證證書里面記錄的名字，如果名字和 B 的名字不符合，就可以發(fā)現(xiàn)對方不是 B. 驗證 B 的名字通過再從證書里面提取 B 的公用密鑰，繼續(xù)通信過程。

那么，如果證書是假的怎么辦？或者證書被修改過了怎么辦？慢慢看下來吧。

證書最簡單的形式就是只包含有證書擁有者的名字和公用密鑰。當(dāng)然現(xiàn)在用的證書沒這么簡單，里面至少還有證書過期的 deadline, 頒發(fā)證書的機構(gòu)名稱， 證書系列號，和一些其他可選的信息。最重要的是，它包含了證書頒發(fā)機構(gòu) (certificationauthority 簡稱 CA) 的簽名信息。

我們現(xiàn)在常用的證書是采用 X.509 結(jié)構(gòu)的，這是一個國際標(biāo)準(zhǔn)證書結(jié)構(gòu)。任何遵循該標(biāo)準(zhǔn)的應(yīng)用程序都可以讀，寫 X509 結(jié)構(gòu)的證書。

通過檢查證書里面的 CA 的名字，和 CA 的簽名，就知道這個證書的確是由該 CA 簽發(fā)的然后，你就可以簡單證書里面的接收證書者的名字，然后提取公共密鑰。這樣做建立的基礎(chǔ)是，你信任該 CA, 認(rèn)為該 CA 沒有頒發(fā)錯誤的證書。

CA 是第三方機構(gòu)，被你信任，由它保證證書的確發(fā)給了應(yīng)該得到該證書的人。 CA 自己有一個龐大的 publickey 數(shù)據(jù)庫，用來頒發(fā)給不同的實體。

這里有必要解釋一下， CA 也是一個實體，它也有自己的公共密鑰和私有密鑰，否則怎么做數(shù)字簽名？它也有自己的證書，你可以去它的站點 down 它的證書得到它的公共密鑰。

一般 CA 的證書都內(nèi)嵌在應(yīng)用程序中間。不信你打開你的 IE, 在 internet 選項里面選中 " 內(nèi)容 ", 點擊 " 證書 ", 看看那個 " 中間證書發(fā)行機構(gòu) " 和 " 委托根目錄發(fā)行機構(gòu) ", 是不是有一大堆 CA 的名稱？也有時 CA 的證書放在安全的數(shù)據(jù)庫里面。

當(dāng)你接受到對方的證書的時候，你首先會去看該證書的 CA, 然后去查找自己的 CA 證書數(shù)據(jù)庫，看看是否找的到，找不到就表示自己不信任該 CA, 那么就告吹本次連接。找到了的話就用該 CA 的證書里面的公用密鑰去檢查 CA 在證書上的簽名。

這里又有個連環(huán)的問題，我怎么知道那個 CA 的證書是屬于那個 CA 的？人家不能造假嗎？

解釋一下吧。 CA 也是分級別的。最高級別的 CA 叫 RootCAs, 其他 cheap 一點的 CA 的證書由他們來頒發(fā)和簽名。這樣的話，最后的保證就是：我們信任 RootCAs. 那些有 RootCAs 簽名過的證書的 CA 就可以來頒發(fā)證書給實體或者其他 CA 了。

你不信任 RootCAs? 人民幣由中國人民銀行發(fā)行，運到各個大銀行，再運到地方銀行，你從地方銀行取人民幣的時候不信任發(fā)行它的中國人民銀行嗎？ RootCAs 都是很權(quán)威的機構(gòu)，沒有必要擔(dān)心他們的信用。

那 RootCAs 誰給簽名 ? 他們自己給自己簽名 , 叫自簽名 .

說了這么多，舉個 certificate 的例子吧 , 對一些必要的 item 解釋一下。

CertificateExample
Certificate:
Data:
Version:1(0x0)
SerialNumber:// 系列號
02:41:00:00:16
SignatureAlgorithm:md2WithRSAEncryption//CA 同志的數(shù)字簽名的算法
Issuer:C=US,O=RSADataSecurity,Inc.,OU=Commercial//CA 自報家門
Certification
Authority
Validity
NotBefore:Nov418:58:341994GMT// 證書的有效期
NotAfter:Nov318:58:341999GMT
Subject:C=US,O=RSADataSecurity,Inc.,OU=Commercial
CertificationAuthority
SubjectPublicKeyInfo:
PublicKeyAlgorithm:rsaEncryption
RSAPublicKey1000bit)
Modulus(1000bit):
00:a4:fb:81:62:7b:ce:10:27:dd:e8:f7:be:6c:6e:
c6:70:99:db:b8:d5:05:03:69:28:82:9c:72:7f:96:
3f:8e:ec:ac:29:92:3f:8a:14:f8:42:76:be:bd:5d:
03:b9:90:d4:d0:bc:06:b2:51:33:5f:c4:c2:bf:b6:
8b:8f:99:b6:62:22:60:dd:db:df:20:82:b4:ca:a2:
2f:2d:50:ed:94:32:de:e0:55:8d:d4:68:e2:e0:4c:
d2:cd:05:16:2e:95:66:5c:61:52:38:1e:51:a8:82:
a1:c4:ef:25:e9:0a:e6:8b:2b:8e:31:66:d9:f8:d9:
fd:bd:3b:69:d9:eb
Exponent:65537(0x10001)
SignatureAlgorithm:md2WithRSAEncryption
76:b5:b6:10:fe:23:f7:f7:59:62:4b:b0:5f:9c:c1:68:bc:49:
bb:b3:49:6f:21:47:5d:2b:9d:54:c4:00:28:3f:98:b9:f2:8a:
83:9b:60:7f:eb:50:c7:ab:05:10:2d:3d:ed:38:02:c1:a5:48:
d2:fe:65:a0:c0:bc:ea:a6:23:16:66:6c:1b:24:a9:f3:ec:79:
35:18:4f:26:c8:e3:af:50:4a:c7:a7:31:6b:d0:7c:18:9d:50:
bf:a9:26:fa:26:2b:46:9c:14:a9:bb:5b:30:98:42:28:b5:4b:
53:bb:43:09:92:40:ba:a8:aa:5a:a4:c6:b6:8b:57:4d:c5

其實這是我們看的懂的格式的證書內(nèi)容，真正的證書都是加密過了的，如下：

-----BEGINCERTIFICATE-----

MIIDcTCCAtqgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBiDELMAkGA1UEBhMCQ0gx

EjAQBgNVBAgTCWd1YW5nZG9uZzESMBAGA1UEBxMJZ3Vhbmd6aG91MREwDwYDVQQK

Ewhhc2lhaW5mbzELMAkGA1UECxMCc3cxDjAMBgNVBAMTBWhlbnJ5MSEwHwYJKoZI

hvcNAQkBFhJmb3JkZXNpZ25AMjFjbi5jb20wHhcNMDAwODMwMDc0MTU1WhcNMDEw

ODMwMDc0MTU1WjCBiDELMAkGA1UEBhMCQ0gxEjAQBgNVBAgTCWd1YW5nZG9uZzES

MBAGA1UEBxMJZ3Vhbmd6aG91MREwDwYDVQQKEwhhc2lhaW5mbzELMAkGA1UECxMC

c3cxDjAMBgNVBAMTBWhlbnJ5MSEwHwYJKoZIhvcNAQkBFhJmb3JkZXNpZ25AMjFj

bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMDYArTAhLIFacYZwP30

Zu63mAkgpAjVHaIsIEJ6wySIZl2THEHjJ0kS3i8lyMqcl7dUFcAXlLYi2+rdktoG

jBQMOtOHv1/cmo0vzuf38+NrAZSZT9ZweJfIlp8W9uyz8Dv5hekQgXFg/l3L+HSx

wNvQalaOEw2nyf45/np/QhNpAgMBAAGjgegwgeUwHQYDVR0OBBYEFKBL7xGeHQSm

ICH5wBrOiqNFiildMIG1BgNVHSMEga0wgaqAFKBL7xGeHQSmICH5wBrOiqNFiild

oYGOpIGLMIGIMQswCQYDVQQGEwJDSDESMBAGA1UECBMJZ3Vhbmdkb25nMRIwEAYD

VQQHEwlndWFuZ3pob3UxETAPBgNVBAoTCGFzaWFpbmZvMQswCQYDVQQLEwJzdzEO

MAwGA1UEAxMFaGVucnkxITAfBgkqhkiG9w0BCQEWEmZvcmRlc2lnbkAyMWNuLmNv

bYIBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAGQa9HK2mixM7ML7

0jZr1QJUHrBoabX2AbDchb4Lt3qAgPOktTc3F+K7NgB3WSVbdqC9r3YpS23RexU1

aFcHihDn73s+PfhVjpT8arC1RQDg9bDPvUUYphdQC0U+HF72/CvxGCTqpnWiqsgw

xqeog0A8H3doDrffw8Zb7408+Iqf

-----ENDCERTIFICATE-----



證書都是有壽命的。就是上面的那個 NotBefore 和 NotAfter 之間的日子。過期的證書，如果沒有特殊原因，都要擺在證書回收列 (certificaterevocationlist) 里面 . 證書回收列，英文縮寫是 CRL. 比如一個證書的 key 已經(jīng)被破了，或者證書擁有者沒有權(quán)力 再使用該證書，該證書就要考慮作廢。 CRL 詳細(xì)記錄了所有作廢的證書。

CRL 的缺省格式是 PEM 格式。當(dāng)然也可以輸出成我們可以讀的文本格式。下面有個 CRL 的例子。

-----BEGINX509CRL-----

MIICjTCCAfowDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxIDAeBgNVBAoT

F1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVTZWN1cmUgU2VydmVy

IENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw05NTA1MDIwMjEyMjZaFw05NTA2MDEw

MDAxNDlaMIIBaDAWAgUCQQAABBcNOTUwMjAxMTcyNDI2WjAWAgUCQQAACRcNOTUw

MjEwMDIxNjM5WjAWAgUCQQAADxcNOTUwMjI0MDAxMjQ5WjAWAgUCQQAADBcNOTUw

MjI1MDA0NjQ0WjAWAgUCQQAAGxcNOTUwMzEzMTg0MDQ5WjAWAgUCQQAAFhcNOTUw

MzE1MTkxNjU0WjAWAgUCQQAAGhcNOTUwMzE1MTk0MDQxWjAWAgUCQQAAHxcNOTUw

MzI0MTk0NDMzWjAWAgUCcgAABRcNOTUwMzI5MjAwNzExWjAWAgUCcgAAERcNOTUw

MzMwMDIzNDI2WjAWAgUCQQAAIBcNOTUwNDA3MDExMzIxWjAWAgUCcgAAHhcNOTUw

NDA4MDAwMjU5WjAWAgUCcgAAQRcNOTUwNDI4MTcxNzI0WjAWAgUCcgAAOBcNOTUw

NDI4MTcyNzIxWjAWAgUCcgAATBcNOTUwNTAyMDIxMjI2WjANBgkqhkiG9w0BAQIF

AAN+AHqOEJXSDejYy0UwxxrH/9+N2z5xu/if0J6qQmK92W0hW158wpJg+ovV3+wQ

wvIEPRL2rocL0tKfAsVq1IawSJzSNgxG0lrcla3MrJBnZ4GaZDu4FutZh72MR3Gt

JaAL3iTJHJD55kK2D/VoyY1djlsPuNh6AEgdVwFAyp0v

-----ENDX509CRL-----

下面是文本格式的 CRL 的例子。

ThefollowingisanexampleofaCRLintextformat:

issuer=/C=US/O=RSADataSecurity,Inc./OU=SecureServerCertification

Authority

lastUpdate=May202:12:261995GMT

nextUpdate=Jun100:01:491995GMT

revoked:serialNumber=027200004CrevocationDate=May202:12:261995GMT

revoked:serialNumber=0272000038revocationDate=Apr2817:27:211995GMT

revoked:serialNumber=0272000041revocationDate=Apr2817:17:241995GMT

revoked:serialNumber=027200001ErevocationDate=Apr800:02:591995GMT

revoked:serialNumber=0241000020revocationDate=Apr701:13:211995GMT

revoked:serialNumber=0272000011revocationDate=Mar3002:34:261995GMT

revoked:serialNumber=0272000005revocationDate=Mar2920:07:111995GMT

revoked:serialNumber=024100001FrevocationDate=Mar2419:44:331995GMT

revoked:serialNumber=024100001ArevocationDate=Mar1519:40:411995GMT

revoked:serialNumber=0241000016revocationDate=Mar1519:16:541995GMT

revoked:serialNumber=024100001BrevocationDate=Mar1318:40:491995GMT

revoked:serialNumber=024100000CrevocationDate=Feb2500:46:441995GMT

revoked:serialNumber=024100000FrevocationDate=Feb2400:12:491995GMT

revoked:serialNumber=0241000009revocationDate=Feb1002:16:391995GMT

revoked:serialNumber=0241000004revocationDate=Feb117:24:261995GMT

總結(jié)一下 X.509 證書是個什么東東吧。它實際上是建立了公共密鑰和某個實體之間聯(lián)系的數(shù)字化的文件。它包含的內(nèi)容有：

版本信息 ,X.509 也是有三個版本的。

系列號
證書接受者名稱
頒發(fā)者名稱
證書有效期
公共密鑰
一大堆的可選的其他信息
CA 的數(shù)字簽名

證書由 CA 頒發(fā)，由 CA 決定該證書的有效期，由該 CA 簽名。每個證書都有唯一的系列號。證書的系列號和證書頒發(fā)者來決定某證書的唯一身份。

openssl 有四個驗證證書的模式。你還可以指定一個 callback 函數(shù)，在驗證證書的時候會自動調(diào)用該 callback 函數(shù)。這樣可以自己根據(jù)驗證結(jié)果來決定應(yīng)用程序的行為。具體的東西在以后的章節(jié)會詳細(xì)介紹的。

openssl 的四個驗證證書模式分別是：

SSL_VERIFY_NONE: 完全忽略驗證證書的結(jié)果。當(dāng)你覺得握手必須完成的話，就選用這個選項。其實真正有證書的人很少 , 尤其在中國。那么如果 SSL 運用于一些免費的服務(wù)，比如 email 的時候，我覺得 server 端最好采用這個模式。

SSL_VERIFY_PEER: 希望驗證對方的證書。不用說這個是最一般的模式了 . 對 client 來說，如果設(shè)置了這樣的模式，驗證 server 的證書 出了任何錯誤， SSL 握手都告吹 . 對 server 來說 , 如果設(shè)置了這樣的模式 ,client 倒不一定要把自己的證書交出去。如果 client 沒有交出證 書， server 自己決定下一步怎么做。

SSL_VERIFY_FAIL_IF_NO_PEER_CERT: 這是 server 使用的一種模式，在這種模式下， server 會向 client 要證書。如果 client 不給， SSL 握手告吹。

SSL_VERIFY_CLIENT_ONCE ：這是僅能使用在 sslsessionrenegotiation 階段的一種方式。什么是 SSLsessionrenegotiation? 以后的章節(jié)再解釋。我英文差點，覺得這個詞組也很難翻譯成相應(yīng)的中文。以后的文章里，我覺得很難直接翻 譯的單詞或詞組，都會直接用英文寫出來。如果不是用這個模式的話 , 那么在 regegotiation 的時候， client 都要把自己的證書送給 server, 然后做一番分析。這個過程很消耗 cpu 時間的，而這個模式則不需要 client 在 regotiation 的時候重復(fù)送自己的證書了。

posted on 2006-10-17 15:20 捕風(fēng) 閱讀(587) 評論(0)  編輯  收藏 所屬分類: java安全