荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: georgehill (清风浮云 人生), 信区: Security
标  题: [转载] openssl简介--证书(转寄)
发信站: BBS 荔园晨风站 (Sat Nov 11 13:43:30 2000), 站内信件

【 以下文字转载自 georgehill 的信箱 】
【 原文由 georgehill.bbs@smth.org 所发表 】
发信人: xgh (小丙), 信区: Security
标  题: openssl简介--证书
发信站: BBS 水木清华站 (Fri Nov 10 20:29:28 2000)

引用请指明原作/译者 fordesign@21cn.com

                           二 证书


  证书就是数字化的文件,里面有一个实体(网站,个人等)的公共密钥和其他的属性,
如名称等。该公共密钥只属于某一个特定的实体,它的作用是防止一个实体假装成另
外一个实体。

  证书用来保证不对称加密算法的合理性。想想吧,如果没有证书记录,那么假设某
俩人A与B的通话过程如下:
这里假设A的public key是K1, private key是K2
        B的public key是K3, private key是K4
xxxxxx(kn)表示用kn加密过的一段文字xxxxxx
             A----->hello(plain text)------------->B
             A<---------hello(plain text)<---------B
             A<---------B's public key<------------B
             A--------->A's public key(K1)-------->B
                     ... ...

如果C想假装成B, 那么步骤就和上面一样。
             A----->hello(plain text)------------->C
             A<---------hello(plain text)<---------C
             注意下一步,因为A没有怀疑C的身份,所以他理所当然的接受了C的
             public key,并且使用这个key来继续下面的通信。
             A<---------C's public key<------------C
             A--------->A's public key(K1)-------->C
                     ... ...
  这样的情况下A是没有办法发觉C是假的。如果A在通话过程中要求取得B的证书,并且
验证证书里面记录的名字,如果名字和B的名字不符合,就可以发现对方不是B.验证B的
名字通过再从证书里面提取B的公用密钥,继续通信过程。

  那么,如果证书是假的怎么办?或者证书被修改过了怎么办?慢慢看下来吧。

  证书最简单的形式就是只包含有证书拥有者的名字和公用密钥。当然现在用的证书没
这么简单,里面至少还有证书过期的deadline, 颁发证书的机构名称,证书系列号,和
一些其他可选的信息。最重要的是,它包含了证书颁发机构(certification authority
简称CA)的签名信息。

   我们现在常用的证书是采用X.509结构的,这是一个国际标准证书结构。任何遵循该
标准的应用程序都可以读,写X509结构的证书。

   通过检查证书里面的CA的名字,和CA的签名,就知道这个证书的确是由该CA签发的,
然后,你就可以简单证书里面的接收证书者的名字,然后提取公共密钥。这样做建立的
基础是,你信任该CA, 认为该CA没有颁发错误的证书。

   CA是第三方机构,被你信任,由它保证证书的确发给了应该得到该证书的人。CA自
己有一个庞大的public key数据库,用来颁发给不同的实体。

  这里有必要解释一下,CA也是一个实体,它也有自己的公共密钥和私有密钥,否则怎
么做数字签名?它也有自己的证书,你可以去它的站点down它的证书得到它的公共密钥。
  一般CA的证书都内嵌在应用程序中间。不信你打开你的IE, 在internet选项里面选中
"内容", 点击"证书", 看看那个"中间证书发行机构"和"委托根目录发行机构", 是不是
有一大堆CA的名称?也有时CA的证书放在安全的数据库里面。

  当你接受到对方的证书的时候,你首先会去看该证书的CA, 然后去查找自己的CA证书
数据库,看看是否找的到,找不到就表示自己不信任该CA, 那么就告吹本次连接。找到
了的话就用该CA的证书里面的公用密钥去检查CA在证书上的签名。

  这里又有个连环的问题,我怎么知道那个CA的证书是属于那个CA的?人家不能造假吗?
解释一下吧。CA也是分级别的。最高级别的CA叫Root CAs, 其他cheap一点的CA的证书由
他们来颁发和签名。这样的话,最后的保证就是:我们信任Root CAs.那些有Root CAs签
名过的证书的CA就可以来颁发证书给实体或者其他CA了。

   你不信任Root CAs?人民币由中国人民银行发行,运到各个大银行,再运到地方银行,
你从地方银行取人民币的时候不信任发行它的中国人民银行吗?Root CAs都是很权威的
机构,没有必要担心他们的信用。

  那Root CAs谁给签名?他们自己给自己签名, 叫自签名.

说了这么多,举个certificate的例子吧,对一些必要的item解释一下。
Certificate Example
Certificate:
Data:
Version: 1 (0x0)
Serial Number: //  系列号
02:41:00:00:16
Signature Algorithm: md2WithRSAEncryption //CA同志的数字签名的算法
Issuer: C=US, O=RSA Data Security, Inc., OU=Commercial //CA自报家门
Certification
Authority
Validity
Not Before: Nov 4 18:58:34 1994 GMT  //证书的有效期
Not After : Nov 3 18:58:34 1999 GMT
Subject: C=US, O=RSA Data Security, Inc., OU=Commercial
Certification Authority
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1000 bit)
Modulus (1000 bit):
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)
Signature Algorithm: 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

  其实这是我们看的懂的格式的证书内容,真正的证书都是加密过了的,其丑恶面容
