是否可以将根证书的使用限制为域


28

我的客户使用自签名证书来使应用程序正常工作。为了能够正常工作,我必须安装用于签名证书的根证书。

是否可以配置根证书,使其仅对一个域进行验证?


可能只有我一个人,但我不清楚您的实际要求。您要达到什么最终状态?如果将其根证书导入到域控制器信任中,则仅该域下的系统就可以对其进行验证……
Gravy

听起来好像您将自签名证书与不受公众信任的根CA混淆了。配置为使用自签名证书的应用程序非常糟糕,因为该应用程序需要配置为忽略证书验证错误。使用不被公共信任的根CA实际上是很普遍的。
格雷格·阿斯克

您是否有内部CA服务器?
Crypt32

1
CA可以通过名称约束将其自身限制在某些域中,但是将约束追溯应用于其他人的CA是另一回事。
Matt Nordhoff 2015年

3
没有区别。您也可以将名称约束应用于第三方CA。您只需使用您的私有CA签署第三方根CA证书,然后发布生成的交叉证书。在这种情况下,外国连锁店将通过受限的交叉证书最终成为您的私人连锁店。
Crypt32

Answers:


24

根据经验:

,暗示信任客户的CA证书是对该CA签名的每个证书的信任。

我不知道有哪个应用程序/库具有简单的选项,允许您作为最终用户选择仅信任某些(子)域(即仅*)的客户或任何其他CA证书。 example.com和* .example.org,仅此而已。

Mozilla对当前受信任的政府赞助的CA作为开放关注点也存在类似的担忧,例如,Chrome内置了用于访问Google网站的额外支票,这就是流氓* .google.com证书和Diginotar CA的危害所在如何公开的原因。 。

但是,即使您不信任CA,也仍然可以导入/信任由该CA签名的特定服务器证书,这将防止对该证书中的主机名进行SSL警告。那应该使您的应用程序正常工作而不会出现错误或投诉。

例外情况:

X.509v3 PKI标准的一个非常未被充分利用的选项是“ 名称约束”扩展,该扩展允许CA证书包含被授权为其颁发证书的域名模式的白名单和黑名单。

您可能很幸运,您的客户在设置PKI基础结构并将其Name约束包括在其CA证书中时已经克制了自己。然后,您可以直接导入其CA证书,并且知道它只能验证有限范围的域名。


2
@CryptoGuy:内部CA也可以为外部域颁发证书。一旦您信任内部CA,便没有任何限制,即仅适用于您自己的域(Active Directory或DNS)example.com*.ad.example.com 有效的证书。您的内部CA也可以颁发证书,以 *.example.bank允许进行中间人攻击并监听您的网上银行凭据。
HBruijn 2015年

1
好吧,“一切”都不是完全正确的。诸如证书吊销列表之类的东西。但这并没有改变底线。
Ben Voigt 2015年

1
抱歉,您又不正确。您可以限制第三方CA信任颁发给所需名称列表的证书(来自该CA)。关于您自己的内部CA,我相信毫无疑问。如果您不信任自己的CA,则IT会出问题。我想说的是,通过拥有私有CA,OP可以建立对第三方CA的部分信任(通过限制它们信任的名称)。
Crypt32

3
到您编辑过的帖子:即使第三方CA没有名称约束扩展名,也可以通过交叉认证使用您自己的内部CA服务器来应用它们。在这种情况下,证书链如下:叶SSL证书->交叉证书->您的CA证书->您的内部根证书。诀窍是您使用内部CA签署第三方CA。交叉证书将具有所有必需的约束。
Crypt32

1
CryptoGuy说这是可能的,但是要找到实现细节是一项挑战。描述如何实现的答案如何?也许讨论哪些​​平台支持nameConstraints。
jorfus

17

@CryptoGuy在这里有一个很好的答案,但我想对此进行扩展。

释义:

您可以限制第三方CA信任颁发给所需名称列表的证书(来自该CA)。即使第三方CA没有名称限制扩展名,也可以通过交叉认证使用您自己的内部CA服务器来应用它们。诀窍是您使用内部CA签署第三方CA。

叶子SSL证书->交叉证书->您的CA证书->内部根证书。

这就是您的工作方式(使用OpenSSL命令行CA)

创建一个简单的CA

openssl req -new -x509 -days 3650 -newkey rsa:2048 -sha256 -out root-ca.crt -keyout root-ca.key -subj "/CN=My Root CA"

您可以跳过创建中间CA

创建一个具有名称约束的中间CA请求。

openssl req -new -days 3650 -newkey rsa:2048 -out domain-ca.req -sha256 -keyout domain-ca.key -config ossl_domain_com.cfg

ossl_domain_com.cfg文件中包含以下内容:

[ req ]
prompt=no
distinguished_name=req_distinguished_name
req_extensions=domain_ca

[ req_distinguished_name ]
CN=somedomain.com trust CA

[ domain_ca ]
basicConstraints=critical,CA:true,pathlen:1
nameConstraints=critical,permitted;DNS:.somedomain.com

然后,将该中间域CA与您的CA签名。

openssl x509 -req -in domain-ca.req -CA root-ca.crt -CAkey root-ca.key -sha256 -set_serial 1 -out domain-ca.crt -extensions domain_ca -extfile ossl_domain_com.cfg

如果您跳过创建中间体,请使用您的根CA进行签名

现在,使用您的证书重新授权您原始域的CA。您可以在此处添加CA扩展。

openssl x509 -in third_party_ca.crt -CA domain-ca.crt -CAkey domain-ca.key -set_serial 47 -sha256 -extensions domain_ca -extfile ossl_domain_com.cfg -out domain-cross-ca.crt

您可能需要使用-x509-to-req参数创建请求,该请求的签名方式与上面的中介完全相同。

现在,将您的根CA,中间CA和跨域CA添加到浏览器的信任数据库中。


2
MacOS不支持nameConstraints。对于任何使用名称限制内部CA的人来说,都是FIY。security.stackexchange.com/questions/95600/... archive.is/6Clgb
jorfus

问:此解决方案的状态如何?如今(2018年)它能在什么系统上运行?//每当我被迫安装另一个公司自签名证书时,我都希望这样做;每当我想到香港邮政局或赛门铁克时。//我想我可能不会在乎每个人都不会实现如此描述的缩小,只要它们不会意外地实现扩大即可。
Krazy Glew '18

@KrazyGlew我有一个用于此的批处理文件,但我仍然定期使用它。有时,我必须在中间证书过期或轮换时重新发行它们,因此它需要更多的手动操作,但这并不是问题。我确实偶尔会在授权管理的网站上运行,这些浏览器由于使用其他中间授权或它们添加的额外域名而使我的浏览器无法信任,而我不信任该域名。
davenpcj

2
我刚刚成功使用了它,谢谢。没有中间证书,效果很好,使用一个证书有什么好处吗?此外,basicConstraints配置文件中的该行似乎导致约束扩展名两次包含在证书中,这导致Firefox拒绝带有错误消息的证书。我认为可以安全地将其删除。
wrtlprnft

我在最后一步遇到错误:error with certificate to be certified - should be self signed。这是什么意思,如何解决?pastebin.ubuntu.com/p/QHhpQh2N6J
mymedia
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.