XCA自签发证书使用教程

为保障内网Web系统的访问安全，现计划在公司内部部署统一的私有CA（证书颁发机构），实现自主签发适用于内网域名及IP地址的HTTPS证书。此举将使目前通过HTTP访问的各类系统（无论使用域名或IP）均可升级为HTTPS加密访问，提升通信安全性与可信度。此文章主要阐述如何使用开源软件XCA进行自签发证书。

---

第一步 下载软件

XCA下载地址：点击链接

第二步 创建XCA数据库

这样所有的XCA数据都保存在这个文件里面，或者可以打开之前已经创建好的数据库

第三步 创建CA私钥

第四步 签名CA数字证书

第五步 客户、服务端导入CA证书

导出CA证书为crt文件，如果是andorid等移动设备，可以选择导出为cer类型文件

把证书导入到Windows，服务器与客户端都要导入此CA证书
在 win+r 开始“运行”里面输入 mmc ，打开windows管理控制台

其它电脑同样按此操作，也可以双击crt文件导入，
主要是导入的位置一定是要在受信用的根证书颁发机构下面

第六步 签发服务器证书与创建私钥

使用CA证书签发如下服务器证书，同时支持 域名：*.abc.com 以及 IP地址：192.168.10.200

生成服务器私钥

签发服务器证书

导出证书与私钥

后续只需将服务器私钥与证书导出然后部署在服务器即可

最后

至此，我们在内网用自己制做的CA证书，并给内网服务器的泛域名和IP签发证书就已经成功完成了
如果后继要给其它应用签发证书的话，
就只要重复上面的第三步就可以了。并在服务器导入就可以了。
当然前提是服务器和客户端都要导入CA证书 后续签名的证书只用在服务器端导入，不用在客户端导入。
因为客户端已经信任了CA证书，那么所有此CA签发的证书都是可以信任的

原文链接：使用XCA自制CA证书并签发https证书 - 博客园

---

证书签发相关知识

核心成员及其职责

1. CA私钥：团队的终极印章。

   • 作用：唯一用途就是对其他证书（如服务器证书）进行数字签名，以证明其真实性。绝不用于加密数据。
   • 比喻：就像公司的法律公章，只用于签发重要文件。

2. CA根证书：团队的公开营业执照。

   • 它包含了CA的公钥，用于验证那个“终极印章”的签名。
   • 它被预置在操作系统或浏览器的“受信任根证书存储区”里，是我们信任链条的起点。

3. 服务器私钥：网站服务器的唯一身份钥匙。

   • 核心作用：在TLS握手时，解密客户端发来的那个用服务器公钥加密的“预主密钥”。能解开这个密文，就反向证明了“我就是这个证书对应的真正服务器”。
   • 它也用于对传输数据进行签名，确保数据完整性和不可否认性。

4. 服务器证书：网站的营业执照。

   • 它由CA用“终极印章”签名，包含了网站信息（域名、组织等）和服务器的公钥。
   • 它的核心作用不是加密数据，而是身份认证：
     • 客户端验证它：用CA根证书的公钥来验证签名，确认此证书真实有效，且由可信CA颁发。
     • 证明公钥归属：确保证书里的公钥确实属于正在通信的www.example.com，而非中间人。
   • 确保证书未被篡改是验证过程中的自然结果。

5. CSR：申请“营业执照”的申请书。

   • 包含服务器信息和公钥，由服务器私钥签名，提交给CA。CA核实后，将其内容放入正式证书并签名。

重点概念澄清表

项目	常见误解	正确理解
CA私钥/根证书	根证书用于加密。	CA私钥只签名，不加密。根证书（含CA公钥）用于验证签名，建立信任锚点。
服务器私钥	用于解密所有传输数据。	主要用于握手时解密“预主密钥”，以完成身份认证和密钥协商。数据本身由对称密钥加密。
服务器证书	1. 用于加密传输数据。 2. 主要目的是“加密”。	1. 核心作用是身份认证，证明“公钥属于该域名”。 2. 其公钥仅加密握手时的“预主密钥”，确保密钥安全交换。
证书验证	只是检查是否过期。	是一个链条验证：用CA公钥验证签名 -> 查域名/有效期 -> 查吊销状态，确保证书真实、有效且可信。
对称加密	不如非对称加密安全。	对称加密（AES等）在相同密钥长度下同样安全，且速度快得多。TLS采用“非对称加密建立安全通道来交换对称密钥，再用对称加密处理数据”的混合模式，实现了安全与性能的最佳平衡。

“服务器公私钥不加密传输数据，而是加密传输数据中的对称加密密钥”是完全正确且最精髓的结论。整个体系的设计哲学就是：用非对称加密解决身份认证和安全密钥交换的问题，然后用对称加密解决高性能数据加密的问题。