运维必看:HTTPS 证书是如何为网站正名的

运维 系统运维
HTTPS解决两个问题: 加密传输保证客户端和服务器之间的信息不是明文传输,保证信息的机密性 身份认证HTTPS协议能够证明服务端的身份,防止假冒网站冒充自己的身份。

 [[315625]]

 HTTPS 解决什么问题

HTTPS解决两个问题:

  • 加密传输保证客户端和服务器之间的信息不是明文传输,保证信息的机密性
  • 身份认证HTTPS协议能够证明服务端的身份,防止假冒网站冒充自己的身份。

对称加密算法

这一部分需要密码学的基础,本段仅做相关总结。对称加密因为密钥只有一个,存在密钥被枚举出来的问题,加密安全性不够高。

常见的对称加密有 DES,3DES,AES

因为性能比非对称加密高,所以用在HTTPS内容加密上,HTTPS通过非对称加密算法做密钥协商生成密钥,用作页面内容的对称加密。

非对称加密算法

常见的非对称加密算法都是基于数学难题,在当前计算能力下破解较难,常见的算法有RSA,ECC等。抽象出几个名词概念:公钥,私钥。

公钥和私钥可以通过数学算法计算相互对明文密文进行数学计算并验证。

加密: 通过公钥(或私钥)对明文计算(如RSA)生成密文

解密: 通过另一个密钥对密文进行计算生成明文

上面加解密的概念是相对的,在日常应用中,常见的两个场景:

  • 发送方通过接收方公钥对明文加密,接收方通过自己的私钥进行解密
  • 需要身份认证的场景下,用自己的私钥对待签名的内容进行电子签章,需要验证的时候,验证者获取签名者的公钥进行验证(公钥对密文进行数学计算解密)

非对称加密算法的场景 – 身份认证和PKI

身份认证

上节提到非对称加密算法的一个场景是数字签名,数字签名是身份认证的手法。因为自己的私钥是别人不知道的也是别人不可复制的,如同人的指纹一样,是能代表自己本人的。但是问题来了?我想让别人拿着我的公钥和我进行加密通信,对方是如何知道这是我的公钥呢?

怎么证明我是我?

证明我是我,只能拿着本人的身份证去派出所查询,然后让官方出具一份“本人证明”,因为有关部门是可信的,所以如果官方说这个是合法的,那就能证明这就是我。

那么电子世界的有这个官方机构吗?有!

PKI 基础设施

PKI是安全世界的基础设施,CA机构是其主要成员,CA机构通过向申请证明“我就是我”的用户颁发证书,用户通过校验证书的有效性,来判断是否是自己需要通信的对方。当然,CA是盈利机构,企业申请证书证明“我就是我”需要花费不少费用的,当然,不差钱!

证书颁发

证书内容:证书 = 使用者公钥 + 主体信息如公司名称等 + CA对信息的确认签名 + 指纹

证书颁发流程大概分为:

  • 申请者生成CSR,申请时填写公司主体身份信息,生成CSR和私钥,CSR内容相当于公钥和身份信息。
  • 选择CA证书签发机构,如亚马逊,Globalsign,或免费机构
  • 提交CSR,CA会验证公司主体信息,没问题后会对申请者提交上来的CSR进行签名,生成web服务器能部署的公钥
  • 发送给申请者

可见在可信官方CA机构的签发下,大家看到这个证书后都可以认为这就是你本人没错了。客户端都内置可信机构的根证书,所以承认这个官方机构,这个在之后的信任链部分会详细介绍。

但是问题又来了,随着HTTPS越来越多,颁发机构忙不过来怎么办?各国之间语言沟通障碍怎么办?如同现实世界,官方机构会授权子公司或者新开总公司分部,同理,CA机构们也会增加自己的分公司,从而产生了中级证书和交叉证书的概念。

中级证书:不使用根证书的私钥对申请者的CSR进行签名,而采用中级证书对申请者的CSR进行签名颁发证书.

交叉证书:不同根证书之间的相互签名,改变信任起始点

信任链和信任锚

 

 

 

 

