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