我曾经在办公室工作过，在局域网上，你只需https://someservice在网页浏览器中输入类似的东西，就能直接访问。（如果我记错了，请告诉我。）
这看起来对我家来说会是一个既有趣又有挑战性、很有教育意义的项目。我知道我没必要这么做，但我真的想知道它是怎么运作的。
我最近在树莓派上安装了 OpenWrt，并将其用作路由器。它负责处理我的本地 DNS 等服务。我还希望 OpenWrt 服务器作为我的证书颁发机构。
我尝试了大量教程后，最终按照本教程site操作。现在，我拥有以下文件，其中一些位于我本地网络的 Web 服务器上，名为，另一些则以router证书颁发机构本身的名称命名，位于路由器上：
- 该网站的私钥：
site.key - 站点的证书签名请求：
site.csr - 该网站的签名证书：
site.crt - 证书颁发机构的私钥存储：
router.key - 以及根证书：
router.pem
还有一些用于创建上述文件的其他文件。
但我想知道的是：网站客户端计算机上的 nginx 服务器已设置为使用我为其生成的证书；我该如何让该证书与路由器进行校验，以验证（至少根据路由器的指示）该网站的真实性。我已将根证书添加到/etc/ssl/certs，并添加了匹配的哈希链接。根据教程中的测试，该证书已存在于路由器上。
我找不到任何教程提到网络上的一台计算机要求另一台计算机验证数据是否可信。同样，这样做的目的是告诉路由器该特定数据是可信的，这对于路由器后面的任何人来说都应该足够了。
如果可以的话，我缺少了哪一步？如果不可以，请告诉我。
证书并不能使网站“真实存在”。即使您使用
https://someservice而不是普通的http://，仍然是DNS（而非证书）使someservice名称存在。最常见的方法是通过发布带有内部 DNS 域名的 DHCP 选项（对于单个后缀使用选项 15，对于多个后缀使用选项 119）来实现，这样当浏览器被告知连接到时，它实际上会在后台
someservice进行 DNS 查找。someservice.example.comTCP 连接建立后，HTTPS（TLS）会使用证书验证所连接的服务器是否有权以该名称进行操作。当您的 CA 为主题名称“someservice”颁发证书时，即授权证书（也就是私钥）持有者以该名称进行操作。
在此阶段不一定需要“与路由器进行检查”——路由器仅在颁发证书时参与，但证书有效的名称已经嵌入在证书本身中（更改它们将需要颁发新证书），并且根 CA 的签名由浏览器或 TLS 客户端独立验证。
从技术上讲，客户端（浏览器）可以联系路由器来验证证书是否已被撤销，但您的内部 CA 很可能没有设置该证书，因此可以肯定地说根本没有发生任何“签到”。
需要明确的是，证书颁发机构并非路由器的工作——它是一个完全独立的功能，在您的情况下，只是恰好在同一台机器上运行。通常情况下，CA 会托管在更安全的地方。
不支持这种做法。事实上，如果真的可以，那基本上就违背了 TLS 和证书的意义：它们的存在部分是为了防范网络攻击，所以如果主机盲目信任它们所连接的网络，那么攻破 TLS 就变得轻而易举，毫无意义。
（出于同样的原因，浏览器希望在证书中找到的名称严格是 URL 中指定的名称，并且不受上述 DHCP 选项的自动后缀的影响。）
唯一类似的情况是，企业网络中的 Active Directory 在所有机器上部署 CA，已经具有预先存在的信任关系：将机器“加入”域的手动操作（域名是手动输入的，而不是自动检测的）意味着从该域注册中央配置和管理，因此内部证书颁发机构经常作为其中的一部分发布。
/etc/ssl/certs 中的哈希链接特定于 OpenSSL。您应该始终遵循发行版自身的说明，例如，
/usr/local/share/ca-certificates在 Debian/Ubuntu 中添加到 ，以便工具可以将根证书复制到 /etc/ssl/certs以及软件可能查找的任何其他位置（例如，工具可能会为 GnuTLS 重新生成单个“cert.pem”包）。仅当路由器本身充当 TLS 客户端时才相关。