打造甲方私有的多级CA证书中心（上）
网络安全等保测评里面有这么一条要求，属于中风险项目：
所有的信息传输都需要加密，即使是在内网。
这条要求落到具体信息系统的意思就是，这个系统只允许通过HTTPS访问，要配置使用SSL证书进行通信加密。
笔者：国际认证信息系统审计师、软考系统分析师
但等保测评要求的并不仅仅是信息系统，还包括整个IT环境，所以这个要求的完整实现，实际并不简单，网络设备、安全设备、服务器的带外管理后台等等但凡是有WEB界面控制台功能的设备全都会被涉及。
这些控制台大多数都支持启用HTTPS，还可以让用户自己上载和应用SSL证书。有些固件本身就会在开启HTTPS的时候生成自签名证书，实现HTTPS加密。
整件事的重点，在于要通过SSL证书保护信息系统的数据传输以及确认身份有效性。对于部署在内网的信息系统来说，要启用HTTPS，就需要设置内网域名访问，但公共可用的SSL证书服务无论需要付费与否，都不支持对内网域名签发。
虽然笔者也折腾出了一个办法，那就是通过内部DNS把公网域名解析成内网IP地址，这样可以在内网使用公网域名，流量并不跑到外网，而且证书还可以有效。具体参见：
但这方法，对没有公网域名的设备依然无效。虽然还可以考虑购买泛域名证书，但成本太高，且还是需要有公网主域名，分级分层还会对内部DNS服务的实现增加复杂性。
那么：干脆自己建一个CA证书中心。
CA证书中心的建立方法，大多数网文都会推荐使用easy-rsa，当然笔者也不例外。但区别在于，大多数网文介绍的都是通过easy-rsa建立简单的、只有一级的CA证书中心，然后就随便签。
这种做法不仅是对等保要求的敷衍应付，还实际引入了新的不安全因素。
要实现足够的安全性，需要参照专业SSL证书机构那样，在甲方内部实现根CA和中级CA构成的证书链，通过中级CA去签发最终证书。
而这个过程，还需要考虑：签发的证书类别、签发过程操作安全性等要素。于是，就有了本文。
写在前面：
因为CA中心的意义重大，必须确保CA中心服务器是独立系统，尤其应该是独立硬件。该服务器仅用于导入、签署和撤销证书请求。它不应运行任何其他服务，理想情况下，不使用CA服务器时，它应处于离线状态或完全关闭。
首先是架构设计。要考虑清楚，CA中心的管理和操作架构设计。既然是多级CA，重点考虑的就是分级之间如何能互操作而又能相互隔离。
不差钱也不差地方的甲方可以弄好几台服务器，从根CA到中级CA每一级都是独立的服务器。但我只能考虑如何在一台服务器上实现。
不过一台服务器也是有好处的：签发过程的所有数据流都可以在机器内实现，不需要在网络上传递，甚至可以全程离线操作，通过U盘实现数据文件传出传入也是可行的。
经思考和参考大量资料后，总体架构设计原则如下：
1、EASY-RSA软件包整个系统只装一份，不创立任何副本，一律通过建立符号链接使用，实现软件程序和数据相互独立。 2、各级CA数据相互独立，分别在不同的用户名下存放，实现逐级隔离，但通过用户同组而实现上一级对下一级可直接操作。
具体实现设计如下：
根CA的数据库存放在root用户文件夹，创建到EASY-RSA的符号链接。这主要方便同时进行软件包的操作。如果进一步严格要求，也可以专门建立一个根CA用户。
用根CA用户创建和初始化根CA数据文件。
为每一个中级CA创建用户，在用户文件夹内创建到EASY-RSA的符号链接，用中级CA用户创建和初始化本级的CA数据文件。
设置根CA用户是所有的中级CA用户的同组用户，中级CA用户所有文件设置同组可以读写的文件属性，即660。
设置中级CA用户的主目录属性同组可以读写（770）。
需要创建的中级CA的数量，按实际信息化环境有多少种类需要使用SSL证书的情况决定。对于笔者所在环境，至少包括有：
-
信息系统中间件，比如Tomcat；
-
WEB服务器，比如Apache，IIS，Nginx；
-
硬件管理的各种代理程序的管理界面，比如PCNS，但不是所有代理程序都能支持替换HTTPS证书；
-
服务器的带外管理WEB界面，比如iDRAC，iLO，iBMC等；
-
路由器、交换机、不间断电源、监控主机等等所有支持网络管理的设备的网络管理WEB界面（注意不是所有品牌都支持替换HTTPS证书）。
操作上，首先使用中级CA用户去初始化本级的CA证书中心数据，创建给根CA的签名请求CSR文件。
随后切换到根CA用户，从中级CA用户目录获取并操作签名请求CSR文件，签发证书，然后把生成的证书复制回去中级CA用户目录。
再切换回去中级CA用户，将根CA签发的中级证书导入，作为本机签发终端加密证书时用的证书。
直接签发就是在服务器内直接创建私钥和证书，并通过可靠的方式传递出去给使用环境使用。如果需要加强安全管理，则应按下文第4点方式，对传入的签名请求CSR文件进行证书签发，这样才能避免在网络上传递私钥。
创建专门用于分发传出私钥、证书的用户A，中级CA用户属于该用户A同组，可读写用户A允许同组读写的文件和目录，也就是文件属性660。
设置A用户的主目录属性为同组可以读写（770）。
操作上，可以通过中级CA用户一步生成私钥和签发证书，然后把私钥和证书复制到用户A目录下，设置文件拥有者为用户A。
签发证书后需要传出文件时，用户A通过SCP方式登录后从用户A目录复制获得私钥和证书，然后部署。
如果有必要更严格，可以按第2点的分类，创建多个传出用户去对应每一个中级CA。
创建一个专门用于传入签名请求CSR文件的用户B，设置中级CA用户和用户B同组，可读写用户B允许同组读写的文件。
设置B用户的主目录属性也一样是同组可以读写（770）。
操作上，用户B通过SCP方式登录并上传签名请求CSR文件到用户B自己的目录后，设置文件属性同组可以读写（660）。
签发时，通过中级CA用户，对位于用户B自己目录下的签名请求CSR文件进行操作，生成证书，然后复制到用户目录，修改文件拥有者为用户B。用户B再通过SCP方式复制获取签发后的证书，然后部署使用。
简要设计大致如上。下一篇就是具体过程记录。
写本文时发现，一些云运营商也基于同样的想法，推出了私有CA服务。
本站微信订阅号：
本页网址二维码：