由于中级证书的采用,整个证书有效性校验流程里有了信任链的概念,信任链就是客户端从服务器实体证书向上逐级校验,每一级证书校验过程是通过拿到证书签发者(Issuer)的证书中的公钥(证书 = 使用者公钥 + 主体信息如公司名称等 + CA对信息的确认签名 + 指纹)对本级证书(Subject)的签名进行数学验证,验证成功即证书有效。

整个一级一级验证上去,形成信任链。直到一个证书的签发者和使用者是同一个人,则这个点为信任锚,即信任链的起始点,起始点需要在客户端系统或者浏览器的根证书信任列表中,整个流程结束后,证书可信。

PS:不同浏览器(客户端)的可信根证书列表是不同的,Chrome读取系统中的根证书列表,而FireFox浏览器则使用自己浏览器内置的可信根证书列表。

Nginx部署证书和校验分析

Nginx服务器证书部署使用base64编码格式的证书。通过CA颁发证书后获得一个base64格式的证书,和私钥一起部署在服务器中。

 

  1. ssl on
  2. ssl_certificate /opt/soft/ssl/0xfe.com.cn_chain.crt; 
  3. ssl_certificate_key /opt/soft/ssl/0xfe.com.cn_key.key

0xfe.com.cn_chain.crt为公钥文件,0xfe.com.cn_key.key为私钥文件。

 

  1. cat /opt/soft/ssl/0xfe.com.cn_chain.crt 
  2. -----BEGIN CERTIFICATE----- 
  3. MIIFpjCCBI6gAwIBAgIQBjLXXyMcU5DDZQ7gshcXdTANBgkqhkiG9w0BAQsFADBy 
  4. MQswCQYDVQQGEwJDTjElMCMGA1UEChMcVHJ1c3RBc2lhIFRlY2hub2xvZ2llcywg 
  5. SW5jLjEdMBsGA1UECxMURG9tYWluIFZhbGlkYXRlZCBTU0wxHTAbBgNVBAMTFFRy 
  6. dXN0QXNpYSBUTFMgUlNBIENBMB4XDTE5MDgxNjAwMDAwMFoXDTIwMDgxNTEyMDAw 
  7. MFowFjEUMBIGA1UEAxMLMHhmZS5jb20uY24wggEiMA0GCSqGSIb3DQEBAQUAA4IB 
  8. DwAwggEKAoIBAQDcNNv3Ap4P+LRHrPHPWwuHHZhexQiSCPBAba/kSAcXjFAxaI7o 
  9. NdyiuBmUhPoGeV3YvIpzV9nsgcar94yDWef/L6Dl5SpVlHYYudgDwa+MKibhPGaL 
  10. ncW3urpPok3LFngSz63n2xg77Of4gEcOOeMPdzUb9UT6tKrZlPKXRjrGXKbLTwTj 
  11. AQo4MhvmS8ZddmaRjCTSxhJrZ8n4W2YfgBjITZEqNDDQyhxkS5Sr8/8OQ8wfn38c 
  12. rrd6FMAgnjnEZZVi3ivd4+XEz+g/DNE/m7+8cmRuHfG8ELXjGnswquJstgllNyUl 
  13. qumW3dfE9YVIJlQkvEQWFMsw5dzxHidJWTFLAgMBAAGjggKSMIICjjAfBgNVHSME 
  14. GDAWgBR/05nzoEcOMQBWViKOt8ye3coBijAdBgNVHQ4EFgQUlKhM50RH3AC7pIcy 
  15. qEoULdttwXUwJwYDVR0RBCAwHoILMHhmZS5jb20uY26CD3d3dy4weGZlLmNvbS5j 
  16. bjAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC 
  17. MEwGA1UdIARFMEMwNwYJYIZIAYb9bAECMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v 
  18. d3d3LmRpZ2ljZXJ0LmNvbS9DUFMwCAYGZ4EMAQIBMIGSBggrBgEFBQcBAQSBhTCB 
  19. gjA0BggrBgEFBQcwAYYoaHR0cDovL3N0YXR1c2UuZGlnaXRhbGNlcnR2YWxpZGF0 
  20. aW9uLmNvbTBKBggrBgEFBQcwAoY+aHR0cDovL2NhY2VydHMuZGlnaXRhbGNlcnR2 
  21. YWxpZGF0aW9uLmNvbS9UcnVzdEFzaWFUTFNSU0FDQS5jcnQwCQYDVR0TBAIwADCC 
  22. AQQGCisGAQQB1nkCBAIEgfUEgfIA8AB2AO5Lvbd1zmC64UJpH6vhnmajD35fsHLY 
  23. gwDEe4l6qP3LAAABbJg76VwAAAQDAEcwRQIhAO5fxTuzbUnz6fna1BAyOzzAxoSw 
  24. N1xo0lnXrMr2bVBrAiAe2PWp7rCX0eMzO+ZdICzFwQtcULLHSGehHv8CgMqbNQB2 
  25. AId1v+dZfPiMQ5lfvfNu/1aNR1Y2/0q1YMG06v9eoIMPAAABbJg76eAAAAQDAEcw 
  26. RQIhAItx6WPv2a2nKIBRVDuvns5D4fElzlPAHMVM9gKDA4HcAiB/D+n/UCFAH5YY 
  27. L6r+vLKgLRJCfq5Vw0kaLWA+P3a5RDANBgkqhkiG9w0BAQsFAAOCAQEAllOZKfyY 
  28. hoyC5/FRnEhoY/6v/kbzPlVsgZvUVtk3IDnyo7GOaUUigQaLSmL0oWTnwmMOweb7 
  29. UhP1TL+RCYcw2fc39l4FIaOKjMmSaPLZw2Fm9Lk/ie5BZ3pLD5A3exz4nMgVjJB6 
  30. XC0ZiBgTsCOl3K3vFefL4x4ewoR0KwN5fTwkxKKT7XUCMTcIOMgWX2ubUXhjM2cy 
  31. c9lRPTy2joO4za9AS6sR5JExLY/kJ3dR7t99gko5MnJZINcPD8WIUySw5oQZA22Y 
  32. OhFVBGiERcH+oD6TNoZuqu2pSfrAIFT3dWpb1bGgiCxblsN2yH1REXmnTx3bmuy2 
  33. UAXfwUlUhtmRbw== 
  34. -----END CERTIFICATE----- 
  35. -----BEGIN CERTIFICATE----- 
  36. MIIErjCCA5agAwIBAgIQBYAmfwbylVM0jhwYWl7uLjANBgkqhkiG9w0BAQsFADBh 
  37. MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 
  38. d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD 
  39. QTAeFw0xNzEyMDgxMjI4MjZaFw0yNzEyMDgxMjI4MjZaMHIxCzAJBgNVBAYTAkNO 
  40. MSUwIwYDVQQKExxUcnVzdEFzaWEgVGVjaG5vbG9naWVzLCBJbmMuMR0wGwYDVQQL 
  41. ExREb21haW4gVmFsaWRhdGVkIFNTTDEdMBsGA1UEAxMUVHJ1c3RBc2lhIFRMUyBS 
  42. U0EgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgWa9X+ph+wAm8 
  43. Yh1Fk1MjKbQ5QwBOOKVaZR/OfCh+F6f93u7vZHGcUU/lvVGgUQnbzJhR1UV2epJa 
  44. e+m7cxnXIKdD0/VS9btAgwJszGFvwoqXeaCqFoP71wPmXjjUwLT70+qvX4hdyYfO 
  45. JcjeTz5QKtg8zQwxaK9x4JT9CoOmoVdVhEBAiD3DwR5fFgOHDwwGxdJWVBvktnoA 
  46. zjdTLXDdbSVC5jZ0u8oq9BiTDv7jAlsB5F8aZgvSZDOQeFrwaOTbKWSEInEhnchK 
  47. ZTD1dz6aBlk1xGEI5PZWAnVAba/ofH33ktymaTDsE6xRDnW97pDkimCRak6CEbfe 
  48. 3dXw6OV5AgMBAAGjggFPMIIBSzAdBgNVHQ4EFgQUf9OZ86BHDjEAVlYijrfMnt3K 
  49. AYowHwYDVR0jBBgwFoAUA95QNVbRTLtm8KPiGxvDl7I90VUwDgYDVR0PAQH/BAQD 
  50. AgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjASBgNVHRMBAf8ECDAG 
  51. AQH/AgEAMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au 
  52. ZGlnaWNlcnQuY29tMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jcmwzLmRpZ2lj 
  53. ZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RDQS5jcmwwTAYDVR0gBEUwQzA3Bglg 
  54. hkgBhv1sAQIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29t 
  55. L0NQUzAIBgZngQwBAgEwDQYJKoZIhvcNAQELBQADggEBAK3dVOj5dlv4MzK2i233 
  56. lDYvyJ3slFY2X2HKTYGte8nbK6i5/fsDImMYihAkp6VaNY/en8WZ5qcrQPVLuJrJ 
  57. DSXT04NnMeZOQDUoj/NHAmdfCBB/h1bZ5OGK6Sf1h5Yx/5wR4f3TUoPgGlnU7EuP 
  58. ISLNdMRiDrXntcImDAiRvkh5GJuH4YCVE6XEntqaNIgGkRwxKSgnU3Id3iuFbW9F 
  59. UQ9Qqtb1GX91AJ7i4153TikGgYCdwYkBURD8gSVe8OAco6IfZOYt/TEwii1Ivi1C 
  60. qnuUlWpsF1LdQNIdfbW3TSe0BhQa7ifbVIfvPWHYOu3rkg1ZeMo6XRU9B4n5VyJY 
  61. RmE= 
  62. -----END CERTIFICATE----- 

 

  1. cat /opt/soft/ssl/0xfe.com.cn_key.key 
  2. -----BEGIN RSA PRIVATE KEY----- 
  3. 省略 
  4. -----END RSA PRIVATE KEY----- 

