我们在 domain.com 的前端使用位于 api.domain.com 的 API。
对于 domain.com，我们使用 LetsEncrypt 的 SSL。然而，对于后端，使用自签名证书要简单得多。
如果用户访问使用自签名证书连接到https://api.domain.com 的 domain.com，是否会显示红色警告横幅？这是好的做法吗？此外，我们可以用外部 IP 代替 https://api.domain.com 吗？
【问题讨论】：
总的来说，这不是一个好主意。证书的目的是允许客户端验证它实际上是在与正确的服务器对话，而不是与中间人攻击者对话。它这样做的方式（有点简化）是证书包括服务器的公钥，以及客户端打算与之通信的服务器的域名（“通用名称”）。然后证书由另一个大约相同类型和内容的证书签名，依此类推，直到链到达一个不需要另一个签名的证书，因为它已经被客户端信任（它在受信任的根中）例如您的操作系统列表）。
自签名证书没有这个签名链，它被称为自签名，因为用来签名它的证书是它自己。客户端无法验证证书（当然，除非它明确将其列为受信任的）。这意味着攻击者可以通过为相同的域名自签名不同的证书，但使用不同的密钥对来欺骗（冒充）您的 API。这可能允许窃取凭据或提供虚假数据。请注意，攻击者还可能将用户输入的信息（发出的所有请求）转发给真实的 API，因此响应（也由攻击者首先收到，但转发给受害者）在没有太多背景信息的情况下很容易看起来非常真实。
这可以（理论上）通过证书固定来解决，但如果是 Javascript 客户端，这将很困难（如果可能的话）。 HPKP 似乎是一种解决方案，但 HPKP 不适用于自签名（不可验证）证书。我不确定 Javascript 是否具有对服务器证书的适当访问级别来实现固定。
即使您确实实施了固定，自签名证书也不能被撤销。想想如果您在您的 api 域中发现用于 https 的 TLS 密钥遭到破坏会发生什么。您将无法撤销密钥，因此客户端仍会接受中间人攻击者提供被泄露的密钥。
付出了很多努力，您可以实现一些不标准、难以正确且容易出错的东西。
或者您也可以为 api.domain.com 使用免费的letsencrypt证书，所有必要的基础设施和设置都已经在主域上完成。 :)
【讨论】：