ssl原理及ssl配置

先来扫盲
CA证书 https://coding.net/u/aminglinux/p/nginx/git/blob/master/ssl/ca.md

在高唐等地区,都构建了全面的区域性战略布局,加强发展的系统性、市场前瞻性、产品创新能力,以专注、极致的服务理念,为客户提供网站建设、成都网站设计 网站设计制作定制制作,公司网站建设,企业网站建设,品牌网站制作,营销型网站建设,成都外贸网站制作,高唐网站建设费用合理。

先来一个例子

A公司的小华被派到B公司办事情。B公司如何信任小华是A公司派来的呢?

普通介绍信

为了让B公司信任小华,A公司特意给小华开了一封介绍信,在信件中详细说明了小华的特征以及小华过来的目的,
并且声明这个小华确实是A公司派来的,除此之外还要有一个A公司的公章。
这样B公司前台姐拿到介绍信后,通过信件内容和A公司公章就能判断出小华确实是A公司派来的员工。

那万一A公司公章是假的呢?毕竟公章伪造太容易了,这样岂不是会存在问题。咱们就暂且认为公章这种东西很难伪造,
否则故事无法继续喽。

引入第三方中介公司

好,回到刚才的话题。如果和B公司有业务往来的公司很多,每个公司的公章都不同,那B公司的前台姐就要懂得分辨各种公章,
非常滴麻烦。所以,有某个中介公司C,发现了这个商机。C公司专门开设了一项“代理公章”的业务。

于是今后,A公司的业务员去B公司,需要带2个介绍信:
介绍信1(含有C公司的公章及A公司的公章。并且特地注明:C公司信任A公司。)
介绍信2(仅含有A公司的公章,然后写上:兹有xxx先生/女士前往贵公司办理业务,请给予接洽......。)

这样不是增加麻烦了吗?有啥好处呢?
主要的好处在于,对于接待公司的前台,就不需要记住各个公司的公章分别是啥样子的,她只要记住中介公司C的公章即可。
当她拿到两份介绍信之后,先对介绍信1的C公章验明正身,确认无误之后,再比对“介绍信1”和“介绍信2”的两个A公章是否一致。
如果是一样的,那就可以证明“介绍信2”是可以信任的了。

相关专业术语的解释

下面就着上面的例子,把相关的名词,作一些解释。

什么是证书?

证书,洋文也叫“digital certificate”或“public key certificate”。
它是用来证明某某东西确实是某某的东西,通俗地说,证书就好比例子里面的公章。通过公章,
可以证明该介绍信确实是对应的公司发出的。
理论上,人人都可以找个证书工具,自己做一个证书。那如何防止坏人自己制作证书出来呢?

什么是CA?

CA 是“Certificate Authority”的缩写,也叫“证书授权中心”。它是负责管理和签发证书的第三方机构,
就好比例子里面的中介C公司。
一般来说,CA必须是所有行业和所有公众都信任的、认可的。因此它必须具有足够的权威性。
就好比A、B两公司都必须信任C公司,才会找C公司作为公章的中介。

什么是CA证书?

CA证书,顾名思义,就是CA颁发的证书。

前面已经说了,人人都可以找工具制作证书。但是你一个小破孩制作出来的证书是没啥用处的。
因为你不是权威的CA机关,你自己搞的证书不具有权威性。
这就好比上述的例子里,某个坏人自己刻了一个公章,盖到介绍信上。但是别人一看,
不是受信任的中介公司的公章,就不予理睬。

什么是证书之间的信任关系?

在开篇的例子里谈到,引入中介后,业务员要同时带两个介绍信。第一个介绍信包含了两个公章,并注明,公章C信任公章A。
证书间的信任关系,就和这个类似。就是用一个证书来证明另一个证书是真实可信滴。

什么是证书信任链?

实际上,证书之间的信任关系,是可以嵌套的。
比如,C信任A1,A1信任A2,A2信任A3......这个叫做证书的信任链。
只要你信任链上的头一个证书,那后续的证书,都是可以信任滴。

什么是根证书?