公钥文件中,-----BEGIN CERTIFICATE-----和-----END CERTIFICATE-----之间即为一个证书,第一个必须为域名实体证书,后面的依次为中级证书或交叉证书,经测试,第一个域名实体证书顺序必须放第一个,后续中级证书可相互调换顺序,通常增加中间证书建议追加到最后面。CER在线读取工具

将上述第一段输入到在线读取工具中,输出如下:

 

  1. CER解码结果: 
  2.  
  3. 通用名 :0xfe.com.cn 
  4. 可用域名 :DNS:0xfe.com.cn, DNS:www.0xfe.com.cn 
  5. 有效时间段 :2019-08-16 - 2020-08-15 
  6. 序列号 :8239351073242680476627775209099171701 
  7. 颁发者 :TrustAsia TLS RSA CA 
  8. 有效期 :2020-08-15 20:00:00 

将上述第二段输入到在线读取工具中,输出如下:

 

  1. CER解码结果: 
  2.  
  3. 通用名 :TrustAsia TLS RSA CA 
  4. 公司组织名 :TrustAsia Technologies, Inc. 
  5. 有效时间段 :2017-12-08 - 2027-12-08 
  6. 序列号 :7311534772508790650765434802415791662 
  7. 颁发者 :DigiCert Global Root CA 
  8. 有效期 :2027-12-08 20:28:26 

