首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >澄清自签署证书与根证书颁发机构

澄清自签署证书与根证书颁发机构
EN

Security用户
提问于 2015-03-03 03:16:11
回答 4查看 15.4K关注 0票数 11

我希望有人能帮助我理解SSL证书的一些基本原理,这些基本知识在我从文档、维基百科( Wikipedia )以及互联网上的任何其他地方获得这些证书时都遇到了困难。

我正在开发一个应用程序,它可以在一个单独的网络上与另一个应用程序通信。在双向通信中,每个应用程序都充当客户端和服务器。他们将在HTTPS上使用REST服务,每个网络的防火墙都是为对方显式打开的。所有SSL证书都将进行自签名。我的应用程序是用Java编写的,但我不确定另一个。

我相信我有两种选择来建立具有自签署证书的HTTPS连接:

  1. 每个应用程序的底层框架(例如Java)安装另一个应用程序的自签名证书,从而生成该框架,而不一定是更广泛的操作系统,信任证书。
  2. 每个服务器将另一个服务器的证书安装为根证书颁发机构,因此信任其他服务器生成的任何自签名证书。像Java这样的框架应该承认这个OS级别的根证书颁发机构,但是服务器上的web浏览器可能不会维护自己的数据库。

我正在处理的服务器已经生成了以下文件:server.crtserver.key。我相信这些都是使用openssl genrsa生成的。据我所知,.crt是公共证书,.key是它的私钥对应。我的主要问题是

  1. 其他服务器是否可以将.crt视为框架级证书或OS级根证书颁发机构(也就是说,我是否可以选择如何安装它)?在我的在线研究中,这一直是非常令人困惑的,因为许多术语似乎负担过重。我不知道我是在与证书颁发机构一起工作,还是与普通证书一起工作。
  2. 如果对1的回答是否定的,那么我需要从现有的文件中生成什么样的文件才能安装自签名的证书?

任何帮助,非常感谢,请假设提供链接到维基百科网页不会对我有多大帮助。

EN

回答 4

Security用户

回答已采纳

发布于 2015-03-03 08:59:33

您应该将证书基础结构(即PKI,公共密钥基础设施)视为信任的网络。

当您与多个希望相互验证自身(以及他们的网站)的人通信时,您首先选择一个共同信任的人。该第三方将成为“受信任的第三方”,并将被称为“证书颁发机构”(CA),用于证书管理。

CA将创建一个主键,也称为根CA键。TTP将不惜一切代价将私钥保密。公钥将嵌入到证书中,此证书将由CA的公钥签名。这意味着证书是自签名的,您可以用其中的密钥验证签名。

让我们假设现在你想访问爱丽丝的网站,但你希望它真的是爱丽丝的网站,而不是另一个自称是她的人。Alice是您社区的一部分,因此与您同意使用的CA联系。她向CA发送一个CSR (证书签名请求),它基本上是一个公钥。CA执行验证Alice是Alice的过程(例如,负责人亲自会见Alice,并从她手中获得CSR )。当CA确定Alice是Alice并且CSR属于她时,CA可以创建一个名为Alice的证书,并使用CA私钥对该证书进行签名。

当您在Alice的网站上连接时,您需要证书。一旦你获得了证书,你想要验证它是好的。您可以在证书中看到它是由CA颁发的。如果您拥有CA密钥,则可以验证签名。如果您信任CA正在正确地完成它的工作,那么您可以信任这个证书是一个很好的证书,并且由于CA首先信任它经过身份验证的Alice,那么您可以信任这个证书属于Alice。

然后,您可以确保使用此公钥加密消息时,只有具有相应私钥的Alice才会读取该消息。您还可以确定,由此证书签名的任何内容都是由Alice签名的。

如果Alice想要对您进行身份验证作为回报,那么您需要做同样的事情(获得从CA签名的证书,因为Alice也信任CA --她将信任该证书)

在您的示例中,由于您掌握了所有端点,所以您可以简单地创建两个自签名证书(实际上是两个根CA证书),并将公共部分交换到另一个端点。每个端点将使用自己的私钥对传出请求进行签名和解密传入消息,而另一个端点证书用于加密传出消息并验证传入消息。

如果您碰巧有很多端点,那么创建您自己的CA可能是值得的。生成根CA证书,然后为每个端点签名证书。在每个端点上,您都可以安装公共根CA证书。然后,每次端点连接到另一个端点时,所联系的端点都可以发送其证书,调用方可以根据根CA证书验证证书。

第一种方法的优点是直接前进,但一个证书的妥协意味着在所有端点上将其转换为一个新的证书。第二种方法具有可伸缩性的优点,一个端点不需要知道有多少其他端点存在,因为它可以动态地验证证书。此外,还有一些方法可以管理与证书撤销列表相妥协的密钥。

票数 11
EN

Security用户

发布于 2016-04-20 09:46:33

您提到的两个选项几乎是正确的:但是,您可以(而且应该)安装自签名证书,而不是证书颁发机构证书。

自签名证书与CA证书的区别在于,CA证书是一个特殊的自签名证书,其"basicConstraints“设置为"CA:true”(通常设置了关键标志)。此外,CA证书的keyUsage序列将"cRLSign“和"keyCertSign”列为常规(非CA)证书中不应该出现的用途。

下面是你的两个问题:

  1. 您可以将其用作框架级或OS级证书,但不要将自签名证书与CA证书混为一谈(见上文)。由于证书似乎只是您的应用程序的特殊用途证书,我建议使用它作为框架级证书。此外,安装受信任的OS级证书可能需要管理员权限,而不是所有通信合作伙伴都可能拥有这些权限。
  2. N/A (因为对1的答复是肯定的:)

附带说明: CA和非CA自签名证书之间的区别之所以相关,是因为您不应该允许以验证通信伙伴为目的的自签名证书充当证书颁发机构,因为这可能会带来额外的安全影响(即使用所述证书作为受信任权限的MITM攻击)。

票数 2
EN

Security用户

发布于 2015-03-03 03:39:29

在这里,您正在尝试验证和信任两个网络,同时充当双向的角色。受信任的授权证书是不同的/相同的,CA颁发证书可能是不同的,也可能是相同的,在它上没有任何问题。

注意:不要在SSL通信中使用自签名证书,并遵循标准的RFC规则。

如果您想在两个网络之间建立通信,有多种方法。( 1)隧道建立2)基于SSL的PTP 3):a.创建两个不同的CA并跨网络放置它,每个CA证书将与每个网络一起放置。现在,每个CA都应该颁发证书,并且它将由信任进行验证,并且通信现在将更加安全。

票数 0
EN
页面原文内容由Security提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://security.stackexchange.com/questions/82884

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档