everything start from keystone(4)

如果你对安全的级别要求比较高，一般会配置使用ssl，即CONF中ssl.enabled为True，这个时候你会涉及到一堆文件， 甚至在nova和keystone，甚至其他模块的看起来会

略有一点儿不一样，差不多，但就是不确定是不是一回事，什么certfile，keyfile，ca_certs,ca_key什么的，还有pem，crt等等，然后你就晕了，其实我之前也晕了，毕竟不是

做网络安全的，对各种加密解密的也不是很清楚，平时可能用过RSA，MD5什么的，但总的来说会晕，ok，我来理一下：

Openstack配置文件中常能看见的几种证书格式.cert, .crt, .pem，其区别和联系：

.cert/.crt是用于存放证书，它是2进制形式存放的，不含私钥，事实上，cer文件是微软形式，可以用工具将cer文件转化为crt文件，前提是采用相同的编码DER或PEM。

.pem跟crt/cert的区别是它以Ascii（Base64）来表示，也可以说pem是一种编码方式。

Tip: .DER，扩展名DER用于二进制DER编码的证书，“一个DER编码的证书”

base64不是加密算法，但也是SSL经常使用的一种算法，它是编码方式，用来把asc码和二进制码转来转去的。

这里可以参考一下：

http://www.360doc.com/content/12/0405/13/3200886_201082456.shtml

http://blog.sina.com.cn/s/blog_44ee37cd01016r1h.html 这篇值得看

现在我们明白了这些看起来很可怕的文件大概是什么东西，恩，是数字证书，于是开始一个很久远的故事：

我们接触比较多的其实是对称加密，怎么加密解密大家都是知道的，每次传送的时候加密解密的秘钥就是我们的密码，这个密码是不能丢的，一旦泄露密码，

所有人都可以假冒服务器对你的数据解密；但是非对称加密不一样，，加密时使用公钥加密明文，解密时使用私钥解密密文

公钥加密的内容只能使用私钥解密，反之，服务器短用私钥加密的数据，只有公钥可以解密。

公钥加密体系看起来不错，但是有了新的问题：

“服务器”要对外发布公钥，那“服务器”如何把公钥发送给“客户”呢？

a)把公钥放到互联网的某个地方的一个下载地址，事先给“客户”去下载。

b)每次和“客户”开始通信时，“服务器”把公钥发给“客户”。

但是这个两个方法都有一定的问题，

对于a)方法，“客户”无法确定这个下载地址是不是“服务器”发布的，你凭什么就相信这个地址下载的东西就是“服务器”发布的而不是别人伪造的呢，万一下载到一个假的怎么办？另外要所有的“客户”都在通信前事先去下载公钥也很不现实。

对于b)方法，也有问题，因为任何人都可以自己生成一对公钥和私钥，他只要向“客户”发送他自己的私钥就可以冒充“服务器”了。

大家都可以生成公钥、私钥对，无法确认公钥对到底是谁的。 如果能够确定公钥到底是谁的，就不会有这个问题了。例如，如果收到“黑客”冒充“服务器”发过来的公钥，经过某种检查，如果能够发现这个公钥不是“服务器”的就好了，于是有了数字证书。因此在客服端和服务器通信时，服务器给客户端发送数字证书而不是公钥。

那么数字证书里都有些什么呢？

发布机构：指明这个证书是哪个公司创建的(只是创建证书，不是指证书的使用者)

有效期

公钥

主题：发布给谁的，或者说证书的所有者，一般是某个人或者某个公司名称、机构的名称、公司网站的网址

签名使用的算法：根据这个算法对指纹进行解密。指纹的加密结果就是数字签名，服务器使用私钥发送，打上数字签名，客户端收到后，根据签名算法和公钥解密，看签名是否改变；

指纹及指纹算法：一个哈希算法和哈希值，用来保证证书本身没有被修改，证书一旦修改，指纹就会变化，证书发布时，使用签名算法和私钥加密指纹，和证书放在一起，接到证书后，根据公钥，由于指纹(指纹的加密就是签名)和指纹算法本身也被用私钥加密，因此通过公钥解密，可以得到指纹，和指纹算法，然后根据指纹算法算出此时证书的“指纹”，和接收的指纹比较

RSA算法，加密强度很高。具体作法是将数字签名和数据加密结合起来。发送方在发送数据时必须加上数据签名，做法是用自己的私钥加密一段与发送数据相关的数据作为数字签名，然后与发送数据一起用接收方密钥加密。当这些密文被接收方收到后，接收方用自己的私钥将密文解密得到发送的数据和发送方的数字签名，然后，用发布方公布的公钥对数字签名进行解密。即：

A：PKA， A， PKB， 即拥有A的公钥，私钥，B的公钥

B：PKA， B， PKB， 即拥有A的公钥，B的公钥，私钥

发送/接收数据时：

A：取与数据data相关的一段数据dt,使用私钥A加密，形成签名，A(dt)，然后与数据data一起使用B的公钥PKB加密，PKB[[A(dt)](data)]，为发送的数据；

B：接收到数据后，只有其有私钥B用于解密数据，B[PKB[[A(dt)](data)] ]，即可得到数据data和签名A(dt)，之后使用A的公钥PKA解密签名 PKA[ A(dt)]，得到签名前的数据dt，通过查看签名知道数据是否更改，若未更改，则接收数据。

以上的过程，A发送的数据只有B可以解密接收，B接收后通过签名就可以知道数据没有遭到破坏，反之，B给A发送数据时，也通过这样的方式，保证传输的安全性！

有了数字证书后，客户与服务器端通信过程变为：

1.认证机构发布证书，证书中指纹及指纹算法被发布机构私钥加密，而发布机构自己也有自己的证书，使得客户端可以通过证书获得发布机构的公钥，发布机构自己的证书在操作系统中！

1.服务器端（公司）向认证机构买证书，客户端发起请求，服务器发送给客户端证书，客户端拿到证书

2.客户端在系统中查找认证公司，查不到则报错，查到则使用操作系统中的认证公司自己的证书，读取公钥。

3.使用公钥解密指纹和指纹算法，然后用指纹算法计算证书的指纹，与收到的指纹对比，一致则验证通过，之后读取证书中的公钥，用于和服务器端通信。

如果数字证书只是要在公司内部使用，公司可以自己给自己生成一个证书，在公司的所有机器上把这个证书设置为操作系统信任的证书发布机构的证书

说了这么多，配置成为ssl之后，通信过程是怎样呢？

客户端发起请求，

服务器将证书给客户端，

客户端拿到证书验证证书，验证成功后，

将自己的证书发给服务器，服务器收到客户端证书，验证证书，

成功后即可相互使用非对称加密算法安全通信。

好了我们再来看keystone中指定的certfile， keyfile，ca_certs, ca_key

分别是服务器端的证书，服务器端私钥，如果要进行客户端验证，ca_certs是客户端公钥，ca_key是客户端私钥，当然了，只是内部使用，无须认证时，

你可以自己生成这些证书文件，例如：

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout keystone.key -out keystone.crt

生成证书和私钥

如果不是要开发keystone部分，或者对这方面有特别的爱好，前面四章看完，使用和分析keystone就够了，everything start from keystone，可能还有其他的概念你希望掌握，

比如revoke，其他的middleware等，遇到再trace。