如下:

-----BEGIN CERTIFICATE-----
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
-----END CERTIFICATE-----

  证书都是有寿命的。就是上面的那个NotBefore和NotAfter之间的日子。过期的
证书,如果没有特殊原因,都要摆在证书回收列(certificate revocation list)里面.
证书回收列,英文缩写是CRL.比如一个证书的key已经被破了,或者证书拥有者没有权
力再使用该证书,该证书就要考虑作废。CRL详细记录了所有作废的证书。

  CRL的缺省格式是PEM格式。当然也可以输出成我们可以读的文本格式。下面有个CRL
的例子。

-----BEGIN X509 CRL-----
MIICjTCCAfowDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxIDAeBgNVBAoT
F1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMS4wLAYDVQQLEyVTZWN1cmUgU2VydmVy
IENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw05NTA1MDIwMjEyMjZaFw05NTA2MDEw
MDAxNDlaMIIBaDAWAgUCQQAABBcNOTUwMjAxMTcyNDI2WjAWAgUCQQAACRcNOTUw
MjEwMDIxNjM5WjAWAgUCQQAADxcNOTUwMjI0MDAxMjQ5WjAWAgUCQQAADBcNOTUw
MjI1MDA0NjQ0WjAWAgUCQQAAGxcNOTUwMzEzMTg0MDQ5WjAWAgUCQQAAFhcNOTUw
MzE1MTkxNjU0WjAWAgUCQQAAGhcNOTUwMzE1MTk0MDQxWjAWAgUCQQAAHxcNOTUw
MzI0MTk0NDMzWjAWAgUCcgAABRcNOTUwMzI5MjAwNzExWjAWAgUCcgAAERcNOTUw
MzMwMDIzNDI2WjAWAgUCQQAAIBcNOTUwNDA3MDExMzIxWjAWAgUCcgAAHhcNOTUw
NDA4MDAwMjU5WjAWAgUCcgAAQRcNOTUwNDI4MTcxNzI0WjAWAgUCcgAAOBcNOTUw
NDI4MTcyNzIxWjAWAgUCcgAATBcNOTUwNTAyMDIxMjI2WjANBgkqhkiG9w0BAQIF
AAN+AHqOEJXSDejYy0UwxxrH/9+N2z5xu/if0J6qQmK92W0hW158wpJg+ovV3+wQ
wvIEPRL2rocL0tKfAsVq1IawSJzSNgxG0lrcla3MrJBnZ4GaZDu4FutZh72MR3Gt
JaAL3iTJHJD55kK2D/VoyY1djlsPuNh6AEgdVwFAyp0v
-----END X509 CRL-----


下面是文本格式的CRL的例子。
The following is an example of a CRL in text format:
issuer= /C=US/O=RSA Data Security, Inc./OU=Secure Server Certification
Authority
lastUpdate=May 2 02:12:26 1995 GMT
nextUpdate=Jun 1 00:01:49 1995 GMT
revoked: serialNumber=027200004C revocationDate=May 2 02:12:26 1995 GMT
revoked: serialNumber=0272000038 revocationDate=Apr 28 17:27:21 1995 GMT
revoked: serialNumber=0272000041 revocationDate=Apr 28 17:17:24 1995 GMT
revoked: serialNumber=027200001E revocationDate=Apr 8 00:02:59 1995 GMT
revoked: serialNumber=0241000020 revocationDate=Apr 7 01:13:21 1995 GMT
revoked: serialNumber=0272000011 revocationDate=Mar 30 02:34:26 1995 GMT
revoked: serialNumber=0272000005 revocationDate=Mar 29 20:07:11 1995 GMT
revoked: serialNumber=024100001F revocationDate=Mar 24 19:44:33 1995 GMT
revoked: serialNumber=024100001A revocationDate=Mar 15 19:40:41 1995 GMT
revoked: serialNumber=0241000016 revocationDate=Mar 15 19:16:54 1995 GMT
revoked: serialNumber=024100001B revocationDate=Mar 13 18:40:49 1995 GMT
revoked: serialNumber=024100000C revocationDate=Feb 25 00:46:44 1995 GMT
revoked: serialNumber=024100000F revocationDate=Feb 24 00:12:49 1995 GMT
revoked: serialNumber=0241000009 revocationDate=Feb 10 02:16:39 1995 GMT
revoked: serialNumber=0241000004 revocationDate=Feb 1 17:24:26 1995 GMT

  总结一下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: 这是仅能使用在ssl session renegotiation阶段的一
   种方式。什么是SSL session renegotiation?以后的章节再解释。我英文差点,觉
   得这个词组也很难翻译成相应的中文。以后的文章里,我觉得很难直接翻译的单词
   或词组,都会直接用英文写出来。如果不是用这个模式的话,那么在regegotiation
   的时候,client都要把自己的证书送给server, 然后做一番分析。这个过程很消耗
   cpu时间的,而这个模式则不需要client在regotiation的时候重复送自己的证书了。

--

※ 来源:·BBS 水木清华站 smth.org·[FROM: 202.38.248.1]
--
※ 转载:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 192.168.1.115]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店