可见上述,两端base64证书分别对应域名实体证书和中级证书。

 

  1. 上述证书信任链为: 
  2. 0xfe.com.cn <----校验----   TrustAsia TLS RSA CA  <----校验----  DigiCert Global Root CA (存在系统或浏览器中) 

客户端通过TrustAsia TLS RSA CA证书中的公钥验证0xfe.com.cn证书中的签名,通过客户端通过DigiCert Global Root CA证书中的公钥验证TrustAsia TLS RSA CA证书中的签名,通过。

上面的DigiCert Global Root CA称为根证书。

 

 

 

 

为了校验上述流程,可通过禁用系统的根证书,下图将DigiCert Global Root CA禁用,标为不信任,可见浏览器将0xfe.com.cn标记为不信任。

 

 

 

 

 

 

 

 

 

 

 

 

百度网站证书分析举例

 

 

 

 

可见百度证书校验信任链为:

baidu.com <—-校验—- GlobalSign Organization Validation CA - SHA256 - G2 <—-校验—- GlobalSign Root CA (存在系统或浏览器中)

客户端通过GlobalSign Organization Validation CA - SHA256 - G2证书中的公钥验证baidu.com证书中的签名,通过;

客户端通过GlobalSign Root CA证书中的公钥验证GlobalSign Organization Validation CA - SHA256 - G2证书中的签名,通过。

