<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    捕風之巢

    統(tǒng)計

    留言簿(3)

    java友情鏈接

    閱讀排行榜

    評論排行榜

    openssl簡介(二)--證書

    ?

    一.???? 證書

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

    證書用來保證不對稱加密算法的合理性。想想吧,如果沒有證書記錄,那么假設某倆人 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 來繼續(xù)下面的通信。

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

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

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

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

    我們現(xiàn)在常用的證書是采用 X.509 結構的,這是一個國際標準證書結構。任何遵循該標準的應用程序都可以讀,寫 X509 結構的證書。

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

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

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

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

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

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

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

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

    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

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

    -----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 證書是個什么東東吧。它實際上是建立了公共密鑰和某個實體之間聯(lián)系的數(shù)字化的文件。它包含的內容有:

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

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

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

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

    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? 以后的章節(jié)再解釋。我英文差點,覺得這個詞組也很難翻譯成相應的中文。以后的文章里,我覺得很難直接翻 譯的單詞或詞組,都會直接用英文寫出來。如果不是用這個模式的話 , 那么在 regegotiation 的時候, client 都要把自己的證書送給 server, 然后做一番分析。這個過程很消耗 cpu 時間的,而這個模式則不需要 client regotiation 的時候重復送自己的證書了。

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

    主站蜘蛛池模板: 天天摸夜夜摸成人免费视频 | 久久亚洲AV成人无码| 成人国产mv免费视频| 91老湿机福利免费体验| 一级做a爱过程免费视频高清| 亚洲人成网站色在线观看| 亚洲国产精品高清久久久| 亚洲Av无码国产情品久久| 性xxxx视频播放免费| 日本h在线精品免费观看| 成全在线观看免费观看大全| 免费大片av手机看片高清| 亚洲国产日韩a在线播放| 亚洲欧洲国产视频| 婷婷亚洲久悠悠色悠在线播放| 亚洲精品高清在线| 四虎影在线永久免费四虎地址8848aa | 精品人妻系列无码人妻免费视频 | 成年女人午夜毛片免费视频| 亚洲高清免费在线观看| 今天免费中文字幕视频| 国产日韩久久免费影院| 人人爽人人爽人人片av免费| 国产天堂亚洲国产碰碰| 精品亚洲成a人在线观看| 亚洲精品无码久久久久A片苍井空| 亚洲国产成人精品无码区在线秒播 | 亚洲精品网站在线观看不卡无广告 | 亚洲男人电影天堂| 久久久久久久亚洲Av无码 | 99re6在线视频精品免费| yellow视频免费看| 亚洲日韩在线观看免费视频| 亚欧国产一级在线免费| 国产高清视频免费在线观看 | 狠狠亚洲狠狠欧洲2019| 亚洲中文字幕久久精品无码APP | 一区二区免费国产在线观看| 人人爽人人爽人人片A免费| www一区二区www免费| 中文字幕视频在线免费观看|