假设A公司有一个密钥对,并且需要发布他的公开密钥供公众使用(也就是在他的网站上发布ssl),那么A公司必须向认证机构(CA)发出证书请求(CR),以获得他的密钥对的证书。
所以A公司的公钥用有效的CA的私钥签署的证书称为A公司的证书。
我举个例子来解释一下。
在普通的基于密钥对的PKI中,有私钥和公钥。
在基于证书的系统中,有私钥和证书。证书比公钥拥有更多的信息。
演示(可以生成证书和私钥)。 http://www.selfsignedcertificate.com/
你可以下载打开私钥文件和证书文件,你可以看到证书文件包含了很多信息,如下图所示。
你可以在这个网站上匹配你生成的证书(用文本编辑器打开)和私钥(用文本编辑器打开)。 https://www.sslshopper.com/certificate-key-matcher.html
如果证书与客户的私钥相匹配,客户可以确定,该证书是客户提供的,或者是客户信任的代理(CA)提供的。
但是,只有私钥和证书的通信存在问题。
因为,任何人都可以生成自己的证书和私钥,所以,除了服务器知道与证书的公钥相匹配的私钥之外,简单的握手并不能证明服务器的任何事情。解决这个问题的一个方法是让客户端拥有套的一个或多个它信任的证书。如果证书不在集子里,则服务器不可信。
这种简单的方法有几个缺点。服务器应该能够随着时间的推移升级到更强的密钥("密钥轮换"),即用新的密钥替换证书中的公钥。不幸的是,现在由于本质上是服务器配置的改变,客户端应用程序必须更新。如果服务器不在应用开发者的控制之下,例如,如果它是一个第三方的Web服务,这就特别有问题。如果应用程序必须与任意服务器(如Web浏览器或电子邮件应用程序)对话,这种方法也会出现问题。
为了解决这些弊端,服务器通常会配置来自知名发证机构的证书,称为证书颁发机构(CA)。他的主机平台(客户端)通常包含一个它信任的知名CA的列表。与服务器类似,CA也有一个证书和一个私钥。当为服务器签发证书时,CA会用它的私钥来签署服务器证书。客户端就可以验证服务器是否有平台已知的CA签发的证书。
然而,使用CA在解决一些问题的同时,又引入了另一个问题。因为CA为许多服务器签发证书,你仍然需要一些方法来确保你正在与你想要的服务器对话。为了解决这个问题,CA颁发的证书会用一个特定的名称(如gmail.com)或一组通配符的主机(如*.google.com)来标识服务器。
下面的例子将使这些概念更加具体。在下面的命令行片段中,openssl工具的s/s_client命令查看维基百科的服务器证书信息。它指定了443端口,因为那是HTTPS的默认端口。该命令将openssl s/_client的输出发送到openssl x509,它根据X.509标准格式化证书信息。具体来说,该命令要求输入包含服务器名称信息的主题和识别CA的发行人。
$ openssl s_client -connect wikipedia.org:443 | openssl x509 -noout -subject -issuer
subject= /serialNumber=sOrr2rKpMVP70Z6E9BT5reY008SJEdYv/C=US/O=*.wikipedia.org/OU=GT03314600/OU=See www.rapidssl.com/resources/cps (c)11/OU=Domain Control Validated - RapidSSL(R)/CN=*.wikipedia.org
issuer= /C=US/O=GeoTrust, Inc./CN=RapidSSL CA
可以看到,证书是由RapidSSL CA为匹配/*.wikipedia.org的服务器签发的。
如你所见,因为有了CA发给Servers的这些附加信息,客户端可以很容易地知道它是否在与服务器通信。
好了,我们来分析一下,让非技术人员也能理解。
你可以这样想。一个证书就像你银行的保险箱。它包含了很多重要的东西;一般来说,这些东西包含了你的身份。证书有一个公钥,需要一个私钥来打开它。
你的保险箱也需要两把钥匙才能打开,就像证书一样。
有了保险箱,银行家的钥匙就像公钥,因为它留在银行,而公钥留在证书上。你有私钥,这是 “取证 "所需要的,在保险箱的例子中,除了公钥之外,你的私钥也是需要的。
在你真正打开你的保险箱之前,你必须先验证你的身份(有点像证书申请);一旦你被确认身份,你就用你的私钥和公钥一起打开你的保险箱。这有点像提出证书请求,然后从认证机构拿到证书(只要你能被识别(信任),而且你有正确的密钥)。