上面的GlobalSign Root CA称为根证书。

使用GlobalSign CA 交叉证书改变信任锚

MAC系统最新内置的GlobalSign CA有5个:

 

 

 

 

组织单位分别称为:

 

  1. Root CA 
  2. GlobalSign Root CA - R2 
  3. GlobalSign ECC Root CA - R5 
  4. GlobalSign ECC Root CA - R4 
  5. GlobalSign Root CA - R3 

即R1到R5,FireFox浏览器中还存在R6

也就是说Gloabalsign一共有这些根证书在使用。

存在以下场景需使用交叉证书:

GlobalSign在根CA启用颁发证书的过程中,会出现客户端没有来得及更新根CA的情况,如客户端只存在R1到R3三个根证书,缺少其他几个根证书。

这个时候使用较新根证书如R4颁发的域名证书会被客户端标记为不安全,这时候GlobalSign会提供交叉证书,将信任锚从较新CA根证书如R4指向到客户端存在的根证书R1上,解决客户端无法访问的问题。

下面将用一个例子直观的表示这个场景:

 

  1. baidu.com <----校验----  GlobalSign Organization Validation CA - SHA256 - G2  <----校验----  GlobalSign Root CA - R4 (GlobalSign Root CA - R4不存在客户端中) 

GlobalSign Root CA - R4不存在客户端可信任根证书列表中,所以信任链不完整,无法正常访问,如何在无需重新签发中级证书GlobalSign Organization Validation CA - SHA256 - G2的情况下解决客户端问题呢?根据上面的分析,只需要在Nginx服务器公钥文件后面增加交叉证书的base64编码版本即可,此时信任链会新会增加一级,将信任锚点从R4根证书转移到R1根证书。

在部署nginx时增加一段交叉证书,改变信任锚,修改后的信任链将为:

 

  1. baidu.com <----校验----  GlobalSign Organization Validation CA - SHA256 - G2  <----校验---- R1-R4交叉证书<----校验---- Root CA  (Root CA 为GlobalSign Root CA R1,存在于系统中) 

即使用R1-R4交叉证书签名且验证GlobalSign Organization Validation CA - SHA256 - G2,使用Root CA签名且验证R1-R4交叉证书,将信任锚点从R4根证书转移到R1根证书,R1根证书存在于系统中,所以可以解决因为较新CA根证书颁发的证书不可信问题。备注:GlobalSign2019年5月27日迁移签发 SSL 证书的中级 CA,使用 RSA 算法密钥的 OV SSL 证书将在新的中级 CA 下签发,该中级 CA 将链到 GlobalSign R3 根证书下。如使用此算法颁发的证书,请保持系统中R3根证书存在,在这之前颁发的证书中的中级证书链到 GlobalSign R1 根证书下。

变更如下图:

更改前,中级证书链到R1根证书:

 

 

 

 

更改后,中级证书链到R3根证书:

 

 

 

 

使用GlobalSign CA 的用户请注意变更带来的影响,可增加GlobalSign R1R3交叉证书到证书文件,解决客户端不存在R3根证书的问题。

责任编辑:武晓燕 来源: 高效运维
相关推荐

2016-09-13 10:56:03

运维性能密度

2019-02-01 08:41:17

运维ITLinux

2023-04-23 14:40:22

智能运维物联网人工智能

2016-11-25 17:51:48

华为ICT

2011-11-08 17:11:47

程序员

2013-06-17 14:03:27

IIS日志网站运维

2014-09-23 11:10:22

运维

2018-09-21 09:15:39

2015-05-07 10:55:05

IAASPAAS可视化

2022-05-24 10:36:45

云原生容器应用

2015-08-10 13:40:56

运维网站

2010-08-12 17:34:19

网站运维流程规范

2018-08-16 08:37:03

机房运维硬件

2019-12-17 09:42:11

运维架构技术

2012-12-28 16:30:05

IT运维服务企业

2020-06-11 11:38:22

运维架构技术

2012-05-08 15:31:09

运维南非蚂蚁

2016-06-17 10:35:20

云计算运维

2013-05-06 15:10:18

IT运维管理大数据

2010-08-17 13:23:49

点赞
收藏

51CTO技术栈公众号