Sectigo 博客
什么是自签名证书，如何创建自签名证书
自签名证书是由使用证书的实体自行签发、自行签名的数字证书，并非由受信任的证书颁发机构（CA）签发。自签名证书成本低、创建速度快，但由于存在安全风险、无法吊销、无外部验证，不建议用于面向公众的网站或涉及敏感数据的场景，更适合内部测试环境使用。其风险包括触发浏览器警告、易受攻击、加密机制失效。创建自签名证书需要生成私钥、证书签名请求（CSR）并自行签发证书，但为提升安全性，组织机构应选择使用受信任CA签发的证书。
更新时间：2023年12月4日
自签名SSL/TLS证书是指未经过公开受信任的证书颁发机构（CA）签名的数字证书。自签名证书与传统CA签发证书的区别在于，它由证书关联网站或软件的负责企业或开发者自行创建、签发、签名，而非由受信任的CA完成这些操作。
从底层原理来看，这类自签名证书采用的公/私钥密码对架构与X.509 证书所用的架构相同，但它不具备Sectigo这类受信任第三方CA提供的验证能力，也就是说，这类证书不会像受信任CA签发的证书那样，锚定到根CA或包含中间证书链。证书签发流程缺乏独立验证会带来额外风险，这也是使用自签名证书的核心问题。自签名证书用于面向公众的网站和应用时存在安全隐患，通常仅可在内部开发和测试环境中使用。
自签名证书类型的用途
尽管自签名证书存在风险，但它确实有适用场景，也具备一定优势：无需成本，开发者可轻松申请，采用与付费SSL证书相同的方式加密数据，不会过期，且不支持吊销。不过从整体安全性角度考虑，其风险通常高于收益。
自签名SSL证书的核心优势是零成本，任何开发者都可以轻松申请。企业可根据自身进度快速部署这类证书，因此常用于内部测试环境，或不对外部用户开放的受限Web服务器。此外，企业可以确认，自签名SSL证书采用与其他付费SSL/TLS证书相同的方式，对相关进出数据进行加密。
企业可以确认，自签名SSL证书采用与其他付费SSL/TLS证书相同的方式，对相关进出数据进行加密。
自签名证书不会像CA签发的证书那样，在固定周期后过期或需要续期。这一点看似便利，实则是重大隐患之一：这意味着自签名证书无法针对已发现的漏洞完成安全更新，也无法满足当下现代企业安全所需的证书敏捷性，因此这种身份验证方式极少被推荐使用。
此外，自签名证书不支持证书吊销。如果证书被遗忘在系统中，或留存于面向恶意攻击者开放的系统上，所使用的加密机制就会暴露在外部威胁下。对任何组织机构而言，网络安全都是重中之重，因此这类证书的风险往往大于收益。
自签名证书相关的风险与错误
自签名SSL证书存在诸多安全警告和隐患，因此几乎不推荐使用这类证书。
安全警告弹窗
当用户访问使用此类证书的站点（绝不建议在面向公众的站点上使用这类证书）时，浏览器会立即弹出安全警告，显示“error_self_signed_cert”或“err_cert_authority_invalid”等错误，要求用户确认是否继续访问。这些错误由用户的浏览器而非网站本身触发，会加重用户的安全顾虑，同时增加访问网站的操作步骤。所有现代Web浏览器都不信任自签名证书，也不会为对应域名显示挂锁图标或HTTPS状态标识。
这些警告会让访客产生恐惧和不安情绪会让访客产生恐惧和不安情绪，让访客觉得站点可能已遭入侵，无法妥善保护他们的数据。访客往往会避开这类网站，转而访问访问时不会弹出安全警告的竞品站点。不难理解，当自己信任的网页浏览器提示某个网站可能缺乏足够的安全防护时，访客几乎不会愿意在该网站上提交任何个人或机密信息。
无证书安全更新与吊销机制
如前所述，自行签发的证书因为永久有效，无需续期，这意味着这类证书永远不会通过更新或调整来修复漏洞，也不会适配最新的安全标准，会使您的环境易受黑客与网络攻击的威胁。
同理，由于这类证书无法被吊销，旧证书可能会在工作人员不知情的情况下留存于环境中，这会提升证书被利用的风险。利用自签名证书的一种常见手段是中间人攻击，这种攻击会导致通过TLS/SSL协议传输的数据被窃取，使访客面临身份被盗用、系统被入侵的风险。
证书链中存在自签名证书错误
如果开发者或IT团队尝试使用自签名SSL证书，在使用OpenSSL时，内部环境可能会出现“self-signed certificate in certificate chain”（证书链中存在自签名证书）错误。在SSL/TLS通信中，信任是通过层层传递的证书链建立的，最终锚定到受信任的根证书颁发机构（CA）。当证书链中出现自签名证书时，由于这类证书本身不具备受信任属性，信任模型会被破坏。
受信任的证书颁发机构（CA）签发的证书具备可追溯至该CA的信任链，可确保证书的合法性。而自签名证书由出示证书的主体自行创建和签名，并非由受信任的CA签发。因此这类证书不会被自动信任，因为没有第三方机构对主体身份进行验证。这会带来安全风险：攻击者可能出示伪造证书，诱骗客户端与恶意服务器建立安全连接。
出现该错误时用户可以选择绕过，但这个错误本身是一项安全防护措施，用于提醒用户自签名证书可能带来的相关风险。
我是否应该使用自签名SSL证书？
如果选择使用这类SSL证书，您将完全需要自行承担相关责任。这意味着您无法获得受信任证书颁发机构（CA）的背书，也无法应用最新的加密方法来保障数据、设备和应用所需的可靠身份认证与加密能力。
这类证书存在诸多风险，尤其是在面向公众的场景下风险极高。对于处理健康、税务、财务记录等任何隐私信息的网站而言，使用这类证书的风险极大。这类信息泄露不仅会损害品牌信任度，还可能因违反适用的隐私法规产生罚金，给组织造成经济损失。基于以上原因，绝不建议在面向公众的网站或应用中使用自签名证书。
很多人认为在员工门户、内部通信站点等内部场景部署自签名证书没有风险，但事实并非如此。这类证书仍然会触发浏览器和安全警告。由于这些警告可以被忽略，组织通常会要求员工直接跳过警告。考虑到内部站点的安全性是有保障的，这种操作本身直接危害不大，但这可能会在无意中让员工养成忽略此类安全警告的习惯，这种行为模式可能会提升组织面临的安全风险，增加漏洞被利用的可能性。
如何创建自签名证书
尽管自签名证书因存在安全风险不被推荐使用，但根据您所使用的环境（如Apache或Ubuntu Linux服务器），配置文件的设置和签发流程的完成操作并不复杂。
生成私钥
创建SSL证书需要同时准备私钥文件和证书签名请求（CSR）。流程的第一步是向您的证书颁发机构（CA）申请私钥。私钥是通过RSA和ECC等算法生成的加密密钥。其中RSA密钥是该应用场景下历史最久的加密体系之一，被众多平台所支持。
尽管不推荐使用自签名证书，以下是通过对应命令生成密钥的代码示例：
openssl genrsa -aes256 -out servername.pass.key 4096
该命令会提示您输入密码。如果证书因任何原因需要吊销，证书颁发机构（CA）可使用该密码验证证书所有者身份。
生成 CSR
生成完成后，私钥文件将以 servername.key 的名称存放在当前目录中，用于生成 CSR。以下是生成自签名证书的证书签名请求代码示例：
openssl req -nodes -new -key servername.key -out servername.csr
接下来，您需要输入若干信息，包括组织、组织部门、国家名称、省份、所在地以及通用名称。通用名称通常是对应站点的域名（DNS）或 IP 地址。
输入上述信息后，当前目录下会生成 servername.csr 文件，与 servername.key 私钥文件存放在同一位置。
颁发证书
最后，系统将基于 server.key（私钥文件）和 server.csr 文件生成新的证书（.crt）。根据您对信任链的应用场景，生成的证书可以是根证书，也可以是中间证书。以下是生成新证书的命令示例：
openssl x509 -req -sha256 -days 365 -in servername.csr -signkey servername.key -out servername.crt
与上一步操作类似，生成的 servername.crt 文件将存放在当前目录中。