根证书的洋文叫“root certificate”,为了说清楚根证书是咋回事,再来看个稍微复杂点的例子。
假设C证书信任A和B;然后A信任A1和A2;B信任B1和B2。则它们之间,构成如下的一个树形关系(一个倒立的树)。

ssl原理及ssl配置

处于最顶上的树根位置的那个证书,就是“根证书”。除了根证书,其它证书都要依靠上一级的证书,来证明自己。
那谁来证明“根证书”可靠呢?
实际上,根证书自己证明自己是可靠滴(或者换句话说,根证书是不需要被证明滴)。
聪明的同学此刻应该意识到了:根证书是整个证书体系安全的根本。
所以,如果某个证书体系中,根证书出了问题(不再可信了),那么所有被根证书所信任的其它证书,也就不再可信了。

证书有啥用?

CA证书的作用有很多,只列出常用的几个。

验证网站是否可信(针对HTTPS)

通常,我们如果访问某些敏感的网页(比如用户登录的页面),其协议都会使用HTTPS而不是HTTP,因为HTTP协议是明文的,
一旦有坏人在偷窥你的网络通讯,他/她就可以看到网络通讯的内容(比如你的密码、银行帐号、等)。
而 HTTPS 是加密的协议,可以保证你的传输过程中,坏蛋无法偷窥。
但是,千万不要以为,HTTPS协议有了加密,就可高枕无忧了。
假设有一个坏人,搞了一个假的网银的站点,然后诱骗你上这个站点。
假设你又比较单纯,一不留神,就把你的帐号,口令都输入进去了。那这个坏蛋的阴谋就得逞了。
为了防止坏人这么干,HTTPS 协议除了有加密的机制,还有一套证书的机制。通过证书来确保,某个站点确实就是某个站点。
有了证书之后,当你的浏览器在访问某个HTTPS网站时,会验证该站点上的CA证书(类似于验证介绍信的公章)。
如果浏览器发现该证书没有问题(证书被某个根证书信任、证书上绑定的域名和该网站的域名一致、证书没有过期),
那么页面就直接打开,否则的话,浏览器会给出一个警告,告诉你该网站的证书存在某某问题,是否继续访问该站点。

验证文件是否可信

SSL原理
https://coding.net/u/aminglinux/p/nginx/git/blob/master/ssl/ssl.md

SSL原理

要想弄明白SSL认证原理,首先要对CA有有所了解,它在SSL认证过程中有非常重要的作用。
说白了,CA就是一个组织,专门为网络服务器颁发证书的,国际知名的CA机构有VeriSign、Symantec,国内的有GlobalSign。
每一家CA都有自己的根证书,用来对它所签发过的服务器端证书进行验证。

如果服务器提供方想为自己的服务器申请证书,它就需要向CA机构提出申请。
服务器提供方向CA提供自己的身份信息,CA判明申请者的身份后,就为它分配一个公钥,
并且CA将该公钥和服务器身份绑定在一起,并为之签字,这就形成了一个服务器端证书。

如果一个用户想鉴别另一个证书的真伪,他就用CA的公钥对那个证书上的签字进行验证,一旦验证通过,该证书就被认为是有效的。
证书实际是由证书签证机关(CA)签发的对用户的公钥的认证。

证书的内容包括:电子签证机关的信息、公钥用户信息、公钥、权威机构的签字和有效期等等。
目前,证书的格式和验证方法普遍遵循X.509国际标准。

申请证书过程

ssl原理及ssl配置

首先要有一个CA根证书,然后用CA根证书来签发用户证书。
用户进行证书申请:

  1. 先生成一个私钥
  2. 用私钥生成证书请求(证书请求里应含有公钥信息)
  3. 利用证书服务器的CA根证书来签发证书

这样最终拿到一个由CA根证书签发的证书,其实证书里仅有公钥,而私钥是在用户手里的。

SSL工作流程(单向)

ssl原理及ssl配置

