【问题标题】:TLS client certificates : which attribute for authorization?TLS 客户端证书:授权的哪个属性?
【发布时间】:2019-03-03 12:35:57
【问题描述】:

我正在尝试设置一个 Web 服务,该服务使用在 TLS 握手期间发送的 x509 客户端证书进行身份验证,并检查用户是否有权访问所请求的资源。

这个想法是给每个用户一个访问级别,并且一些资源只对更高级别可用。然后使用证书将用户与其级别匹配。

我在配置 Apache 以根据根 CA 验证证书并将证书转发到后端应用程序(基于 python 的 XML-RPC 服务器)时没有问题。

但是我正在努力选择我应该使用证书的哪些属性来将用户映射到他的级别:

  • Common Name 字段似乎是一个自然的选择,但我想知道这个解决方案的安全性如何,因为没有什么能阻止多个中间 CA 提供具有相同 CN 的证书
  • 公钥本身显然更安全,但它的实用性如何?如果客户在证书到期后必须更新证书,它会保持不变吗?还有一个更大的字符串的存储和比较速度的问题
  • 整个证书本身或其指纹指纹可以替代公钥,但如果更新证书,客户端将无法连接

我目前倾向于使用公钥,但在这种情况下它是最佳选择吗?还是有更好的选择?

提前感谢

【问题讨论】:

  • HTTPS 客户端身份验证的基本部分是您只接受来自您的 CA(或某些遵循 CN 上特定规则的 CA)的证书。完成此操作后,您可以确定 CN 是真实的。
  • "如果客户在证书到期后必须更新证书,它会保持不变吗?"这取决于它如何更新。默认情况下,例如 Let's Encrypt/Certbot,它将是一个新密钥。但是有一个选项可以保留旧密钥,因为有时这是一个问题,例如当您通过 TLSA 记录在 DNS 中发布密钥时,或者如果您执行 HTTP 密钥锁定或类似的事情。
  • 某些 CA 可能允许您在证书中添加特定 ID,例如在扩展中。在这种情况下,您可以控制它并进行所需的映射。有关将证书内容映射到用户 ID 的示例,另请参见 Apache SSLOptions 案例 FakeBasicAuth

标签: ssl authorization x509certificate client-certificates mutual-authentication


【解决方案1】:

通常,使用客户端证书进行身份验证是通过一些私有 CA 来完成的,该 CA 颁发客户端证书并且仅在验证客户端证书时信任 CA。在这种情况下,受信任的 CA 并且只有这个 CA 可以完全控制证书的主题,这意味着将 CN 映射到用户非常好并且也很常用。

如果您出于某种原因想要允许由任意 CA 颁发的证书,那么您已经意识到自己无法完成这种简单的映射。在这种情况下,可能会完成证书公钥或证书指纹之间的映射,这当然需要预先知道特定用户期望的确切证书。而且,每当客户端证书因过期而需要更改时,都需要以某种方式更新此映射。

【讨论】:

  • 谢谢,这基本上证实了我的猜测。由于我们不了解客户端基础架构,因此我将继续推动专用 CA,以便使用 CN 作为身份验证的基础。
  • “而且,每当客户端证书因过期而需要更改时,都需要以某种方式更新此映射。”如果在 pubkey 上完成匹配,并且每次证书续订使用相同的密钥,则映射可以保持固定。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-10-25
  • 1970-01-01
  • 2021-01-15
  • 2019-05-02
  • 2021-12-12
  • 1970-01-01
相关资源
最近更新 更多