發信站:BBS水木清華站(FriNov1020:29:282000)

引用請指明原作譯者fordesign@21cn.com

二證書


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

證書用來保證不對稱加密算法的合理性。想想吧，如果沒有證書記錄，那么假設某倆人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
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

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



-----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已經被破了，或者證書擁有者沒有權力再使用該證書，該證書就要考慮作廢。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的時候重復送自己的證書了。