1.客户端say hello 服务端
2.服务端将证书、公钥等发给客户端
3.客户端CA验证证书,成功继续、不成功弹出选择页面
4.客户端告知服务端所支持的加密算法
5.服务端选择最高级别加密算法明文通知客户端
6.客户端生成随机对称密钥key,使用服务端公钥加密发送给服务端
7.服务端使用私钥解密,获取对称密钥key
8.后续客户端与服务端使用该密钥key进行加密通信

SSL工作流程(双向)

单向认证,仅仅是客户端需要检验服务端证书是否是正确的,而服务端不会检验客户端证书是否是正确的。 双向认证,指客户端验证服务器端证书,而服务器也需要通过CA的公钥证书来验证客户端证书。

双向验证的过程:

1.客户端say hello 服务端
2.服务端将证书、公钥等发给客户端
3.客户端CA验证证书,成功继续、不成功弹出选择页面
4.客户端将自己的证书和公钥发送给服务端
5.服务端验证客户端证书,如不通过直接断开连接
6.客户端告知服务端所支持的加密算法
7.服务端选择最高级别加密算法使用客户端公钥加密后发送给客户端
8.客户端收到后使用私钥解密并生成随机对称密钥key,使用服务端公钥加密发送给服务端
9.服务端使用私钥解密,获取对称密钥key
10.后续客户端与服务端使用该密钥key进行加密通信

在Linux机器上生成SSL密钥对
https://coding.net/u/aminglinux/p/nginx/git/blob/master/ssl/key.md

生成CA根证书

mkdir /etc/pki/ca_test //创建CA更证书的目录

cd /etc/pki/ca_test

mkdir root server client newcerts //创建几个相关的目录

echo 01 > serial //定义序列号为01

echo 01 > crlnumber //定义crl号为01

touch index.txt //创建index.txt

cd ..

vi tls/openssl.cnf //改配置文件

default_ca = CA_default 改为 default_ca = CA_test
[ CA_default ] 改为 [ CA_test ]
dir = /etc/pki/CA 改为 dir = /etc/pki/ca_test
certificate = $dir/cacert.pem 改为 certificate = $dir/root/ca.crt
private_key = $dir/private/cakey.pe 改为 private_key = $dir/root/ca.key

openssl genrsa -out /etc/pki/ca_test/root/ca.key //生成私钥

openssl req -new -key /etc/pki/ca_test/root/ca.key -out /etc/pki/ca_test/root/ca.csr

//生成请求文件,会让我们填写一些指标,这里要注意:如果在这一步填写了相应的指标,
比如Country Name、State or Province Name、hostname。

openssl x509 -req -days 3650 -in /etc/pki/ca_test/root/ca.csr -signkey /etc/pki/ca_test/root/ca.key -out /etc/pki/ca_test/root/ca.crt

生成crt文件

生成server端证书

cd /etc/pki/ca_test/server

openssl genrsa -out server.key //生成私钥文件

openssl req -new -key server.key -out server.csr//生成证书请求文件,填写信息需要和ca.csr中的Organization Name保持一致

openssl ca -in server.csr -cert /etc/pki/ca_test/root/ca.crt -keyfile /etc/pki/ca_test/root/ca.key -out server.crt -days 3650

//用根证书签名server.csr,最后生成公钥文件server.crt,此步骤会有两个地方需要输入y
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y

生成客户端证书

如果做ssl的双向认证,还需要给客户端生成一个证书,步骤和上面的基本一致

cd /etc/pki/ca_test/client

openssl genrsa -out client.key //生成私钥文件

openssl req -new -key client.key -out client.csr //生成请求文件,填写信息需要和ca.csr中的Organization Name保持一致

openssl ca -in client.csr -cert /etc/pki/ca_test/root/ca.crt -keyfile /etc/pki/ca_test/root/ca.key -out client.crt -days 3650

//签名client.csr, 生成client.crt,此步如果出现
failed to update database
TXT_DB error number 2

需执行:

sed -i 's/unique_subject = yes/unique_subject = no/' /etc/pki/ca_test/index.txt.attr

执行完,再次重复执行签名client.csr那个操作

如上操作如下结果
ssl原理及ssl配置


文章题目:ssl原理及ssl配置
本文链接:http://ybzwz.com/article/piieis.html