CA的搭建与申请

Posted 2020-10-07

引入    

A和B使用非对称加密方法加密数据进行通讯，则双方均需要知道对方的公钥。若A得到一个声称为B的公钥后，不进行检查就用该公钥加密数据，然后传输，而该公钥实际上是黑客C的公钥，那么就只有黑客C的私钥才能解开数据，造成数据泄露。所以A需要对B非公钥进行检查，那么检查合格的依据是B拥有由CA颁发的证明自己身份的证书。CA（Certificate Authority）是签证机构，受通讯双方的信任，负责向通讯双方颁发证书，以证明通讯双方的身份。

以B为例，其申请证书的过程是：CA也有自己的公钥和私钥，首先B利用CA的公钥将自己的公钥加密后发送给CA，CA得到B的公钥后，对B提交的相关资料进行检查，若通过检查，则向B颁发证书。证书内容包括：用CA的私钥对B的公钥加密后所得的数据包、CA的相关信息、算法、证书有效期等。B收到CA颁发的证书后，将证书发送给A，由于A事先已有CA的公钥，则可以解得B的公钥，并且该公钥值是值得信任的。同理B也可以得到A的公钥，接下来A、B就可以进行数据传输。

那么A、B怎样确定CA的公钥是可信的呢？这需要CA向根CA申请证书，申请过程类似。证书内容包括：用根CA的私钥对CA的公钥加密后所得的数据包、根CA的相关信息、算法、证书有效期等。CA收到根CA颁发的证书后，将证书发送给A、B，由于A事先已有根CA的公钥，则可以解得CA的公钥，并且该公钥是值得信任的。

那么A、B怎样确定根CA的公钥是可信的呢？由于已经没有上级CA，所以根CA自己为自己颁发证书，证书内容包括：用根CA的私钥对根CA的公钥加密后所得的数据包、根CA的相关信息、算法、证书有效期等，即自己证明自己的身份，而A、B只能选择信任根CA。

Linux操作系统中的主机中已经安装了根证书，用来证明自己的身份。

PKI: Public Key Infrastructure

• 签证机构：CA（Certificate Authority）

• 注册机构：RA（签证机构和注册机构可能不一样）

• 证书吊销列表：CRL

• 证书存取库：

• X.509：定义了证书的结构以及认证协议标准：版本号、序列号、签名、算法、颁发者、有效期限、主体名称、主体公钥、CRL分发点、扩展信息、发行者签名

证书类型：

• 证书授权机构的证书：根CA的证书（自签名的证书，即自己给自己颁发证书）；子CA的证书（由上级CA颁发）

• 服务器证书（服务器要向外提供web服务，需要申请证书用来证明服务器的身份）

• 用户证书（当用户发送邮件或进行其他操作时用来证明用户的身份）

获取证书两种方法：

• 使用证书授权机构

（1）生成签名请求（csr）

（2）将csr发送给CA

（3）从CA处接收签名

• 自签名的证书

自已签发自己的公钥

CA的搭建与申请

在企业内部，可以搭建一个私有CA，对于https等需要加密的服务，可以通过向CA申请证书来实现加密通讯。

OpenSSL软件包大概可以分成三个主要的功能部分：SSL协议库、应用程序以及密码算法库。OpenSSL可以用户密码、生成随机数，实现单向加密，对称加密、非对称加密，在此基础上，实现密钥证书管理。OpenSSL实现了ASN.1的证书和密钥相关标准，提供了对证书、公钥、私钥、证书请求以及CRL等数据对象的DER、PEM和BASE64的编解码功能。OpenSSL提供了产生各种公开密钥对和对称密钥的方法、函数和应用程序，同时提供了对公钥和私钥的DER编解码功能。并实现了私钥的PKCS#12和PKCS#8的编解码功能。OpenSSL在标准中提供了对私钥的加密保护功能，使得密钥可以安全地进行存储和分发。在此基础上，OpenSSL实现了对证书的X.509标准编解码、PKCS#12格式的编解码以及PKCS#7的编解码功能。并提供了一种文本数据库，支持证书的管理功能，包括证书密钥产生、请求产生、证书签发、吊销和验证等功能。

下面通过openssl搭建CA并实现证书的申请：

openssl的配置文件：/etc/pki/tls/openssl.conf文件,根据该文件中的定义进行配置就可以实现CA的搭建。

打开etc/pki/tls/openssl.conf

这一部分定义了CA所在主机上相关配置文件的存储路径：

指定了使用哪一套CA，即可以有多套类似于CA_default的配置，可以在此处指明使用哪一套CA。

CA的工作目录，所有与CA相关的设置都在该目录下。

人工指定的新证书的路径，当前主机成为CA后，为子CA或客户端签署证书时，生成新证书的路径可人工指定。

证书吊销列表所在文件夹。

证书数据库，保存了证书的状态、编号等信息。默认没有，需手工创建，创建时只需要创建一个空文件，因为随着证书的颁发，系统会自动向其中添加内容。但若没有该文件，会报错。

默认的新证书的路径，当前主机成为CA后，为子CA或客户端签署证书时，生成的新证书会自动存放在该路径下。

$dir/certs是需要人工指定的，若不指定，生成的新证书只会自动存放在$dir/newcerts；若指定了，在$dir/certs和$dir/newcerts目录下都会存放该新证书，两路径下证书的内容相同，名称不同：$dir/certs下的证书名称是执行命令时手工指定的；$dir/newcerts下的证书是以证书的编号来命名的。

当前CA自己的证书，若当前CA是子CA，则该证书是上级CA颁发的；若当前CA是根CA，则该证书是当前CA自己给自己颁发的。

当前颁发证书序列号（十六进制数），当前CA作为签证机构，要为下级CA或客户端颁发证书，serial中保存的实际上是要颁发的下一个证书的编号。/etc/pki/CA/serial默认不存在，需手工创建，且不能为空，即需要指明序列号。

当前吊销序列号（十六进制数）即要吊销的下一个证书的编号。/etc/pki/CA/crlnumber默认不存在，需手工创建，且不能为空，即需要指明序列号。

当前CA的私钥。

命名方式和证书选项由ca_default决定。

当前主机成为CA后，为子CA或客户端签署证书时证书的有效期，默认365天。

当前主机成为CA后，为子CA或客户端签署证书时证书的吊销有效期。

这一部分定义了子CA或客户端与当前CA的匹配策略：

若搭建的CA是私有CA，仅供企业内使用，可以设置policy为policy_match，即子CA或客户端与当前CA的国家、省、组织名（即公司）必须匹配，但组织单元即部门可以不同，邮件地址也可以不写。对根CA来说，common name是根CA为客户端或子CA颁发证书时，证书上显示的颁发者；对子CA来说，common name是子CA向上级CA申请得到的证书上的被颁发者，以及子CA为客户端或下级CA颁发证书时，证书上显示的颁发者；对客户端来说，common name是客户端向CA申请得到的证书上的被颁发者。

若搭建的CA是公有CA，可以设置policy为policy_anything，即国家、省、组织名、组织单元即部门、邮件地址可以不同。搭建的CA是私有CA，也可以设置policy为policy_anything。

本文出自 “运维” 博客，请务必保留此出处http://fightingg.blog.51cto.com/13311108/1966156