ca证书_ca证书失败 - CSDN
精华内容
参与话题
  • CA证书(数字证书的原理)

    万次阅读 多人点赞 2018-07-19 17:25:53
    文中首先解释了加密解密的一些基础知识和概念,然后通过一个加密通信过程的例子说明了加密...接着对数字证书做一个详细的解释,并讨论一下windows中数字证书的管理,最后演示使用makecert生成数字证书。如果发现文...

    转自:http://www.cnblogs.com/JeffreySun/archive/2010/06/24/1627247.html(感谢)

    文中首先解释了加密解密的一些基础知识和概念,然后通过一个加密通信过程的例子说明了加密算法的作用,以及数字证书的出现所起的作用。接着对数字证书做一个详细的解释,并讨论一下windows中数字证书的管理,最后演示使用makecert生成数字证书。如果发现文中有错误的地方,或者有什么地方说得不够清楚,欢迎指出!

     

    1、基础知识

          这部分内容主要解释一些概念和术语,最好是先理解这部分内容。

    1.1、公钥密码体制(public-key cryptography)

    公钥密码体制分为三个部分,公钥、私钥、加密解密算法,它的加密解密过程如下:

    • 加密:通过加密算法和公钥对内容(或者说明文)进行加密,得到密文。加密过程需要用到公钥。
    • 解密:通过解密算法和私钥对密文进行解密,得到明文。解密过程需要用到解密算法和私钥。注意,由公钥加密的内容,只能由私钥进行解密,也就是说,由公钥加密的内容,如果不知道私钥,是无法解密的。

    公钥密码体制的公钥和算法都是公开的(这是为什么叫公钥密码体制的原因),私钥是保密的。大家都以使用公钥进行加密,但是只有私钥的持有者才能解密。在实际的使用中,有需要的人会生成一对公钥和私钥,把公钥发布出去给别人使用,自己保留私钥。

     

    1.2、对称加密算法(symmetric key algorithms)

    在对称加密算法中,加密使用的密钥和解密使用的密钥是相同的。也就是说,加密和解密都是使用的同一个密钥。因此对称加密算法要保证安全性的话,密钥要做好保密,只能让使用的人知道,不能对外公开。这个和上面的公钥密码体制有所不同,公钥密码体制中加密是用公钥,解密使用私钥,而对称加密算法中,加密和解密都是使用同一个密钥,不区分公钥和私钥。

     

            // 密钥,一般就是一个字符串或数字,在加密或者解密时传递给加密/解密算法。前面在公钥密码体制中说到的公钥、私钥就是密钥,公钥是加密使用的密钥,私钥是解密使用的密钥。

     

    1.3、非对称加密算法(asymmetric key algorithms)

    在非对称加密算法中,加密使用的密钥和解密使用的密钥是不相同的。前面所说的公钥密码体制就是一种非对称加密算法,他的公钥和是私钥是不能相同的,也就是说加密使用的密钥和解密使用的密钥不同,因此它是一个非对称加密算法。

     

    1.4、RSA简介

    RSA是一种公钥密码体制,现在使用得很广泛。如果对RSA本身有兴趣的,后面看我有没有时间写个RSA的具体介绍。

    RSA密码体制是一种公钥密码体制,公钥公开,私钥保密,它的加密解密算法是公开的。 由公钥加密的内容可以并且只能由私钥进行解密,并且由私钥加密的内容可以并且只能由公钥进行解密。也就是说,RSA的这一对公钥、私钥都可以用来加密和解密,并且一方加密的内容可以由并且只能由对方进行解密

     

    1.5、签名和加密

    我们说加密,是指对某个内容加密,加密后的内容还可以通过解密进行还原。 比如我们把一封邮件进行加密,加密后的内容在网络上进行传输,接收者在收到后,通过解密可以还原邮件的真实内容。

    这里主要解释一下签名,签名就是在信息的后面再加上一段内容,可以证明信息没有被修改过,怎么样可以达到这个效果呢?一般是对信息做一个hash计算得到一个hash值,注意,这个过程是不可逆的,也就是说无法通过hash值得出原来的信息内容。在把信息发送出去时,把这个hash值加密后做为一个签名和信息一起发出去。 接收方在收到信息后,会重新计算信息的hash值,并和信息所附带的hash值(解密后)进行对比,如果一致,就说明信息的内容没有被修改过,因为这里hash计算可以保证不同的内容一定会得到不同的hash值,所以只要内容一被修改,根据信息内容计算的hash值就会变化。当然,不怀好意的人也可以修改信息内容的同时也修改hash值,从而让它们可以相匹配,为了防止这种情况,hash值一般都会加密后(也就是签名)再和信息一起发送,以保证这个hash值不被修改。至于如何让别人可以解密这个签名,这个过程涉及到数字证书等概念,我们后面在说到数字证书时再详细说明,这里您先只需先理解签名的这个概念。

     

    2、一个加密通信过程的演化

          我们来看一个例子,现在假设“服务器”和“客户”要在网络上通信,并且他们打算使用RSA(参看前面的RSA简介)来对通信进行加密以保证谈话内容的安全。由于是使用RSA这种公钥密码体制,“服务器”需要对外发布公钥(算法不需要公布,RSA的算法大家都知道),自己留着私钥。“客户”通过某些途径拿到了“服务器”发布的公钥,客户并不知道私钥。“客户”具体是通过什么途径获取公钥的,我们后面再来说明,下面看一下双方如何进行保密的通信:

     

    2.1 第一回合:

    “客户”->“服务器”:你好

    “服务器”->“客户”:你好,我是服务器

    “客户”->“服务器”:????

    因为消息是在网络上传输的,有人可以冒充自己是“服务器”来向客户发送信息。例如上面的消息可以被黑客截获如下:

    “客户”->“服务器”:你好

    “服务器”->“客户”:你好,我是服务器

    “客户”->“黑客”:你好        // 黑客在“客户”和“服务器”之间的某个路由器上截获“客户”发给服务器的信息,然后自己冒充“服务器”

    “黑客”->“客户”:你好,我是服务器

    因此“客户”在接到消息后,并不能肯定这个消息就是由“服务器”发出的,某些“黑客”也可以冒充“服务器”发出这个消息。如何确定信息是由“服务器”发过来的呢?有一个解决方法,因为只有服务器有私钥,所以如果只要能够确认对方有私钥,那么对方就是“服务器”。因此通信过程可以改进为如下:

     

    2.2 第二回合:

    “客户”->“服务器”:你好

    “服务器”->“客户”:你好,我是服务器

    “客户”->“服务器”:向我证明你就是服务器

    “服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

          // 意这里约定一下,{} 表示RSA加密后的内容,[ | ]表示用什么密钥和算法进行加密,后面的示例中都用这种表示方式,例如上面的 {你好,我是服务器}[私钥|RSA]  就表示用私钥对“你好,我是服务器”进行加密后的结果。

    为了向“客户”证明自己是“服务器”, “服务器”把一个字符串用自己的私钥加密,把明文和加密后的密文一起发给“客户”。对于这里的例子来说,就是把字符串 “你好,我是服务器”和这个字符串用私钥加密后的内容 {你好,我是服务器}[私钥|RSA] 发给客户。

    “客户”收到信息后,她用自己持有的公钥解密密文,和明文进行对比,如果一致,说明信息的确是由服务器发过来的。也就是说“客户”把 {你好,我是服务器}[私钥|RSA] 这个内容用公钥进行解密,然后和“你好,我是服务器”对比。因为由“服务器”用私钥加密后的内容,由并且只能由公钥进行解密,私钥只有“服务器”持有,所以如果解密出来的内容是能够对得上的,那说明信息一定是从“服务器”发过来的。

    假设“黑客”想冒充“服务器”:

    “黑客”->“客户”:你好,我是服务器

    “客户”->“黑客”:向我证明你就是服务器

    “黑客”->“客户”:你好,我是服务器 {你好,我是服务器}[???|RSA]    //这里黑客无法冒充,因为他不知道私钥,无法用私钥加密某个字符串后发送给客户去验证。

    “客户”->“黑客”:????

    由于“黑客”没有“服务器”的私钥,因此它发送过去的内容,“客户”是无法通过服务器的公钥解密的,因此可以认定对方是个冒牌货!

    到这里为止,“客户”就可以确认“服务器”的身份了,可以放心和“服务器”进行通信,但是这里有一个问题,通信的内容在网络上还是无法保密。为什么无法保密呢?通信过程不是可以用公钥、私钥加密吗?其实用RSA的私钥和公钥是不行的,我们来具体分析下过程,看下面的演示:

     

    2.3 第三回合:

    “客户”->“服务器”:你好

    “服务器”->“客户”:你好,我是服务器

    “客户”->“服务器”:向我证明你就是服务器

    “服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

    “客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[公钥|RSA]

    “服务器”->“客户”:{你的余额是100元}[私钥|RSA]

    注意上面的的信息 {你的余额是100元}[私钥],这个是“服务器”用私钥加密后的内容,但是我们之前说了,公钥是发布出去的,因此所有的人都知道公钥,所以除了“客户”,其它的人也可以用公钥对{你的余额是100元}[私钥]进行解密。所以如果“服务器”用私钥加密发给“客户”,这个信息是无法保密的,因为只要有公钥就可以解密这内容。然而“服务器”也不能用公钥对发送的内容进行加密,因为“客户”没有私钥,发送个“客户”也解密不了。

    这样问题就又来了,那又如何解决呢?在实际的应用过程,一般是通过引入对称加密来解决这个问题,看下面的演示:

     

    2.4 第四回合:

    “客户”->“服务器”:你好

    “服务器”->“客户”:你好,我是服务器

    “客户”->“服务器”:向我证明你就是服务器

    “服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

    “客户”->“服务器”:{我们后面的通信过程,用对称加密来进行,这里是对称加密算法和密钥}[公钥|RSA]    //蓝色字体的部分是对称加密的算法和密钥的具体内容,客户把它们发送给服务器。

    “服务器”->“客户”:{OK,收到!}[密钥|对称加密算法]

    “客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[密钥|对称加密算法]

    “服务器”->“客户”:{你的余额是100元}[密钥|对称加密算法]

    在上面的通信过程中,“客户”在确认了“服务器”的身份后,“客户”自己选择一个对称加密算法和一个密钥,把这个对称加密算法和密钥一起用公钥加密后发送给“服务器”。注意,由于对称加密算法和密钥是用公钥加密的,就算这个加密后的内容被“黑客”截获了,由于没有私钥,“黑客”也无从知道对称加密算法和密钥的内容。

    由于是用公钥加密的,只有私钥能够解密,这样就可以保证只有服务器可以知道对称加密算法和密钥,而其它人不可能知道(这个对称加密算法和密钥是“客户”自己选择的,所以“客户”自己当然知道如何解密加密)。这样“服务器”和“客户”就可以用对称加密算法和密钥来加密通信的内容了。

     

    总结一下,RSA加密算法在这个通信过程中所起到的作用主要有两个:

    • 因为私钥只有“服务器”拥有,因此“客户”可以通过判断对方是否有私钥来判断对方是否是“服务器”。
    • 客户端通过RSA的掩护,安全的和服务器商量好一个对称加密算法和密钥来保证后面通信过程内容的安全。

    如果这里您理解了为什么不用RSA去加密通信过程,而是要再确定一个对称加密算法来保证通信过程的安全,那么就说明前面的内容您已经理解了。(如果不清楚,再看下2.3和2.4,如果还是不清楚,那应该是我们说清楚,您可以留言提问。)

    到这里,“客户”就可以确认“服务器”的身份,并且双方的通信内容可以进行加密,其他人就算截获了通信内容,也无法解密。的确,好像通信的过程是比较安全了。

     

    但是这里还留有一个问题,在最开始我们就说过,“服务器”要对外发布公钥,那“服务器”如何把公钥发送给“客户”呢?我们第一反应可能会想到以下的两个方法:

    a)把公钥放到互联网的某个地方的一个下载地址,事先给“客户”去下载。

    b)每次和“客户”开始通信时,“服务器”把公钥发给“客户”。

    但是这个两个方法都有一定的问题,

    对于a)方法,“客户”无法确定这个下载地址是不是“服务器”发布的,你凭什么就相信这个地址下载的东西就是“服务器”发布的而不是别人伪造的呢,万一下载到一个假的怎么办?另外要所有的“客户”都在通信前事先去下载公钥也很不现实。

    对于b)方法,也有问题,因为任何人都可以自己生成一对公钥和私钥,他只要向“客户”发送他自己的私钥就可以冒充“服务器”了。示意如下:

    “客户”->“黑客”:你好           //黑客截获“客户”发给“服务器”的消息

    “黑客”->“客户”:你好,我是服务器,这个是我的公钥    //黑客自己生成一对公钥和私钥,把公钥发给“客户”,自己保留私钥

    “客户”->“黑客”:向我证明你就是服务器

    “黑客”->“客户”:你好,我是服务器 {你好,我是服务器}[黑客自己的私钥|RSA]      //客户收到“黑客”用私钥加密的信息后,是可以用“黑客”发给自己的公钥解密的,从而会误认为“黑客”是“服务器”

    因此“黑客”只需要自己生成一对公钥和私钥,然后把公钥发送给“客户”,自己保留私钥,这样由于“客户”可以用黑客的公钥解密黑客的私钥加密的内容,“客户”就会相信“黑客”是“服务器”,从而导致了安全问题。这里问题的根源就在于,大家都可以生成公钥、私钥对,无法确认公钥对到底是谁的。 如果能够确定公钥到底是谁的,就不会有这个问题了。例如,如果收到“黑客”冒充“服务器”发过来的公钥,经过某种检查,如果能够发现这个公钥不是“服务器”的就好了。

    为了解决这个问题,数字证书出现了,它可以解决我们上面的问题。先大概看下什么是数字证书,一个证书包含下面的具体内容:

    • 证书的发布机构
    • 证书的有效期
    • 公钥
    • 证书所有者(Subject)
    • 签名所使用的算法
    • 指纹以及指纹算法

    证书的内容的详细解释会在后面详细解释,这里先只需要搞清楚一点,数字证书可以保证数字证书里的公钥确实是这个证书的所有者(Subject)的,或者证书可以用来确认对方的身份。也就是说,我们拿到一个数字证书,我们可以判断出这个数字证书到底是谁的。至于是如何判断的,后面会在详细讨论数字证书时详细解释。现在把前面的通信过程使用数字证书修改为如下:

     

    2.5 第五回合:

    “客户”->“服务器”:你好

    “服务器”->“客户”:你好,我是服务器,这里是我的数字证书        //这里用证书代替了公钥

    “客户”->“服务器”:向我证明你就是服务器

    “服务器”->“客户”:你好,我是服务器 {你好,我是服务器}[私钥|RSA]

    注意,上面第二次通信,“服务器”把自己的证书发给了“客户”,而不是发送公钥。“客户”可以根据证书校验这个证书到底是不是“服务器”的,也就是能校验这个证书的所有者是不是“服务器”,从而确认这个证书中的公钥的确是“服务器”的。后面的过程和以前是一样,“客户”让“服务器”证明自己的身份,“服务器”用私钥加密一段内容连同明文一起发给“客户”,“客户”把加密内容用数字证书中的公钥解密后和明文对比,如果一致,那么对方就确实是“服务器”,然后双方协商一个对称加密来保证通信过程的安全。到这里,整个过程就完整了,我们回顾一下:

     

    2.6 完整过程:

    step1: “客户”向服务端发送一个通信请求

    “客户”->“服务器”:你好

      

    step2: “服务器”向客户发送自己的数字证书。证书中有一个公钥用来加密信息,私钥由“服务器”持有

    “服务器”->“客户”:你好,我是服务器,这里是我的数字证书 

     

    step3: “客户”收到“服务器”的证书后,它会去验证这个数字证书到底是不是“服务器”的,数字证书有没有什么问题,数字证书如果检查没有问题,就说明数字证书中的公钥确实是“服务器”的。检查数字证书后,“客户”会发送一个随机的字符串给“服务器”用私钥去加密,服务器把加密的结果返回给“客户”,“客户”用公钥解密这个返回结果,如果解密结果与之前生成的随机字符串一致,那说明对方确实是私钥的持有者,或者说对方确实是“服务器”。

    “客户”->“服务器”:向我证明你就是服务器,这是一个随机字符串     //前面的例子中为了方便解释,用的是“你好”等内容,实际情况下一般是随机生成的一个字符串。

    “服务器”->“客户”:{一个随机字符串}[私钥|RSA]

     

    step4: 验证“服务器”的身份后,“客户”生成一个对称加密算法和密钥,用于后面的通信的加密和解密。这个对称加密算法和密钥,“客户”会用公钥加密后发送给“服务器”,别人截获了也没用,因为只有“服务器”手中有可以解密的私钥。这样,后面“服务器”和“客户”就都可以用对称加密算法来加密和解密通信内容了。

    “服务器”->“客户”:{OK,已经收到你发来的对称加密算法和密钥!有什么可以帮到你的?}[密钥|对称加密算法]

    “客户”->“服务器”:{我的帐号是aaa,密码是123,把我的余额的信息发给我看看}[密钥|对称加密算法]

    “服务器”->“客户”:{你好,你的余额是100元}[密钥|对称加密算法]

    …… //继续其它的通信

     

    2.7 其它问题:

    上面的过程已经十分接近HTTPS的真实通信过程了,完全可以按照这个过程去理解HTTPS的工作原理。但是我为了方便解释,上面有些细节没有说到,有兴趣的人可以看下这部分的内容。可以跳过不看,无关紧要。

     

    【问题1】

    上面的通信过程中说到,在检查完证书后,“客户”发送一个随机的字符串给“服务器”去用私钥加密,以便判断对方是否真的持有私钥。但是有一个问题,“黑客”也可以发送一个字符串给“服务器”去加密并且得到加密后的内容,这样对于“服务器”来说是不安全的,因为黑客可以发送一些简单的有规律的字符串给“服务器”加密,从而寻找加密的规律,有可能威胁到私钥的安全。所以说,“服务器”随随便便用私钥去加密一个来路不明的字符串并把结果发送给对方是不安全的。

    〖解决方法〗

    每次收到“客户”发来的要加密的的字符串时,“服务器”并不是真正的加密这个字符串本身,而是把这个字符串进行一个hash计算,加密这个字符串的hash值(不加密原来的字符串)后发送给“客户”,“客户”收到后解密这个hash值并自己计算字符串的hash值然后进行对比是否一致。也就是说,“服务器”不直接加密收到的字符串,而是加密这个字符串的一个hash值,这样就避免了加密那些有规律的字符串,从而降低被破解的机率。“客户”自己发送的字符串,因此它自己可以计算字符串的hash值,然后再把“服务器”发送过来的加密的hash值和自己计算的进行对比,同样也能确定对方是否是“服务器”。

     

    【问题2】

    在双方的通信过程中,“黑客”可以截获发送的加密了的内容,虽然他无法解密这个内容,但是他可以捣乱,例如把信息原封不动的发送多次,扰乱通信过程。

    〖解决方法〗

    可以给通信的内容加上一个序号或者一个随机的值,如果“客户”或者“服务器”接收到的信息中有之前出现过的序号或者随机值,那么说明有人在通信过程中重发信息内容进行捣乱,双方会立刻停止通信。有人可能会问,如果有人一直这么捣乱怎么办?那不是无法通信了? 答案是的确是这样的,例如有人控制了你连接互联网的路由器,他的确可以针对你。但是一些重要的应用,例如军队或者政府的内部网络,它们都不使用我们平时使用的公网,因此一般人不会破坏到他们的通信。 

     

    【问题3】

    在双方的通信过程中,“黑客”除了简单的重复发送截获的消息之外,还可以修改截获后的密文修改后再发送,因为修改的是密文,虽然不能完全控制消息解密后的内容,但是仍然会破坏解密后的密文。因此发送过程如果黑客对密文进行了修改,“客户”和“服务器”是无法判断密文是否被修改的。虽然不一定能达到目的,但是“黑客”可以一直这样碰碰运气。

    〖解决方法〗

    在每次发送信息时,先对信息的内容进行一个hash计算得出一个hash值,将信息的内容和这个hash值一起加密后发送。接收方在收到后进行解密得到明文的内容和hash值,然后接收方再自己对收到信息内容做一次hash计算,与收到的hash值进行对比看是否匹配,如果匹配就说明信息在传输过程中没有被修改过。如果不匹配说明中途有人故意对加密数据进行了修改,立刻中断通话过程后做其它处理。

     

    3. 证书的构成和原理

    3.1 证书的构成和原理

    之前已经大概说了一个证书由什么构成,但是没有仔细进行介绍,这里对证书的内容做一个详细的介绍。先看下一个证书到底是个什么东西,在windows下查看一个证书时,界面是这样的,我们主要关注一下Details Tab页,其中的内容比较长,我滚动内容后后抓了三个图,把完整的信息显示出来:

    certificateDetails

    里面的内容比较多——Version、Serial number、Signature algorithm 等等,挑几个重要的解释一下。

     

    ◆Issuer (证书的发布机构)

    指出是什么机构发布的这个证书,也就是指明这个证书是哪个公司创建的(只是创建证书,不是指证书的使用者)。对于上面的这个证书来说,就是指"SecureTrust CA"这个机构。

     

    ◆Valid from , Valid to (证书的有效期)

    也就是证书的有效时间,或者说证书的使用期限。 过了有效期限,证书就会作废,不能使用了。

     

    ◆Public key (公钥)

    这个我们在前面介绍公钥密码体制时介绍过,公钥是用来对消息进行加密的,第2章的例子中经常用到的。这个数字证书的公钥是2048位的,它的值可以在图的中间的那个对话框中看得到,是很长的一串数字。

     

    ◆Subject (主题)

    这个证书是发布给谁的,或者说证书的所有者,一般是某个人或者某个公司名称、机构的名称、公司网站的网址等。 对于这里的证书来说,证书的所有者是Trustwave这个公司。

     

    ◆Signature algorithm (签名所使用的算法)

    就是指的这个数字证书的数字签名所使用的加密算法,这样就可以使用证书发布机构的证书里面的公钥,根据这个算法对指纹进行解密。指纹的加密结果就是数字签名(第1.5节中解释过数字签名)。

     

    ◆Thumbprint, Thumbprint algorithm (指纹以及指纹算法)

    这个是用来保证证书的完整性的,也就是说确保证书没有被修改过,这东西的作用和2.7中说到的第3个问题类似。 其原理就是在发布证书时,发布者根据指纹算法(一个hash算法)计算整个证书的hash值(指纹)并和证书放在一起,使用者在打开证书时,自己也根据指纹算法计算一下证书的hash值(指纹),如果和刚开始的值对得上,就说明证书没有被修改过,因为证书的内容被修改后,根据证书的内容计算的出的hash值(指纹)是会变化的。 注意,这个指纹会使用"SecureTrust CA"这个证书机构的私钥用签名算法(Signature algorithm)加密后和证书放在一起。

     

    注意,为了保证安全,在证书的发布机构发布证书时,证书的指纹和指纹算法,都会加密后再和证书放到一起发布,以防有人修改指纹后伪造相应的数字证书。这里问题又来了,证书的指纹和指纹算法用什么加密呢?他们是用证书发布机构的私钥进行加密的。可以用证书发布机构的公钥对指纹和指纹算法解密,也就是说证书发布机构除了给别人发布证书外,他自己本身也有自己的证书。证书发布机构的证书是哪里来的呢???这个证书发布机构的数字证书(一般由他自己生成)在我们的操作系统刚安装好时(例如windows xp等操作系统),这些证书发布机构的数字证书就已经被微软(或者其它操作系统的开发机构)安装在操作系统中了,微软等公司会根据一些权威安全机构的评估选取一些信誉很好并且通过一定的安全认证的证书发布机构,把这些证书发布机构的证书默认就安装在操作系统里面了,并且设置为操作系统信任的数字证书。这些证书发布机构自己持有与他自己的数字证书对应的私钥,他会用这个私钥加密所有他发布的证书的指纹作为数字签名。

     

    3.2 如何向证书的发布机构去申请证书

    举个例子方便大家理解,假设我们公司"ABC Company"花了1000块钱,向一个证书发布机构"SecureTrust CA"为我们自己的公司"ABC Company"申请了一张证书,注意,这个证书发布机构"SecureTrust CA"是一个大家公认并被一些权威机构接受的证书发布机构,我们的操作系统里面已经安装了"SecureTrust CA"的证书。"SecureTrust CA"在给我们发布证书时,把Issuer,Public key,Subject,Valid from,Valid to等信息以明文的形式写到证书里面,然后用一个指纹算法计算出这些数字证书内容的一个指纹,并把指纹和指纹算法用自己的私钥进行加密,然后和证书的内容一起发布,同时"SecureTrust CA"还会给一个我们公司"ABC Company"的私钥给到我们。我们花了1000块钱买的这个证书的内容如下:

    ×××××××××××××××证书内容开始×××××××××××××××××

    Issuer : SecureTrust CA

    Subject : ABC Company

    Valid from : 某个日期

    Valid to: 某个日期

    Public Key : 一串很长的数字

    …… 其它的一些证书内容……

    {证书的指纹和计算指纹所使用的指纹算法}[SecureTrust CA的私钥|RSA]      //这个就是"SecureTrust CA"对这个证书的一个数字签名,表示这个证书确实是他发布的,有什么问题他会负责(收了我们1000块,出了问题肯定要负责任的)

    ×××××××××××××××证书内容结束×××××××××××××××××

                   // 记不记得前面的约定?{} 表示RSA加密后的内容,[ | ]表示用什么密钥和算法进行加密

     

    我们"ABC Company"申请到这个证书后,我们把证书投入使用,我们在通信过程开始时会把证书发给对方,对方如何检查这个证书的确是合法的并且是我们"ABC Company"公司的证书呢?首先应用程序(对方通信用的程序,例如IE、OUTLook等)读取证书中的Issuer(发布机构)为"SecureTrust CA" ,然后会在操作系统中受信任的发布机构的证书中去找"SecureTrust CA"的证书,如果找不到,那说明证书的发布机构是个水货发布机构,证书可能有问题,程序会给出一个错误信息。 如果在系统中找到了"SecureTrust CA"的证书,那么应用程序就会从证书中取出"SecureTrust CA"的公钥,然后对我们"ABC Company"公司的证书里面的指纹和指纹算法用这个公钥进行解密,然后使用这个指纹算法计算"ABC Company"证书的指纹,将这个计算的指纹与放在证书中的指纹对比,如果一致,说明"ABC Company"的证书肯定没有被修改过并且证书是"SecureTrust CA" 发布的,证书中的公钥肯定是"ABC Company"的。对方然后就可以放心的使用这个公钥和我们"ABC Company"进行通信了。

    ★这个部分非常重要,一定要理解,您可以重新回顾一下之前的两章“1、基础知识”和“ 2、一个加密通信过程的演化”,然后再来理解这部分的内容。如果您把这节的内容看了几遍还没有搞懂证书的工作原理,您可以留言指出我没有说清楚的内容,我好方便进行修正。

     

    3.3 证书的发布机构

    前面已经初步介绍了一下证书发布机构,这里再深入讨论一下。

    其实所有的公司都可以发布证书,我们自己也可以去注册一家公司来专门给别人发布证书。但是很明显,我们自己的专门发布证书的公司是不会被那些国际上的权威机构认可的,人家怎么知道你是不是个狗屁皮包公司?因此微软在它的操作系统中,并不会信任我们这个证书发布机构,当应用程序在检查证书的合法信的时候,一看证书的发布机构并不是操作系统所信任的发布机构,就会抛出错误信息。也就是说windows操作系统中不会预先安装好我们这个证书发布机构的证书,不信任我们这个发布机构。

      

    不受信任的证书发布机构的危害

    为什么一个证书发布机构受不受信任这么重要?我们举个例子。假设我们开了一个狗屁公司来为别人发布证书,并且我和微软有一腿,微软在他们的操作系统中把我设置为了受信任的证书发布机构。现在如果有个小公司叫Wicrosoft 花了10块钱让我为他们公司申请了一个证书,并且公司慢慢壮大,证书的应用范围也越来越广。然后有个奸商的公司JS Company想冒充Wicrosoft,于是给了我¥10000,让我为他们颁布一个证书,但是证书的名字(Subject)要写Wicrosoft,假如我为了这¥10000,真的把证书给了他们,那么他们以后就可以使用这个证书来冒充Wicrosoft了。

    如果是一个优秀的证书发布机构,比如你要向他申请一个名字叫Wicrosoft的证书,它会让你提供很多资料证明你确实可以代表Wicrosoft这个公司,也就是说他回去核实你的身份。证书发布机构是要为他发布出的证书负法律责任的。

      

    到这里,你可能会想,TMD,那我们自己就不能发布证书吗?就一定要花钱去申请?当然不是,我们自己也可以成立证书发布机构,但是需要通过一些安全认证等等,只是有点麻烦。另外,如果数字证书只是要在公司内部使用,公司可以自己给自己生成一个证书,在公司的所有机器上把这个证书设置为操作系统信任的证书发布机构的证书(这句话仔细看清楚,有点绕口),这样以后公司发布的证书在公司内部的所有机器上就可以通过验证了(在发布证书时,把这些证书的Issuer(发布机构)设置为我们自己的证书发布机构的证书的Subject(主题)就可以了)。但是这只限于内部应用,因为只有我们公司自己的机器上设置了信任我们自己这个所谓的证书发布机构,而其它机器上并没有事先信任我们这个证书发布机构,所以在其它机器上,我们发布的证书就无法通过安全验证。

     

    4. 在windows中对数字证书进行管理

    4.1 查看、删除、安装 数字证书

    我们在上一章中说到了,我们的操作系统中会预先安装好一些证书发布机构的证书,我们看下在windows中如何找到这些证书,步骤如下:

    1)开始菜单->运行,输入mmc,回车

    2)在打开的窗口中选择 File-> Add/Remove Snap-in…

    3)然后在弹出的对话框的 Standalone Tab页里面点击 Add… 按钮

    4)在弹出的对对话框中选择 certificates 后点击 Add 按钮

    具体的步骤如下图所示:

     

    上面的步骤结束后,会又弹出一个对话框,里面有三个单选按钮如下:

    • My user account
    • Service account
    • Computer account

    可以选择第一或者第三个选项,用来查看当前用户的证书或整个计算里面安装的证书。我们这里就默认选择第一个,平时一般安装证书的时候都会给所有用户安装,所以选择第一个和第三个选项看到的证书会差不多。我们在左边的导航树中选中受信任的证书发布机构(Trusted Root Certificate Authorities),然后点击下面的证书(Certificates),在右边的区域中就可以看到所有的受信任的证书发布机构的证书。

    trustedcaAuth

    注意上面的图片中,右边我们选中的这个证书发布机构"SecureTrust CA",我们前面在第3章3.2节中举例子的时候,就是去向这个证书发布机构申请的证书,由于我们申请的证书是这个机构发布的,所以应用程序在检查我们的证书的发布机构时(会检查我们证书的签名,确认是该机构发布的证书),就会发现是可以信任的证书发布机构,从而就会相信我们证书的真实性。

    删除数字证书很简单,直接在右边的列表中右键然后删除就可以了。

    数字证书的安装也比较简单,直接双击数字证书文件,会打开数字证书,对话框下面会有一个Install Certificate按钮,点击后就可以根据向导进行安装,如下图所示:

    installCertificate

    这个证书是我自己生成的测试证书,在证书的导入向导里面,它会让你选择导入到什么位置,如果是一个我们自己信任的证书发布机构自己的证书,只要导入到Certificate Authorities就可以了。Trusted Root Certificate Authorities, Intermediate Certification Authorities, Third-Party Root Certification Authorities 都是可以的,他们只是对证书的发布机构做了一个分类,还有一些其它的证书类型,例如Personal(个人证书)等等,具体就不介绍了。安装的时候一般来说可以用默认的选择项一直"下一步"到底。

     

    4.2 如何自己创建证书

    每个证书发布机构都有自己的用来创建证书的工具,当然,具体他们怎么去创建一个证书的我也不太清楚,不同类型的证书都有一定的格式和规范,我没有仔细去研究过这部分内容。 微软为我们提供了一个用来创建证书的工具makecert.exe,在安装Visual Studio的时候会安装上。如果没有安装也无所谓,可以上网去下一个,搜索makecert就可以了。可以直接从我的博客下载,这是链接

    向一些正规的证书发布机构申请证书一般是要收费的(因为别人要花时间检查你的身份,确认有没有同名的证书等等),这里我们看下如何自己创建一个证书,为后面在IIS中配置Https做准备。

    我们用到的是makecert这个工具,微软有很详细的使用帮助,我这里只做一个简单的解释,详细的各种参数和使用方法请查看MSDN的makecert的帮助。但是里面有些参数说得不够清楚,而且还有遗漏的,可以参看我后面的解释作为一个补充。

     

    先看下makecert最简单的使用方式:

    makecert.exe test.cer

    上面的命令会在makecert.exe所在的目录生成一个证书文件test.cer的数字证书文件。可以双击证书打开,看看证书的内容如下:

    testCertificate1

    证书的发布机构是"Root Agency",证书的主题(证书发布给谁)是"Joe’s-Software-Emporium",因为我们没有指定把证书发布给谁,makecert自己给我们随便生成了一个公司的名字。另外还指定了公钥、签名算法(用来解密签名)、指纹和指纹算法等。

    注意,因为这个证书是由微软的工具生成的,严格来说它没什么发布机构,所以微软虚拟了一个叫做"Root Agency"的发布机构,默认情况下,windows里面安装了这个所谓的证书发布机构的证书,但是这证书默认情况下不是受信任的,原因很简单,这样做大家都可以用makecert来制作合法的数字证书了。如果我们自己硬是要,也可以把它设置为受信任的。

     

    下面我们看下其它的参数,比如我们要给网站 www.jefferysun.com 生成一个证书MyCA.cer,假设我们把makecert.exe放在C:盘下,命令行如下:

    makecert -r -pe -n "CN=10.30.146.206" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

    C:\> makecert.exe –pe -r  –n  "CN=www.jefferysun.com" -ss my -sr LocalMachine -a sha1 -len 2048  MyCA.cer

    解释一下makecert的常用参数的意思:

    • -n 指定主题的名字,这个是有固定的格式的, CN=主题名字 ,CN应该是Certificate Name的缩写。我这里的主题的名字就是我们的IIS所在机器的IP。这里可以指定一些主题的其它附加信息,例如 O= *** 表示组织信息等等。
    • -r 创建自签署证书,意思就是说在生成证书时,将证书的发布机构设置为自己。
    • -pe 将所生成的私钥标记为可导出。注意,服务器发送证书给客户端的时候,客户端只能从证书里面获取公钥,私钥是无法获取的。如果我们指定了这个参数,证书在安装在机器上后,我们还可以从证书中导出私钥,默认情况下是不能导出私钥的。正规的途径发布的证书,是不可能让你导出私钥的。
    • -b –e 证书的有效期
    • -ss 证书的存储名称,就是windows证书存储区的目录名,如果不存在在的话就创建一个。
    • -sr 证书的存储位置,只有currentuser(默认值)或 localmachine两个值。
    • -sv 指定保存私钥的文件,文件里面除了包含私钥外,其实也包含了证书。这个文件是需要保密的,这个文件在服务端配置时是需要用到的。
    • 这个CN=10.30.146.206要与自己的服务器相对应,要不然在配置HTTPS的时候会出现错误
    • -a 指定签名算法,必须是md5或rsa1。(还记得签名算法的作用不?可以看一下3章的第1节中关于签名算法的介绍)
    • -in 指定证书发布机构的名称
    • -len 这个参数在中文的帮助文档中好像没有提到,但是这个其实很重要,用于指定公钥的位数,越大越安全,默认值是1024,推荐2048。我试了下,这个不为1024的倍数也是可以的。
    展开全文
  • 数字证书CA的详细理解

    千次阅读 2017-03-14 16:01:00
     考虑到证书体系的相关知识比较枯燥、晦涩。俺先拿一个通俗的例子来说事儿。  ◇ 普通的介绍信  想必大伙儿都听说过介绍信的例子吧?假设 A 公司的张三先生要到 B 公司去拜访,但是 B 公司的所有人都不认识他,他...

    原文作者:编程思想 链接http://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html 

    ★ 先说一个通俗的例子

      考虑到证书体系的相关知识比较枯燥、晦涩。俺先拿一个通俗的例子来说事儿。

      ◇ 普通的介绍信

      想必大伙儿都听说过介绍信的例子吧?假设 A 公司的张三先生要到 B 公司去拜访,但是 B 公司的所有人都不认识他,他咋办捏?常用的办法是带公司开的一张介绍信,在信中说:兹有张三先生前往贵公司办理业务,请给予接洽......云云。然后在信上敲上A公司的公章。

      张三先生到了 B 公司后,把介绍信递给 B 公司的前台李四小姐。李小姐一看介绍信上有 A 公司的公章,而且 A 公司是经常和 B 公司有业务往来的,这位李小姐就相信张先生不是歹人了。

      说到这,爱抬杠的同学会问了:万一公章是伪造的,咋办捏?在此,俺要先声明,在本例子中,先假设公章是难以伪造的,否则俺的故事没法说下去鸟。

      ◇ 引入中介机构的介绍信

      好,回到刚才的话题。如果和 B 公司有业务往来的公司很多,每个公司的公章都不同,那前台就要懂得分辨各种公章,非常滴麻烦。所以,有某个中介公司 C,发现了这个商机。C公司专门开设了一项“代理公章”的业务。

      今后,A 公司的业务员去 B 公司,需要带2个介绍信:

      介绍信1

      含有 C 公司的公章及 A 公司的公章。并且特地注明:C 公司信任 A 公司。

      介绍信2

      仅含有 A 公司的公章,然后写上:兹有张三先生前往贵公司办理业务,请给予接洽......云云。

      某些不开窍的同学会问了,这样不是增加麻烦了吗?有啥好处捏?

      主要的好处在于,对于接待公司的前台,就不需要记住各个公司的公章分别是啥样子的;他/她只要记住中介公司 C 的公章即可。当他/她拿到两份介绍信之后,先对介绍信1的 C 公章,验明正身;确认无误之后,再比对介绍信1和介绍信2的两个 A 公章是否一致。如果是一样的,那就可以证明介绍信2是可以信任的了。

      ★ 相关专业术语的解释

      费了不少口水,终于说完了一个俺自认为比较通俗的例子。如果你听到到这,还是想不明白这个例子在说啥,那后续的内容,就不必浪费时间听了 :(

      下面,俺就着上述的例子,把相关的名词,作一些解释。

      ◇ 什么是证书?

      “证书”洋文也叫“digital certificate”或“public key certificate”(专业的解释看“这里”)。

      它是用来证明某某东西确实是某某东西的东西(是不是像绕口令?)。通俗地说,证书就好比例子里面的公章。通过公章,可以证明该介绍信确实是对应的公司发出的。

      理论上,人人都可以找个证书工具,自己做一个证书。那如何防止坏人自己制作证书出来骗人捏?请看后续 CA 的介绍。

      ◇ 什么是CA?

      CA是Certificate Authority的缩写,也叫“证书授权中心”。(专业的解释看“这里”)

      它是负责管理和签发证书的第三方机构,就好比例子里面的中介——C 公司。一般来说,CA必须是所有行业和所有公众都信任的、认可的。因此它必须具有足够的权威性。就好比A、B两公司都必须信任C公司,才会找 C 公司作为公章的中介。

      ◇ 什么是CA证书?

      CA 证书,顾名思义,就是CA颁发的证书。

      前面已经说了,人人都可以找工具制作证书。但是你一个小破孩制作出来的证书是没啥用处的。因为你不是权威的CA机关,你自己搞的证书不具有权威性。

      这就好比上述的例子里,某个坏人自己刻了一个公章,盖到介绍信上。但是别人一看,不是受信任的中介公司的公章,就不予理睬。坏蛋的阴谋就不能得逞啦。

      文本后续提及的证书,若无特殊说明,均指 CA 证书。

      ◇ 什么是证书之间的信任关系?

      在俺的例子里谈到,引入中介后,业务员要同时带两个介绍信。第一个介绍信包含了两个公章,并注明,公章C信任公章A。证书间的信任关系,就和这个类似。就是用一个证书来证明另一个证书是真实可信滴。

      ◇ 什么是证书信任链?

      实际上,证书之间的信任关系,是可以嵌套的。比如,C 信任 A1,A1 信任 A2,A2 信任 A3......这个叫做证书的信任链。只要你信任链上的头一个证书,那后续的证书,都是可以信任滴。

      ◇ 什么是根证书?

      “根证书”的洋文叫“root certificate”,专业的解释看“这里”。为了说清楚根证书是咋回事,再来看个稍微复杂点的例子。

      假设 C 证书信任 A 和 B;然后 A 信任 A1 和 A2;B 信任 B1 和 B2。则它们之间,构成如下的一个树形关系(一个倒立的树)。

      处于最顶上的树根位置的那个证书,就是“根证书”。除了根证书,其它证书都要依靠上一级的证书,来证明自己。那谁来证明“根证书”可靠捏?实际上,根证书自己证明自己是可靠滴(或者换句话说,根证书是不需要被证明滴)。

      聪明的同学此刻应该意识到了:根证书是整个证书体系安全的根本。所以,如果某个证书体系中,根证书出了问题(不再可信了),那么所有被根证书所信任的其它证书,也就不再可信了。这个后果是相当相当滴严重(简直可以说是灾难性的),具体在下一个帖子里介绍。

      ★ 证书有啥用?

      CA 证书的作用有很多,俺为了节省口水,只列出常用的几个。

      ◇ 验证网站是否可信(针对HTTPS)

      通常,我们如果访问某些敏感的网页(比如用户登录的页面),其协议都会使用 HTTPS 而不是 HTTP。因为 HTTP 协议是明文的,一旦有坏人在偷窥你的网络通讯,他/她就可以看到网络通讯的内容(比如你的密码、银行帐号、等);而 HTTPS 是加密的协议,可以保证你的传输过程中,坏蛋无法偷窥。

      但是,千万不要以为,HTTPS 协议有了加密,就可高枕无忧了。俺再举一个例子来说明,光有加密是不够滴。假设有一个坏人,搞了一个假的网银的站点,然后诱骗你上这个站点。假设你又比较单纯,一不留神,就把你的帐号,口令都输入进去了。那这个坏蛋的阴谋就得逞鸟。

      为了防止坏人这么干,HTTPS 协议除了有加密的机制,还有一套证书的机制。通过证书来确保,某个站点确实就是某个站点。

      有了证书之后,当你的浏览器在访问某个 HTTPS 网站时,会验证该站点上的 CA 证书(类似于验证介绍信的公章)。如果浏览器发现该证书没有问题(证书被某个根证书信任、证书上绑定的域名和该网站的域名一致、证书没有过期),那么页面就直接打开;否则的话,浏览器会给出一个警告,告诉你该网站的证书存在某某问题,是否继续访问该站点?为了形象起见,下面给出 IE 和 Firefox 的抓图:

      大多数知名的网站,如果用了 HTTPS 协议,其证书都是可信的(也就不会出现上述警告)。所以,今后你如果上某个知名网站,发现浏览器跳出上述警告,你就要小心啦!

      ◇ 验证某文件是否可信(是否被篡改)

      证书除了可以用来验证某个网站,还可以用来验证某个文件是否被篡改。具体是通过证书来制作文件的数字签名。制作数字签名的过程太专业,咱就不说了。后面专门告诉大家如何验证文件的数字签名。考虑到大多数人用 Windows 系统,俺就拿 Windows 的例子来说事儿。

      比如,俺手头有一个 Firefox 的安装文件(带有数字签名)。当俺查看该文件的属性,会看到如下的界面。眼神好的同学,会注意到到上面有个“数字签名”的标签页。如果没有出现这个标签页,就说明该文件没有附带数字签名。

      选择该标签页,看到如下界面。

      顺便说一下,某些数字签名中没有包含“邮件地址”,那么这一项会显示“不可用”;同样的,某些数字签名没有包含“时间戳”,也会显示“不可用”。不要紧张,这里显示的“不可用”跟数字签名的有效性没关系

      一般来说,签名列表中,有且仅有一个签名。选中它,点“详细信息”按钮。跳出如下界面:

      通常这个界面会显示一行字:“该数字签名正常”(图中红圈标出)。如果有这行字,就说明该文件从出厂到你手里,中途没有被篡改过(是原装滴、是纯洁滴)。

      如果该文件被篡改过了(比如,感染了病毒、被注入木马),那么对话框会出现一个警告提示“该数字签名无效”(图中红圈标出)。界面如下:

      不论签名是否正常,你都可以点“查看证书”按钮。这时候,会跳出证书的对话框。如下:

     

      从后一个界面,可以看到俺刚才说的证书信任链。图中的信任链有3层:

      第1层是根证书(Thawte Premium Server CA)。

      第2层是 Thawte 专门用来签名的证书。

      第3层是 Mozilla 自己的证书。 

      目前大多数知名的公司(或组织机构),其发布的可执行文件(比如软件安装包、驱动程序、安全补丁),都带有数字签名。你可以自己去看一下。

      建议大伙儿在安装软件之前,都先看看是否有数字签名?如果有,就按照上述步骤验证一把。一旦数字签名是坏的,那可千万别装。

      ★ 总结

      费了半天口舌,大致介绍了 CA 证书相关的概念。想更深入了解这方面知识的同学,可以找些信息安全或密码学方面的资料,继续钻研。

      如果哪个同学觉得俺有说得不对的地方,或者有需要补充的内容,欢迎给俺写邮件(program.think@gmail.com)。

      *******

      版权声明

      本博客所有的原创文章,作者皆保留版权。转载必须包含本声明,保持本文完整,并以超链接形式注明作者编程随想和本文原始地址:

      http://program-think.blogspot.com/2010/02/introduce-digital-certificate-and-ca.html

    展开全文
  • CA证书

    万次阅读 2018-01-30 19:02:59
    1. CA证书理解?CA证书的作用?CA证书顾名思义就是由CA(Certification Authority)机构发布的数字证书。要对CA证书完全理解及其作用,首先要理解SSL。SSL(security sockets layer,安全套接层)是为网络通信提供...

    1. CA证书理解?CA证书的作用?

    CA证书顾名思义就是由CA(Certification Authority)机构发布的数字证书。要对CA证书完全理解及其作用,首先要理解SSL。SSL(security sockets layer,安全套接层)是为网络通信提供安全及数据完整性的一种安全协议。SSL3.0版本以后又被称为TLS。SSL位于TCP与各应用层之间,是操作系统向外提供的API。SSL如何保证网络通信的安全和数据的完整性呢?就是采用了两种手段:身份认证和数据加密。首先身份认证就需要用到CA证书了。先了解CA证书具体包括哪些内容:

    颁发者
    使用者
    版本
    签名算法
    签名哈希算法
    使用者
    公钥
    指纹
    指纹算法
    ……
    上述中颁发者、使用者、版本等内容好理解,颁发者就是CA机构,下面会讲到。对于签名算法、签名哈希算法的理解,首先要先理解签名是什么东东?联系到实际情况,当我们向某机构提供报告时,往往在报告最后加上个人的名字,以表示该报告是我本人的。签名在网络通讯中的应用称为数字签名,当服务器向客户端发送信息时,会将报文生成报文摘要,同时对报文摘要进行hash计算,得到hash值,然后对hash值进行加密,然后将加密的hash值放置在报文后面,这个加密后的hash值就称为签名。服务器将报文、签名和数字证书一同发送给客户端。客户端收到这些信息后,会首先验证签名,利用签名算法对签名进行解密,得到报文摘要的hash值,然后将得到的报文生成报文摘要并利用签名hash算法生成新的hash值,通过对比这两个hash值是否一致,就能判断信息是否完整,是否是由真正的服务器发送的。可知签名有两个作用确认消息发送方可靠,确认消息完整准确。

    上面提到了hash值的加密,我们还需要理解SSL的加密机制,在使用SSL的网络通讯过程中,消息在请求和响应中都是加密传送的。首先要知道加密算法分为两种:对称加密和非对称加密。对称加密就是发送双发使用相同的密钥对消息进行加解密,常见的对称加密为DES、3DES,AES等。非对称加密是发送双方各自拥有一对公钥私钥,其中公钥是公开的,私钥是保密的。当发送方向接收方发送消息时,发送方利用接收方的公钥对消息进行加密,接收方收到消息后,利用自己的私钥解密就能得到消息的明文。其中非对称加密方法有RSA、Elgamal、ECC等。此处只是简单了说明了这两种加密机制的过程,若要深入理解它们的原理、过程请搜索相应的资料,很容易搜索到。

    好了,了解了签名原理和两种加密机制,我们继续理解网络通讯中是怎么利用CA证书进行身份认证的?客户端与服务端需要经过一个握手的过程才能完成身份认证,建立一个安全的连接。握手的过程如下:

    1. 客户端访问服务器(比如:https://www.12306.cn),发送ssl版本、客户端支持的加密算法、随机数等消息。
    2. 服务器向客户端发送ssl版本、随机数、加密算法、证书(证书出现了)等消息。
    3. 客户端收到消息后,判断证书是否可信(如何判断可信,看下文介绍),若可信,则继续通信,发送消息包括:向服务器发送一个随机数,从证书中获取服务器端的公钥,对随机数加密;编码改变通知,表示随后信息都将使用双方协定的加密方法和密钥发送;客户端握手结束通知。
    4. 服务器端对数据解密得到随机数,发送消息:编码改变通知,表示随后信息都将使用双方协定的加密方法和密钥发送。

    以上就是整个握手的过程,在第三步实际上就完成了身份的认证,第四、五步是进行密钥的商定,因为非对称加密算法对数据加密非常慢,效率低,而对称加密加密效率很高,因此在整个握手过程要生成一个对称加密密钥,然后数据传输中使用对称加密算法对数据加密。可知ssl整个握手过程包括身份认证、密钥商定。上述讲述ssl的握手过程比较简单,想要深入理解ssl原理,下面这篇博文讲的不错:
    https://segmentfault.com/a/1190000002554673
    一定要看上面的博文,否则无法彻底理解证书使用的原理。

    2.客户端是如何验证CA证书是可信任的?

    一般来说,现在公共网站数据传输都是使用SSL,即通过https协议访问。Https就是http加SSL。在上面SSL握手过程中,客户端是如何验证服务器发送的CA证书呢?我们以12306网站为例进行说明,此时,客户端就是浏览器,如果我们是第一次访问12306网站,使用https://www.12306.cn地址访问,返回如下结果:
    这里写图片描述

    提示此网站的安全证书有问题,说明证书不可信,如果我们忽略证书不可信,继续访问网站,打开12306网页,在首页提供一个根证书的下载,见下页面:

    这里写图片描述

    下载根证书,安装完毕,再次访问12036网站,就不会提示网站的安全证书有问题了。这是什么机制呢?

    打开【工具】菜单(360浏览器为例),然后选择【内容】选项卡,点击【证书】按钮,打开证书窗口,选择【中级证书颁发机构】,会看到已经安装的12306的证书:

    这里写图片描述

    只要安装上12306证书,就说明证书是可信的。使用https协议访问时,服务器发送证书向浏览器时,首先查找该证书是否已在信任列表中,然后对证书进行校验,校验成功,那么就证明证书是可信的。另外,证书的认证是安装证书链执行的,证书链的意思是有一个证书机构A,A生成证书B,B也可以生成证书C,比如在证书窗口中有一个360证书,见下图:

    这里写图片描述

    360证书的颁发者是certification authority of wosign,在【受信任的根证书颁发机构】中,我们会看到该证书:见下图,

    这里写图片描述

    也就是说,certification authority of wosign生成360证书,360可以生成其它的证书。A证书或者certification authority of wosign证书在整个证书链上就被称为根证书,证书验证的机制是只要根证书是受信任的,那么它的子证书都是可信的。比如说,我们使用https协议访问了需要360证书的网站,即使我们不安装360证书,那么网站也不会提示证书不安全,因为,生成360证书的根证书certification authority of wosign证书,在受信任的证书列表中。如果一个证书的根证书是不可信的,那么这个证书肯定也是不可信任的。

    由以上可知,根证书在证书验证中极其重要,而且,根证书是无条件信任的,只要我们将根证书安装上,就说明我们对根证书是信任的。比如我们安装12306的根证书,是出于我们对国家的信任,对网站的信任,我们才放心安装这个根证书。对于一些不安全的网站的证书,一定要慎重安装。

    另外需要知道的是,【受信任的根证书颁发机构】中的证书是windows预先安装的一些证书,都是国际上很有权威的证书机构,他们证书的生成都有很严格的流程,因此他们的证书被认为是安全,就像我们相信银行是安全,所以把钱存入到银行。

    3.有哪些CA机构?

    世界上较早的数字认证中心是美国的verisign公司,在windows的证书窗口中可以看到好多verisign公司生成的证书,见下图:

    这里写图片描述

    另外还有加拿大的ENTRUST公司,也是很著名的证书机构。中国的安全认证体系分为金融CA和非金融CA。在金融CA方面,根证书由中国人民银行管理,在非金融CA方面,由中国电信负责。中国CA又可分为行业性CA和区域性CA,行业性CA中影响最大是中国金融认证中心和中国电信认证中国;区域性CA主要是以政府为背景,以企业机制运行,其中广东CA中心和上海CA中影响最大。

    4.自签名证书的如何生成、安装?

    有时候,我们在内部系统传输数据需要使用SSL协议,对数据加密,但是我们又不想花钱去申请CA,这个时候可以使用自签名CA,实现数据加密传输的功能。首先要明确一点就是自签名证书是不安全的,存在安全漏洞,具体看下面的博文介绍:

    为什么”自签名SSL证书”不安全?
    https://www.wosign.com/FAQ/selfsigned_SSL_insecure.htm

    自签名证书使用jdk中的keytool生成即可,看似神秘,但实际上比较简单,见下博文:

    如何利用keytool工具生成数字证书
    https://jingyan.baidu.com/article/b0b63dbfe18eff4a483070f4.html

    自签名证书的安装也很简单,见下博文:

    添加自签发的 SSL 证书为受信任的根证书
    https://cnzhx.net/blog/self-signed-certificate-as-trusted-root-ca-in-windows/

    在java编程中,使用socket网络编程,实现SSL协议,对服务器的证书需要导入到客户端的秘钥库中,这样才能完成自动认证,具体实现见下博文:

    JAVA SSL SOCKET通信服务器端客户端证书双向认证
    http://blog.csdn.net/matt8/article/details/45071815

    展开全文
  • 细说 CA证书

    千次阅读 2019-04-07 11:41:10
    CA,Catificate Authority,它的作用就是提供证书(即服务器证书,由域名、公司信息、序列号和签名信息组成)加强服务端和客户端之间信息交互的安全性,以及证书运维相关服务。任何个体/组织都可以扮演 CA 的角色,...

    CA,Catificate Authority,它的作用就是提供证书(即服务器证书,由域名、公司信息、序列号和签名信息组成)加强服务端和客户端之间信息交互的安全性,以及证书运维相关服务。任何个体/组织都可以扮演 CA 的角色,只不过难以得到客户端的信任,能够受浏览器默认信任的 CA 大厂商有很多,其中 TOP5 是 Symantec、Comodo、Godaddy、GolbalSign 和 Digicert。

    服务器证书分类

    可以通过两个维度来分类,一个是商业角度,一个是业务角度。

      单域名 多域名 泛域名 多泛域名
    DV 支持 不支持
    OV 支持
    EV 支持 不支持
    举例 www.barretlee.com www.barretlee.com
    www.xiaohuzige.com
    www.barret.cc
    *.barretlee.com *.barretlee.com
    *.xiaohuzige.com
    *.barret.cc

    需要强调的是,不论是 DV、OV 还是 EV 证书,其加密效果都是一样的! 它们的区别在于:

    • DV(Domain Validation),面向个体用户,安全体系相对较弱,验证方式就是向 whois 信息中的邮箱发送邮件,按照邮件内容进行验证即可通过;
    • OV(Organization Validation),面向企业用户,证书在 DV 证书验证的基础上,还需要公司的授权,CA 通过拨打信息库中公司的电话来确认;
    • EV(Extended Validation),打开 Github 的网页,你会看到 URL 地址栏展示了注册公司的信息,这会让用户产生更大的信任,这类证书的申请除了以上两个确认外,还需要公司提供金融机构的开户许可证,要求十分严格。

    OV 和 EV 证书相当昂贵,使用方可以为这些颁发出来的证书买保险,一旦 CA 提供的证书出现问题,一张证书的赔偿金可以达到 100w 刀以上。

    CA 的作用

    前文 HTTPS证书生成原理和部署细节 提到如果本地生成公/私钥对和对应未签证的证书,如果使用的证书没有签证,或者未在浏览器受信的 CA 签证,你会看到下图的问题:

    上图出现的错误是 net:ERR_CERT_AUTHORITY_INVALID,我们生成证书和公/私钥对的流程都是正确的,但是浏览器不认这张证书,并且提示证书授权不通过;如果通过其他与 Common Name 不同的域名去访问,如我注册的时候使用的 localhost,但是访问的时候用的 127.0.0.1,还会报出这样的错误:

    错误码为 net:ERR_CERT_COMMON_NAME_INVALID,意思是 Common Name 不匹配,具体校验流程可以在浏览器的 DevTools 中看到:

    从上面几张图,可以大致了解 CA 和证书会做哪些事情,证书由域名、公司信息、序列号和签名信息组成,当我们通过 HTTPS 访问页面时,浏览器会主动验证证书信息是否匹配,也会验证证书是否有效。

    CA 有权给所有的域名签发证书,如它可以私自给我的网站签发一张 www.barretlee.com的证书,并且可以拿着新证书拦截网页流量(当然,前提是这个 CA 是浏览器认证的权威 CA),那我的网站可能就很不安全了,对拥新证书的人来说,我的网站等同于在 HTTP 下进行通讯。

    评估 CA 供应商

    CA 供应商很多,提供服务的侧重点可能也存在一些差异,比如很多 CA 都没有提供证书吊销的服务,这一点对于安全性要求很高的企业来说是完全不能接受的,那么对 CA 供应商的评估需要注意写什么呢?

    1. 内置根

    所谓内置根,就是 CA 的根证书内置到各种通用的系统/浏览器中,只有根证书的兼容性够强,它所能覆盖的浏览器才会越多。

    2. 安全体系

    两个指标可以判断 CA 供应商是否靠谱,一是看价格,价格高自然有它的理由,必然提供了全套的安全保障体系;二是看黑历史,该 CA 供应商有没有爆出过什么漏洞,比如之前的 DigiNotar,被伊朗入侵,签发了 500 多张未授权的证书,结果直接被各系统/浏览器将其根拉入黑名单,毫无疑问公司直接倒闭。

    3. 核心功能和扩展功能

    这就需要从业务上考虑了,不同的规模的企业、不同的业务对证书的要求不一样,比如证书是否会考虑无 SNI 支持的浏览器问题,是否支持在 reissue 的时候添加域名,是否支持 CAA,是否支持短周期证书等等。

    4. 价格

    企业完全没必要购买 Github 那样的 EV 证书,太昂贵,而且一般的企业也未必能够申请到这样的证书。供应商很大,价格可以好好评估下,不一定要最贵,最适合的就行。

    自建 Root CA

    OpenSSL 是一个免费开源的库,它提供了构建数字证书的命令行工具,其中一些可以用来自建 Root CA。

    很多网站都希望用户知道他们建立的网络通道是安全的,所以会想 CA 机构购买证书来验证 domain,所以我们也可以在很多 HTTPS 的网页地址栏看到一把小绿锁。

    然而在一些情况下,我们没必要去 CA 机构购买证书,比如在内网的测试环境中,为了验证 HTTPS 下的一些问题,我们不需要部署昂贵的证书,这个时候自建 Root CA,给自己颁发证书就显得很有价值了。

    本节内容较多,主要是代码演示生成证书和验证的过程,可以跳过看下一节,直接看 这里

    • git clone //github.com/barretlee/autocreate-ca.git
    • 依次执行 install-rootCA.shinstall-intermediateCA.sh 和 install-websiteConfig.sh

    首先找到一个放置证书的文件夹,比如 /root/ca 下,下方的测试也在改目录下,如果你要更换其他目录,记得替换下文中的目录地址。

    创建 root pair

    扮演 CA 角色,就意味着要管理大量的 pair 对,而原始的一对 pair 对叫做 root pair,它包含了 root key(ca.key.pen)和 root certificate(ca.cert.pem)。通常情况下,root CA 不会直接为服务器或者客户端签证,它们会先为自己生成几个中间 CA(intermediate CAs),这几个中间 CA 作为 root CA 的代表为服务器和客户端签证。

    注意:一定要在绝对安全的环境下创建 root pair,可以断开网络、拔掉网线和网卡,当然,如果是测试玩一玩就不用这么认真了。

    设定文件夹结构,并且配置好 openssl 设置:

    $ cd /root/ca
    $ mkdir certs crl newcerts private
    $ chmod 700 private
    $ touch index.txt
    $ echo 1000 > serial
    $ wget -O /root/ca/openssl.cnf \ 
        //raw.githubusercontent.com/barretlee/autocreate-ca/master/cnf/root-ca
    

    创建 root key,密码可为空,设定权限为只可读:

    $ cd /root/ca
    $ openssl genrsa -aes256 -out private/ca.key.pem 4096
    
    Enter pass phrase for ca.key.pem: secretpassword
    Verifying - Enter pass phrase for ca.key.pem: secretpassword
    
    $ chmod 400 private/ca.key.pem

    创建 root cert,权限设置为可读:

    $ cd /root/ca
    $ openssl req -config openssl.cnf \
          -key private/ca.key.pem \
          -new -x509 -days 7300 -sha256 -extensions v3_ca \
          -out certs/ca.cert.pem
    
    Enter pass phrase for ca.key.pem: secretpassword
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    -----
    Country Name (2 letter code) [XX]:CN
    State or Province Name []:Zhejiang
    Locality Name []:
    Organization Name []:Barret Lee
    Organizational Unit Name []:Barret Lee Certificate Authority
    Common Name []:Barret Lee Root CA
    Email Address []:
    
    $ chmod 444 certs/ca.cert.pem

    验证证书:

    $ openssl x509 -noout -text -in certs/ca.cert.pem

    正确的输出应该是这样的:

    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number:
                87:e8:c0:a0:4b:e2:12:5d
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: C=CN, ST=Zhejiang, O=Barret Lee, OU=Barret Lee Certificate Authority, CN=Barret Lee Root CA
            Validity
                Not Before: Apr 23 05:46:36 2016 GMT
                Not After : Apr 18 05:46:36 2036 GMT
            Subject: C=CN, ST=Zhejiang, O=Barret Lee, OU=Barret Lee Certificate Authority, CN=Barret Lee Root CA
            Subject Public Key Info:
                Public Key Algorithm: rsaEncryption
                RSA Public Key: (4096 bit)
                    Modulus (4096 bit):
                        // ...
                    Exponent: 65537 (0x10001)
            X509v3 extensions:
                X509v3 Subject Key Identifier:
                    E5:2D:B8:2B:DC:88:FE:CE:DA:93:D8:6F:2E:74:04:D2:39:E7:C8:03
                X509v3 Authority Key Identifier:
                    keyid:E5:2D:B8:2B:DC:88:FE:CE:DA:93:D8:6F:2E:74:04:D2:39:E7:C8:03
    
                X509v3 Basic Constraints: critical
                    CA:TRUE
                X509v3 Key Usage: critical
                    Digital Signature, Certificate Sign, CRL Sign
        Signature Algorithm: sha256WithRSAEncryption
            // ...

    包含:

    • 数字签名(Signature Algorithm)
    • 有效时间(Validity)
    • 主体(Issuer)
    • 公钥(Public Key)
    • X509v3 扩展,openssl config 中配置了 v3_ca,所以会生成此项

    创建 intermediate pair

    目前我们已经拥有了 Root Pair,事实上已经可以用于证书的发放了,但是由于根证书很干净,特别容易被污染,所以我们需要创建中间 pair 作为 root pair 的代理,生成过程同上,只是细节略微不一样。

    生成目录结构和 openssl 的配置,这里的配置是针对 intermediate pair 的:

    $ mkdir /root/ca/intermediate
    $ cd /root/ca/intermediate
    $ mkdir certs crl csr newcerts private
    $ chmod 700 private
    $ touch index.txt
    $ echo 1000 > serial
    $ echo 1000 > /root/ca/intermediate/crlnumber
    $ wget -O /root/ca/openssl.cnf \
        //raw.githubusercontent.com/barretlee/autocreate-ca/master/cnf/intermediate-ca
    

    创建 intermediate key,密码可为空,设定权限为只可读:

    $ cd /root/ca
    $ openssl genrsa -aes256 \
          -out intermediate/private/intermediate.key.pem 4096
    
    Enter pass phrase for intermediate.key.pem: secretpassword
    Verifying - Enter pass phrase for intermediate.key.pem: secretpassword
    
    $ chmod 400 intermediate/private/intermediate.key.pem
    

    创建 intermediate cert,设定权限为只可读,这里需要特别注意的一点是 Common Name 不要与 root pair 的一样 :

    $ cd /root/ca
    $ openssl req -config intermediate/openssl.cnf -new -sha256 \
          -key intermediate/private/intermediate.key.pem \
          -out intermediate/csr/intermediate.csr.pem
    
    Enter pass phrase for intermediate.key.pem: secretpassword
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    -----
    Country Name (2 letter code) [XX]:CN
    State or Province Name []:Zhejiang
    Locality Name []:
    Organization Name []:Barret Lee
    Organizational Unit Name []:Barret Lee Certificate Authority
    Common Name []:Barret Lee Intermediate CA
    Email Address []:

    使用 v3_intermediate_ca 扩展签名,密码可为空,中间 pair 的有效时间一定要为 root pair 的子集:

    $ cd /root/ca
    $ openssl ca -config openssl.cnf -extensions v3_intermediate_ca \
          -days 3650 -notext -md sha256 \
          -in intermediate/csr/intermediate.csr.pem \
          -out intermediate/certs/intermediate.cert.pem
    
    Enter pass phrase for ca.key.pem: secretpassword
    Sign the certificate? [y/n]: y
    
    $ chmod 444 intermediate/certs/intermediate.cert.pem

    此时 root 的 index.txt 中将会多出这么一条记录:

    V 260421055318Z   1000  unknown .../CN=Barret Lee Intermediate CA
    

    验证中间 pair 的正确性:

    $ openssl x509 -noout -text \
          -in intermediate/certs/intermediate.cert.pem
    $ openssl verify -CAfile certs/ca.cert.pem \
          intermediate/certs/intermediate.cert.pem
    
    intermediate.cert.pem: OK

    浏览器在验证中间证书的时候,同时也会去验证它的上一级证书是否靠谱,创建证书链,将 root cert 和 intermediate cert 合并到一起,可以让浏览器一并验证:

    $ cat intermediate/certs/intermediate.cert.pem \
          certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem
    $ chmod 444 intermediate/certs/ca-chain.cert.pem

    创建服务器/客户端证书

    终于到了这一步,生成我们服务器上需要部署的内容,上面已经解释了为啥需要创建中间证书。root pair 和 intermediate pair 使用的都是 4096 位的加密方式,一般情况下服务器/客户端证书的过期时间为一年,所以可以安全地使用 2048 位的加密方式。

    $ cd /root/ca
    $ openssl genrsa -aes256 \
          -out intermediate/private/www.barretlee.com.key.pem 2048
    $ chmod 400 intermediate/private/www.barretlee.com.key.pem

    创建 www.barretlee.com 的证书:

    $ cd /root/ca
    $ openssl req -config intermediate/openssl.cnf \
          -key intermediate/private/www.barretlee.com.key.pem \
          -new -sha256 -out intermediate/csr/www.barretlee.com.csr.pem
    
    Enter pass phrase for www.barretlee.com.key.pem: secretpassword
    You are about to be asked to enter information that will be incorporated
    into your certificate request.
    -----
    Country Name (2 letter code) [XX]:CN
    State or Province Name []:Zhejiang
    Locality Name []:Hangzhou
    Organization Name []:Barret Lee
    Organizational Unit Name []:Barret Lee's Personal Website
    Common Name []:www.barretlee.com
    Email Address []:barret.china@gmail.com

    使用 intermediate pair 签证上面证书:

    $ cd /root/ca
    $ openssl ca -config intermediate/openssl.cnf \
          -extensions server_cert -days 375 -notext -md sha256 \
          -in intermediate/csr/www.barretlee.com.csr.pem \
          -out intermediate/certs/www.barretlee.com.cert.pem
    $ chmod 444 intermediate/certs/www.barretlee.com.cert.pem

    可以看到 /root/ca/intermediate/index.txt 中多了一条记录:

    V 170503055941Z   1000  unknown .../emailAddress=barret.china@gmail.com
    

    验证证书:

    $ openssl x509 -noout -text \
          -in intermediate/certs/www.barretlee.com.cert.pem
    $ openssl verify -CAfile intermediate/certs/ca-chain.cert.pem \
          intermediate/certs/www.barretlee.com.cert.pem
    
    www.barretlee.com.cert.pem: OK

    此时我们已经拿到了几个用于部署的文件:

    • ca-chain.cert.pem
    • www.barretlee.com.key.pem
    • www.barretlee.com.cert.pem

    添加信任 CA 和证书的调试

    双击 /root/ca/intermediate/certs/ca-chain.cert.pem 将证书安装到系统中,目的是让本机信任这个 CA,将其当作一个权威 CA,安装 root pem 或者 intermediate chain pem 都是可以的,它们都具备验证能力。如果不执行这一步,浏览器依然会提示 net:ERR_CERT_AUTHORITY_INVALID

    上面申请测试证书时,我设置的 Common Name 为 www.barretlee.com,由于不在线上机器测试,可以将其添加到 hosts:

    127.0.0.1 www.barretlee.com
    

    执行下方测试代码:

    // https-server.js
    var https = require('https');
    var fs = require('fs');
    
    var options = {
      key: fs.readFileSync('/root/ca/intermediate/private/www.barretlee.com.key.pem'),
      cert: fs.readFileSync('/root/ca/intermediate/certs/www.barretlee.com.cert.pem'),
      passphrase: 'passoword' // 如果生成证书的时候设置了密码,请添加改参数和密码
    };
    
    https.createServer(options, function(req, res) {
      res.writeHead(200);
      res.end('hello world');
    }).listen(8000, function(){
      console.log('Open URL: //www.barretlee.com:8000');
    });

    可以看到这样的效果:

    查看证书的详细信息:

     

    回到最初的问题:

    然而在一些情况下,我们没必要去 CA 机构购买证书,比如在内网的测试环境中,为了验证 HTTPS 下的一些问题,我们不需要部署昂贵的证书,这个时候自建 Root CA,给自己颁发证书就显得很有价值了。

    一般公司内网的电脑都会强制安装一些安全证书,此时就可以把我们自建自签名的证书导入/引导安装到用户的电脑中啦~

    无 SNI 支持问题

    很多公司由于业务众多,域名也是相当多的,为了方便运维,会让很多域名指向同样的 ip,然后统一将流量/请求分发到后端,此时就会面临一个问题:由于 TLS/SSL 在 HTTP 层之下,客户端和服务器握手的时候还拿不到 origin 字段,所以服务器不知道这个请求是从哪个域名过来的,而服务器这边每个域名都对应着一个证书,服务器就不知道该返回哪个证书啦。

    SNI 就是用来解决这个问题的,官方解释是

    然后有将近 25% 的浏览器不支持该字段的扩展,这个问题有两个通用解决方案:

    • 使用 VIP 服务器,每个域名对应一个 VIP,然后 VIP 与统一接入服务对接,通过 ip 来分发证书,不过运维成本很高,可能也需要大量的 VIP 服务器
    • 采用多泛域名,将多个泛域名证书打包进一个证书,可以看看淘宝页面的证书

    它的缺点是每次添加域名都需要更新证书。

    几个细节知识点

    1. 证书选择

    证书有多张加密方式,不同的加密方式对 CPU 计算的损耗不同,安全级别也不同。TLS 在进行第一次握手的时候,客户端会向服务器端 say hello,这个时候会告诉服务器,它支持哪些算法,此时服务器可以将最适合的证书发给客户端。

    2. 证书的吊销

    CA 证书的吊销存在两种机制,一种是在线检查,client 端向 CA 机构发送请求检查 server 公钥的靠谱性;第二种是 client 端储存一份 CA 提供的证书吊销列表,定期更新。前者要求查询服务器具备良好性能,后者要求每次更新提供下次更新的时间,一般时差在几天。安全性要求高的网站建议采用第一种方案。

    大部分 CA 并不会提供吊销机制(CRL/OCSP),靠谱的方案是为根证书提供中间证书,一旦中间证书的私钥泄漏或者证书过期,可以直接吊销中间证书并给用户颁发新的证书。中间证书的签证原理于上上条提到的原理一样,中间证书还可以产生下一级中间证书,多级证书可以减少根证书的管理负担。

    很多 CA 的 OCSP Server 在国外,在线验证时间比较长,如果可以联系 CA 供应商将 Server 转移到国内,效率可以提升 10 倍左右。

    3. PKI 体系

    比较主流的两种方案是 HPKP 和 Certificate Transparency:

    • HPKP 就是用户第一次访问的时候记下 sign 信息,以后不匹配则拒绝访问,这存在很大的隐患,比如 Server 更新了证书,或者用户第一次访问的时候就被人给黑了
    • Certificate Transparency 意思就是让 CA 供应商透明化 CA 服务日志,防止 CA 供应商偷偷签证

    小结

    看了不少文章,对 CA 和证书相关的知识做了一些总结,可能不全面,也可能存在表述错误或者知识性错误,欢迎拍砖!

    拓展阅读

    转自:

    https://www.barretlee.com/blog/2016/04/24/detail-about-ca-and-certs/

     

     

     

     

    展开全文
  • 数字证书CA详解

    万次阅读 2019-08-30 16:11:00
    证书1.1 证书的应用场景1.2 证书标准规范X.5091.2.1 证书规范1.2.2 证书格式1.2.3 CA证书1.3 公钥基础设施(PKI)1.3.1 什么是公钥基础设施1.3.2 PKI的组成要素用户认证机构(CA)仓库1.3.3 各种各样的PKI2.Fabric ...
  • CA证书原理(转载)

    千次阅读 2019-01-18 10:02:31
    文中首先解释了加密解密的一些基础知识和概念,然后通过一个加密通信过程的例子说明了加密...接着对数字证书做一个详细的解释,并讨论一下windows中数字证书的管理,最后演示使用makecert生成数字证书。如果发现文...
  • 什么是CA证书

    千次阅读 2019-09-21 16:30:44
    数字证书就是用电子形式来唯一标识企业或者个人在国际互联网上或专用网上的身份,当您用您的数字证书对电子化信息进行签名以后,您对这份电子信息的内容就具有不可抵赖性或篡改性,如同您在工作或生活中用公章或私章...
  • 解决方案: 1,打开IE浏览器,点击“工具”——“Internet选项” ——“内容”选项卡  ... 3、在要安装的证书类型时点“受信任的根证书颁发机构”,接下来点左下角的“导入”按钮导入相关的证书即可。
  • Linux系统生成CA证书

    万次阅读 2020-07-15 02:41:48
    生成CA证书 在配置HTTPS监听时,您可以使用自签名的CA证书,并且使用该CA证书为客户端证书签名。 使用Open SSL生成CA证书 执行如下命令,在/root目录下新建一个ca文件夹,并在ca文件夹下创建四个子文件夹。 ...
  • CentOS导入CA证书

    万次阅读 2016-08-19 14:14:36
    CentOS导入CA证书
  • CA(Certificate Authority)被称为证书授权中心,是数字证书发放和管理的机构。 根证书CA认证中心给自己颁发的证书,是信任链的起始点。安装根证书意味着对这个CA认证中心的信任。 数字证书颁发过程一般为:用户首先...
  • BurpSuite抓https的包/BurpSuite CA证书下载

    万次阅读 多人点赞 2018-08-07 16:20:13
    BurpSuite抓https的包/BurpSuite CA证书下载 Burp Suite要抓HTTPS的包的话,是需要有Burp Suite的... Burp Suite软件是自带了CA证书的,我总结了一下有两种方法把CA证书下载到本地 (1)网上大多数的方法,【通过...
  • 热心网友 一、 所问应指单证书,这个... 2、单证中密钥对不由ca产生,不存在它是将私钥发送给用户的情况,也无ca那里负责保存用户的私钥码的情况。 二、扩展说明。国内当前是双证书体系,即用户同时拥有签名证书
  • OpenSSL 自建CA及签发证书

    万次阅读 2017-02-12 14:43:32
    ref: http://rhythm-zju.blog.163.com/blog/static/310042008015115718637/利用 OpenSSL ...创建默认CA下的目录及文件如下图(.old文件和.attr文件是签发证书后自动生成的文件)。 其中, newcerts目录用于存放CA
  • 自签名的证书无法被吊销,CA签名的证书可以被吊销 能不能吊销证书的区别在于,如果你的私钥被黑客获取,如果证书不能被吊销,则黑客可以伪装成你与用户进行通信 如果你的规划需要创建多个证书,那么使用私有CA的...
  • 解决linux下https访问证书问题

    万次阅读 2016-05-13 11:25:56
    如果出现这个报错信息的话就是证书无效:Peer certificate cannot be authenticated with known CA certificates 解决办法是将该证书的公钥.pem文件内容,追加到/etc/pki/tls/certs/ca-bundle.crt。
  • openssl生成SSL证书的流程

    万次阅读 2015-09-15 17:57:54
    SSL证书通过在客户端浏览器和Web服务器之间建立一条SSL安全通道(Secure socketlayer(SSL),SSL安全协议主要用来提供对用户和服务器的认证;对传送的数据进行加密和隐藏;确保数据在传送中不被改变,即数据的完整性,...
  • linux系统导入CA证书

    万次阅读 2014-07-02 08:46:32
    因为众所周知的原因,同步android源码成了非常痛苦的事情。迫不得已采用了goagent,但是在同步时发生经常发生...网上找了一圈资料,最后明白根本的原因是系统中没有安装goagent的CA证书。这里的系统不是指firefox,
  • 操作环境:Centos 6、RHEL 6 操作虚拟机:VMware本实验基于...1、以Centos 6系统作为CA机构,实行签发证书等操作 2、以RHEL 6系统作为申请证书客户机操作步骤: 1、让Centos 6自签证书成为CA发证机构 2、让RH
  • 安全套接字层 SSL协议,通过CA证书来验证服务器的身份,并且对通信消息进行加密https://blog.csdn.net/mrpre/article/details/78015580 SSL协议https://zhidao.baidu.com/question/198445759327094485...
1 2 3 4 5 ... 20
收藏数 79,873
精华内容 31,949
关键字:

ca证书