我正在尝试为大多数本地服务生成自签名证书 (SSC)。密码学有点复杂，尤其是 PKI。
是否存在概念上的原因，为什么我们不在 HTTPS 上使用 SSC，但对于 FTP 安全来说似乎没问题（这里可能是错的）？
这是我生成它们的方式，而不是证书签名请求：
openssl req -x509 -nodes -days 365 -sha256 -newkey rsa:4096 -keyout server.pkey -out server.cert
答案1
其他答案中的假设是，HTTPS 仅供一般消费者浏览网页。诚然，绝大多数 HTTPS 流量来自网络，但两者只是协议，并且存在一些极端情况（例如基于 REST 的 API），其中 HTTPS 可能与 FTP 一样专业，在这种情况下，支持和反对自签名证书的论点并没有什么不同。
两个端点通过 HTTPS 进行通信且不太可能扩展的服务可以（而且经常）使用自签名进行操作。从协议的角度来看，没有区别，只有用例。
当终端实体（服务器）和依赖方（客户端）之间存在一对多关系时，PKI 签名证书便会发挥作用。在这种情况下，自签名证书会很麻烦，因为客户端需要单独审查和信任每个服务器证书（忽略用于信任锚点分发的 Windows 组策略等）。如果将其推广到多个服务器（例如 WWW），那么挑战会变得更大。再加上大多数 WWW 用户不懂技术，那么自签名证书就成了负担。
另一方面，考虑到运行安全 PKI 服务的开销，为两台机器通信设置完整的 PKI 是过度的。如果您所做的只是在两台服务器之间发送文件，或在两台机器之间发送 REST API 消息，那么自签名证书在这里可以被认为是可以接受的。在配置两个端点期间，很可能由精通技术的管理员完成，他们可以查看证书并安装它。
一种折衷方案是使用商业 CA，这样就可以为您完成操作受信任 CA 的工作。无需操作 PKI，证书受到许多潜在用户的信任。唯一的额外工作量是服务器操作员需要从 CA 注册证书（可能需要付费）并将其安装在他们的服务器上，而不是生成自签名证书。但这假设您的机器已连接到 Internet。
与上一段类似，您的组织可能运营自己的内部 PKI，而客户端已在其信任锚存储中拥有根 CA 证书。现在，自签名与 CA 签名的争论变得更加模糊，因为使用 CA 签名的证书几乎不需要额外的努力。
底线是：HTTPS 或 FTPS 作为协议并不关心您使用的是 CA 签名证书还是自签名证书。您需要根据具体情况分析您的需求，并决定使用哪种模型。
答案2
这完全取决于威胁模型、使用 SSL 的原因和用户群。
在外部用户通过更广泛的互联网传输稍微关键的数据的一般/任意情况下，两个证书都应该由第三方签署。
另一方面，如果只有少数开发人员需要它，那么自签名证书可以简单地作为每个 ftp 客户端的一次性证书被接受，这样工作量更少而且更安全。
还有实际方面需要考虑 - 许多人（大多数？）并不关心或了解安全性。HTTPS 已成为网络的标准，因为 Google 通过将其作为排名因素，然后调整其浏览器来推动它……sftp 背后没有这样的驱动程序。
另一个要素是易于创建。在可公开访问的 Web 服务器上使用 cpanel 或 letsencrypt 可以轻松系统地更新证书 - 而对于 sftp 来说，由于多种原因，这种情况不太可能发生 - 包括许多域共享一个 ftp 主机，通常需要不切实际的复杂 SSL 证书才能“正常工作”
如果你真的不在乎自签名证书的安全性，为什么只签名 365 天呢？如果让它有效期多年，你可能会减少麻烦。
答案3
是否有任何概念上的原因导致我们不在 HTTPS 上使用 SSC，但似乎没问题（此处可能有误) FTP 是否安全？
我认为你在这里错了，这是不可接受的。
但是，FTP 是一项正在消亡的技术，例如主流浏览器取消了对它的支持。首先，FTP 服务器的数量就很少，至少与网站数量相比是如此。其中支持 FTPS（与 SFTP 不同）的服务器就更少了，即使用 TLS 的 FTP。而且主流浏览器从一开始就不支持 FTPS。
因此，您看到的基本上是互联网的垃圾场，大部分是废弃的技术，只用于特殊情况。由于一般公共访问已被 HTTP 和 HTTPS 取代，因此通常不再是其中之一。因此可以说，没有人关心那里发生了什么。
尽管如此，这还是不可接受的。在证书很容易获得而且免费的时代（Let's Encrypt 和其他），获得一个合适的证书而不是自签名证书不再需要太多的努力。