openssl簡介(二)--證書
一.????
證書
證書用來保證不對稱加密算法的合理性。想想吧,如果沒有證書記錄,那么假設某倆人 A 與 B 的通話過程如下:
這里假設 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 的身份,所以他理所當然的接受了 C 的 publickey, 并且使用這個 key 來繼續下面的通信。
A 〈 ---------Cspublickey 〈 ------------C
A--------- 〉 Aspublickey(K1)-------- 〉 C
......
這樣的情況下 A 是沒有辦法發覺 C 是假的。如果 A 在通話過程中要求取得 B 的證書,并且驗證證書里面記錄的名字,如果名字和 B 的名字不符合,就可以發現對方不是 B. 驗證 B 的名字通過再從證書里面提取 B 的公用密鑰,繼續通信過程。
那么,如果證書是假的怎么辦?或者證書被修改過了怎么辦?慢慢看下來吧。
證書最簡單的形式就是只包含有證書擁有者的名字和公用密鑰。當然現在用的證書沒這么簡單,里面至少還有證書過期的 deadline, 頒發證書的機構名稱, 證書系列號,和一些其他可選的信息。最重要的是,它包含了證書頒發機構 (certificationauthority 簡稱 CA) 的簽名信息。
我們現在常用的證書是采用 X.509 結構的,這是一個國際標準證書結構。任何遵循該標準的應用程序都可以讀,寫 X509 結構的證書。
通過檢查證書里面的 CA 的名字,和 CA 的簽名,就知道這個證書的確是由該 CA 簽發的然后,你就可以簡單證書里面的接收證書者的名字,然后提取公共密鑰。這樣做建立的基礎是,你信任該 CA, 認為該 CA 沒有頒發錯誤的證書。
CA 是第三方機構,被你信任,由它保證證書的確發給了應該得到該證書的人。 CA 自己有一個龐大的 publickey 數據庫,用來頒發給不同的實體。
這里有必要解釋一下, CA 也是一個實體,它也有自己的公共密鑰和私有密鑰,否則怎么做數字簽名?它也有自己的證書,你可以去它的站點 down 它的證書得到它的公共密鑰。
一般 CA 的證書都內嵌在應用程序中間。不信你打開你的 IE, 在 internet 選項里面選中 " 內容 ", 點擊 " 證書 ", 看看那個 " 中間證書發行機構 " 和 " 委托根目錄發行機構 ", 是不是有一大堆 CA 的名稱?也有時 CA 的證書放在安全的數據庫里面。
當你接受到對方的證書的時候,你首先會去看該證書的 CA, 然后去查找自己的 CA 證書數據庫,看看是否找的到,找不到就表示自己不信任該 CA, 那么就告吹本次連接。找到了的話就用該 CA 的證書里面的公用密鑰去檢查 CA 在證書上的簽名。
這里又有個連環的問題,我怎么知道那個 CA 的證書是屬于那個 CA 的?人家不能造假嗎?
解釋一下吧。 CA 也是分級別的。最高級別的 CA 叫 RootCAs, 其他 cheap 一點的 CA 的證書由他們來頒發和簽名。這樣的話,最后的保證就是:我們信任 RootCAs. 那些有 RootCAs 簽名過的證書的 CA 就可以來頒發證書給實體或者其他 CA 了。
你不信任 RootCAs? 人民幣由中國人民銀行發行,運到各個大銀行,再運到地方銀行,你從地方銀行取人民幣的時候不信任發行它的中國人民銀行嗎? RootCAs 都是很權威的機構,沒有必要擔心他們的信用。
那 RootCAs 誰給簽名 ? 他們自己給自己簽名 , 叫自簽名 .
說了這么多,舉個 certificate 的例子吧 , 對一些必要的 item 解釋一下。
CertificateExample
Certificate:
Data:
Version:1(0x0)
SerialNumber:// 系列號
02:41:00:00:16
SignatureAlgorithm:md2WithRSAEncryption//CA 同志的數字簽名的算法
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
RSAPublicKey
Modulus(1000bit):
00:a4:fb:81:62:7b:ce:10:27:dd:e8:f7:be:
c6:70:99:db:b8:d5:05:03:69:28:82:
03:b9:90:d4:d0:bc:06:b2:51:33:
8b:
d2:cd:05:16:2e:95:66:
a1:c4:ef:25:e9:
fd:bd:3b:69:d9:eb
Exponent:65537(0x10001)
SignatureAlgorithm:md2WithRSAEncryption
76:b5:b6:10:fe:23:f7:f7:59:62:4b:b0:
bb:b3:49:
83:9b:60:
d2:fe:65:a0:c0:bc:ea:a6:23:16:66:
35:18:
bf:a9:26:fa:26:2b:46:
53:bb:43:09:92:40:ba:a8:aa:
其實這是我們看的懂的格式的證書內容,真正的證書都是加密過了的,如下:
-----BEGINCERTIFICATE-----
MIIDcTCCAtqgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBiDELMAkGA1UEBhMCQ0gx
EjAQBgNVBAgTCWd1YW5nZG9uZzESMBAGA1UEBxMJZ3Vhbmd6aG91MREwDwYDVQQK
Ewhhc2lhaW5mbzELMAkGA1UECxMCc3cxDjAMBgNVBAMTBWhlbnJ5MSEwHwYJKoZI
hvcNAQkBFhJmb3JkZXNpZ25AMjFjbi5jb20wHhcNMDAwODMwMDc0MTU1WhcNMDEw
ODMwMDc0MTU1WjCBiDELMAkGA1UEBhMCQ0gxEjAQBgNVBAgTCWd1YW5nZG9uZzES
MBAGA1UEBxMJZ3Vhbmd6aG91MREwDwYDVQQKEwhhc2lhaW5mbzELMAkGA1UECxMC
c3cxDjAMBgNVBAMTBWhlbnJ5MSEwHwYJKoZIhvcNAQkBFhJmb3JkZXNpZ25AMjFj
bi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMDYArTAhLIFacYZwP30
Zu63mAkgpAjVHaIsIEJ6wySIZl2THEHjJ0kS3i8lyMqcl7dUFcAXlLYi2+rdktoG
jBQMOtOHv1/cmo0vzuf38+NrAZSZT9ZweJfIlp8W9uyz8Dv5hekQgXFg/l
wNvQalaOEw2nyf45/np/QhNpAgMBAAGjgegwgeUwHQYDVR0OBBYEFKBL7xGeHQSm
ICH5wBrOiqNFiildMIG1BgNVHSMEga0wgaqAFKBL7xGeHQSmICH5wBrOiqNFiild
oYGOpIGLMIGIMQswCQYDVQQGEwJDSDESMBAGA1UECBMJZ3Vhbmdkb25nMRIwEAYD
VQQHEwlndWFuZ3pob3UxETAPBgNVBAoTCGFzaWFpbmZvMQswCQYDVQQLEwJzdzEO
MAwGA1UEAxMFaGVucnkxITAfBgkqhkiG9w0BCQEWEmZvcmRlc2lnbkAyMWNuLmNv
bYIBADAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBAUAA4GBAGQa9HK2mixM7ML7
0jZr1QJUHrBoabX2AbDchb4Lt3qAgPOktTc
aFcHihDn73s+PfhVjpT8arC1RQDg9bDPvUUYphdQC0U+HF72/CvxGCTqpnWiqsgw
xqeog
-----ENDCERTIFICATE-----
證書都是有壽命的。就是上面的那個 NotBefore 和 NotAfter 之間的日子。過期的證書,如果沒有特殊原因,都要擺在證書回收列 (certificaterevocationlist) 里面 . 證書回收列,英文縮寫是 CRL. 比如一個證書的 key 已經被破了,或者證書擁有者沒有權力 再使用該證書,該證書就要考慮作廢。 CRL 詳細記錄了所有作廢的證書。
CRL 的缺省格式是 PEM 格式。當然也可以輸出成我們可以讀的文本格式。下面有個 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
總結一下 X.509 證書是個什么東東吧。它實際上是建立了公共密鑰和某個實體之間聯系的數字化的文件。它包含的內容有:
版本信息 ,X.509 也是有三個版本的。
系列號
證書接受者名稱
頒發者名稱
證書有效期
公共密鑰
一大堆的可選的其他信息
CA 的數字簽名
證書由 CA 頒發,由 CA 決定該證書的有效期,由該 CA 簽名。每個證書都有唯一的系列號。證書的系列號和證書頒發者來決定某證書的唯一身份。
openssl 有四個驗證證書的模式。你還可以指定一個 callback 函數,在驗證證書的時候會自動調用該 callback 函數。這樣可以自己根據驗證結果來決定應用程序的行為。具體的東西在以后的章節會詳細介紹的。
openssl 的四個驗證證書模式分別是:
SSL_VERIFY_NONE: 完全忽略驗證證書的結果。當你覺得握手必須完成的話,就選用這個選項。其實真正有證書的人很少 , 尤其在中國。那么如果 SSL 運用于一些免費的服務,比如 email 的時候,我覺得 server 端最好采用這個模式。
SSL_VERIFY_PEER: 希望驗證對方的證書。不用說這個是最一般的模式了 . 對 client 來說,如果設置了這樣的模式,驗證 server 的證書 出了任何錯誤, SSL 握手都告吹 . 對 server 來說 , 如果設置了這樣的模式 ,client 倒不一定要把自己的證書交出去。如果 client 沒有交出證 書, server 自己決定下一步怎么做。
SSL_VERIFY_FAIL_IF_NO_PEER_CERT: 這是 server 使用的一種模式,在這種模式下, server 會向 client 要證書。如果 client 不給, SSL 握手告吹。
SSL_VERIFY_CLIENT_ONCE :這是僅能使用在 sslsessionrenegotiation 階段的一種方式。什么是 SSLsessionrenegotiation? 以后的章節再解釋。我英文差點,覺得這個詞組也很難翻譯成相應的中文。以后的文章里,我覺得很難直接翻 譯的單詞或詞組,都會直接用英文寫出來。如果不是用這個模式的話 , 那么在 regegotiation 的時候, client 都要把自己的證書送給 server, 然后做一番分析。這個過程很消耗 cpu 時間的,而這個模式則不需要 client 在 regotiation 的時候重復送自己的證書了。
posted on 2006-10-17 15:20 捕風 閱讀(587) 評論(0) 編輯 收藏 所屬分類: java安全