您的问题的答案归结为威胁建模。使用 HTTPS 等加密协议是一种安全机制，可以防止某些威胁。如果这些威胁与您相关，则必须进行分析：

• 您的内部网络中是否存在潜在的威胁参与者？根据您的问题，您似乎认为可以完全信任内部网络。这通常是一种误解，因为您的内部网络可能会受到多种威胁（例如，有权访问该网络的有效用户变得恶意，该网络中的系统受到威胁，错误配置打开了网段等）。
• 架构会发生变化吗？系统很可能会随着时间的推移而发生变化，并且先前的安全假设（例如我的内部网络是受信任的）不再成立。如果这是一个合理的场景，那么提前构建必要的安全机制可能是一个好主意。这就是安全最佳实践的用途。在不确定的领域提供安全保障。
• 是否有必须满足的监管、法律或合规要求？您说您的客户认为 HTTPS 是最先进/现代的最佳实践。这个友好措辞的声明的来源实际上可能是一个外部驱动的要求，必须满足。不合规是一种威胁，也应该在威胁分析中涵盖。

这些都是值得分析的重要话题。当我设计系统架构并且我有疑问时，我宁愿在安全方面犯错。在这种情况下，最佳实践方法确实是使用 HTTPS 进行通信，无论在何种情况下，只要对应用程序没有显着影响（例如性能影响）。

如今，维护服务器证书的困难应该不是问题，因为这是常见的做法。这应该是正常计划操作活动的一部分。

说了这么多，当然需要额外的努力来使用 HTTPS 而不是 HTTP，并且您有权向客户收取额外的努力。我建议您计算在开发过程中以及在操作过程中随着时间的推移这将花费多少，并让客户决定这些成本是否值得收益。

混合和匹配 HTTP 和 HTTPS 不是一个好主意 - 您将不断地在配置中进行处理。

通常，只有在有非常具体的原因时才应该将组件添加到系统中 - 只是因为有人认为这是一个好主意，而不是具体原因。

我并不是说 HTTPS 是一个坏主意——恰恰相反——但你有很多学习要做。您提出的模型破坏了信任关系，而信任关系是首先使用 TLS 的主要原因。您似乎也没有考虑过如何规划您的 PKI。

服务器在未来的某一天损坏，因为某些服务器的证书已过期并且没人知道

如果您提供服务，那么您应该为服务配置监控，包括证书到期。

听起来您正在寻找与推出证书的方法争论的理由。从这里的字里行间看，您目前似乎缺乏实现此目标所需的技能和计划。

是的，工作量很大，但这就是商业模式——您评估工作量、您需要获得的技能以及您可以购买的技能，然后您为此向客户收费。（Serge 强调了证书的成本——但这是整个练习中最小的成本）。

内部网络不安全

一般来说，内部网络比面向公众的系统更安全，但不应将其视为完全安全。很大一部分攻击来自内部——鱼叉式网络钓鱼、社会工程和内部攻击都是流行的载体，它们从网络内部的立足点开始。

因此，即使通过您的内部网络，也没有充分的理由让秘密或私人信息的未加密流量。您不一定需要公共名称或 CA 层次结构 - 如果您有明确定义的双边通信渠道，那么建立明确的信任关系可能会更简单，您的负载均衡器配置为信任您的特定自签名证书后端服务器，仅此而已。

作为专业人士，您应该向您的客户提供建议，但不应自己做出决定。

向您的客户提出的论点是：

• 在服务器网络中使用 HTTPS 有什么好处？如果此网络与任何其他系统隔离，并且只有系统管理员可以访问它，您可能会争辩说这种收益可以忽略不计，因为它只是保护系统免受已经拥有管理员权限的人的侵害。如果其他没有管理员权限的工作人员可以访问它，则收益不为零，其他客户的系统也不能。
• 这样做有什么风险？证书上的离题主要是……离题。但事实是 HTTPS 是一种比 HTTP 更复杂的协议，任何增加的复杂性都会增加实施错误的风险。如果上一步得出的结论是收益可以忽略不计，那足以建议客户不要这样做。
• 增加的成本是多少？在这里，您必须考虑直接和间接成本。如果您使用外部证书，直接成本可能包括额外证书的价格，或者如果您使用私有 PKI，则可能包括创建私有证书的时间。它们还将包括系统配置的时间。他们应该将维护时间作为经常性成本包括在内，包括计划的证书更新——这部分属于您的责任范围，但您可以向您的客户收取时间费用。间接成本更难确定，但由于增加的复杂性及其可能的后果，您应该使用自己的经验来评估错误风险。恕我直言，如果您的客户坚持不听从您的建议，您可能会为此向他们收费。

但是，当您说了这么多时，客户要对决定负责。