突然(几个月后)出现了一个狂野的系统管理员......
我将不得不对此表示异议。 没有 CA 就可以建立 PKI 的想法非常荒谬。您必须通过简化创建过程来维护 PKI 的完整性和性能。您必须在某处创建和存储证书,那将在哪里?繁荣,你有一个CA。任何体面的 PKI 也需要维护 CRL,管理员应该只是手写吗?您也可以忘记拥有 509 的不同类型,因为手动维护它的开销会让你大开眼界,然后把它变成灰色泥浆。 p>
我想您可以使用 openssl 的 CLI 手动创建票证,然后将它们通过 ftp 传输到远程客户端,但这对于相当大的部署来说是一个巨大的麻烦。本质上,如果您的部署是如此之小以至于手动生成证书(重复输入信息和所有)然后不担心 CRL 是一个合理的计划,那么您根本不需要高级身份验证系统。类似于 TLS+LDAP(一个服务器证书用于机密性而非身份验证)更合适。
好的,既然我已经消除了一些误解,让我们真正回答您的问题:您何时希望使用 SSL 而不是 Kerberos 进行身份验证?基于 x509 的身份验证是一个令人难以置信的模糊野兽,主要是因为大多数人(如上面的 Michael-O)没有意识到 SSL 是专门工作的,因为它正在对用户进行身份验证。我知道有一些 FTP 程序可以通过这种方式进行身份验证,中间件使用它……有时(这听起来与 Java 谈话中的用例很接近),并且 vpn 客户端/网关通常使用 SSL 证书进行身份验证。
使用 SSL 意味着我在上面提到的 PKI,如果您的用例涉及机密性,这将非常有用。 DoD 是企业广泛使用 PKI 来实现身份验证之外的功能的一个很好的例子。在这种情况下,假设所有相关的客户端程序都支持 x509 身份验证是很有意义的。它仍然是一个奇特的设置,您仍然需要弄清楚最终用户如何将他们的 SSL 凭据“呈现”给系统(客户端配置、智能卡等),但它会很好地结合在一起。除了奇怪的配合之外,kerberos 还通过临时票证进行身份验证,而 SSL 证书通常会持续很长时间(这就是需要 CRL 的原因),这意味着如果在一个证书上考虑到永不更改的密钥,攻击者将有几个月的时间在他们必须找到新证书之前免费乘车,而在 kerberos 中,他们只有一天的时间,而且只有在门票没有被销毁的情况下。
所有其他情况应尽可能使用 Kerberos 身份验证。它提供了正确的安全层,实际上被设计为一个大型网络身份验证系统,这就是为什么你有一些难以用 SSL 复制的东西(比如作为服务而不是普通用户进行身份验证)并且只是为他们的预期工作目的。您的用例总是需要考虑现有的基础架构,这些基础架构可能会面向 kerberos,有时面向 LDAPS,但几乎从不面向 x509 身份验证。换句话说:无论您正在编写什么,都更有可能已经在 kerberos 基础架构中运行,因此您不妨以某种方式插入它。与 509 作为身份验证相比,管理员熟悉 Kerberos 作为身份验证也会使您受益更多。这样做的缺点是门票之外的机密性是个笑话。 NFSv4 有一些弱 DES(不,我什至不是指 3DES)加密,它(不知何故)与 kerberos 票证相关,但它进行身份验证,基本上就是这样。
我希望看到 x509 的一些灵活性与 kerberos 风格的基础架构(服务识别和拥有即将到期的票证的“一次性”方面)结合到更广泛实施的解决方案中比现在的 x509,但在这个阶段,它主要是做白日梦。
总结:
x509 很好,如果基础设施要求不会成为问题,并且无论如何您都会将 PKI 用于其他东西,但可能会不必要地重复工作,或者如果部署可能无论如何都会有一个 kerberos 基础设施。
p>
Kerberos 是一种类似但更好的身份验证方案,它被更广泛地使用/理解,但对 PKI 完全没有帮助,你获得了身份验证,仅此而已。