如果您是网络工程师，停机就是您的头号敌人。跟上变更请求、解决问题和实施新硬件是一项艰苦的工作，但当服务中断发生时，所有这些都会脱轨。

    网络和应用程序中断的背后可能有很多原因，但最痛苦（且可避免）的原因之一是 Web 服务器和负载均衡器（例如 Avi Vantage）中使用的 TLS 证书过期或配置错误。

    瓶颈：手动配置

    如果您部署了 Avi 控制器或任何其他网络设备，您就会知道强制实施 HTTPS 加密以保护应用程序和后端连接的重要性。毋庸置疑，可用性和安全性是应用程序交付的首要任务。但是，手动且容易出错的 SSL/TLS 证书流程会迅速减慢团队的速度并带来多种风险。

    虽然 Avi Vantage 提供了一定程度的证书可见性，但安装、配置和续订证书的过程仍然非常手动，而且经常被误解。现实情况是，许多应用程序和运营团队仍然在纠结这个问题：“我在哪里可以得到证书？”更不用说如何在证书到期前正确部署和续订证书了。

    当您考虑到提交 CSR、等待批准、检索证书以及在 Avi 控制器上安装和配置每个证书需要花费的 10 到 15 分钟时，这些时间加起来非常可观。团队可能要花费数小时来完成原本只需几分钟即可完成的工作。

    那么，发生了什么？他们点击了“轻松”按钮……

    简单按钮：自签名加密证书

    传统上，组织使用由公众信任或内部私有证书颁发机构 (CA) 签名的证书。另一方面， 自签名加密证书 并不适用于所有用例，但它们很容易生成，这使得它们很受网络和应用程序团队的喜欢。然而，它们也带来了一些风险和挑战。

    与 CA 签署的证书相比，自签名加密证书的信任链始于生成证书的用户，也终于生成证书的用户。用户很容易生成熵值较低的证书密钥对，无法适当保护私钥，或者颁发有效期远远超过可接受有效期的证书（我们见过有效期从 10 年到 99 年不等的证书）。

    问题是，跟踪自签名加密证书的任务对 PKI 或安全团队来说非常痛苦。当您有数十个用户使用不同的服务器和网络设备（包括 Avi 控制器）生成自己的证书时，每个证书都有不同的界面，保持可见性和治理就变得更加困难。

    另一个捷径：通配符SSL证书

    用户经常采取的另一个避免更多手动工作的捷径是使用通配符SSL证书。他们只需  在多个子域中使用一个通配符SSL证书，就可以避免在其环境中跨多个服务器管理多个证书的麻烦。很简单，对吧？

    如果无法正确查看安装证书的所有位置，也无法严格保护相关的私钥，那么通配符SSL证书就会产生单点故障，一旦出现问题，修复起来将非常困难。

    例如，Epic Games 最近 因通配符SSL证书过期而经历了一次大面积中断 ，花了五个多小时才修复。在对该事件进行事后审查时，他们表示，“服务到服务的通配符SSL证书安装在数百种不同的生产服务中，因此影响非常广泛。”

    底线： 应该限制使用自签名加密证书和通配符SSL证书。在大多数情况下，它们只是捷径，而不是解决问题的办法。那么，答案是什么？一个词——自动化。