证书没有公共审核记录到底意味着什么?他们的某些威胁是否存在于使用没有公共审核记录的证书的站点是否具有使用具有公共审核记录的证书的站点吗?
#1 楼
注意:如果您因为证书不受Chrome浏览器信任而在这里,这不是原因。 Chrome仍然会信任没有CT信息的证书。如果您的证书不受信任,则可能会遗漏其他因素。这与证书透明性的概念有关。
问题
如果满足以下四个条件,浏览器当前将信任证书:(a)证书由受信任的CA签名,(b)当前时间在有效时间内证书和签名证书的有效期限(介于
notBefore
和notAfter
之间),(c)证书和任何签名证书均未被吊销,最后(d)证书与所需URL的域名匹配。 > 但是这些规则为滥用提供了方便。受信任的CA仍可以向不应该拥有证书的人颁发证书。这包括受损的CA(例如DigiNotar)以及CA(例如Trustwave),它们至少签发了一个中间签名证书,用于执行SSL流量的中间人拦截。在CAcert的CA和PKI的风险和威胁事件历史记录中可以找到CA失败的历史记录。在您实际看到证书之前,您不会知道Trustwave或DigiNotar已颁发欺诈性证书,在这种情况下,您可能是犯罪者的目标,而不是实际上可以进行任何实际审核的人员。为了防止滥用或错误,我们需要CA将其签名的证书历史记录公开。
解决方案
我们处理此问题的方法是创建已颁发证书的日志。这可以由发行人维护,也可以由其他人维护。但是重要的一点是(a)无法编辑日志,只能添加新条目,并且(b)通过适当的时间戳验证将证书添加到日志的时间。当然,对所有内容都进行了加密保证以防止篡改,并且公众可以观看日志的内容,以查看是否为他们不知道的域颁发了证书。然后,您的浏览器会看到一个应该在日志中但不是的证书,或者在日志中但是不匹配的证书(例如错误的时间戳等),然后浏览器可以采取适当的措施。
然后,您在Chrome中查看的内容就表明您正在查看的证书是否存在可公开听到的日志。如果是这样,Chrome浏览器还可以检查是否已创建适当的日志条目以及何时进行。
它的使用范围很广?日志”。撰写本文时,Google,Digicert,Izenpe和Certly维护着日志,每个日志都可以维护任意数量的CA的审计跟踪。在2015年1月1日之后,所有人都必须拥有公开审核记录才能被视为EV。在应用了有关EV证书审核日志的经验之后,他们将继续向所有证书颁发者推出该产品。 “证书透明度”查找表单的标准“透明度报告”,这意味着您现在可以查询要关注的域,以查看这些域的哪些证书显示在透明日志中。例如,这使您可以查看假设CA进行合作的情况下,哪些证书当前对您的域有效。
请在此处查找:https://www.google.com/transparencyreport/https/ct/
请记住,如果您想跟踪给定的域名,以在证书更新时收到警报,您应该直接跟踪日志。此表格对于进行时间点查询很有用,而不是用于生成警报。
评论
这是一个很好的答案,但对于为何Google到底为什么不使用可听的证书仍未解决问题?难道这还根本不可用,Google正在将指示器放在Chrome中以尝试更改CA?
–脆弱
15年1月13日在13:11
@Fraggle Google可以做得更好。他们使用HSTS固定证书,更令人印象深刻的是,他们的浏览器(也包括Firefox)都已预先加载正确的HSTS条目。因此,无论是谁签名,Firefox和Chrome甚至都不允许您使用欺诈性的Google证书。相同的保护也扩展到其他要求的人。
– tylerl
15年1月13日在15:15
@tylerl,不。该保护仅适用于像Google这样的特权大人物。这不是可以扩展的解决方案。如果您有一个网站my_site.com,并告诉Google将my_site.com添加到Chrome中预加载的STS列表中,则他们只会忽略您。即使实施了STS列表,它也不会阻止MITM攻击。
–起搏器
2015年1月16日在13:34
@Pacerier它真的向任何人开放。在这里添加您的网站:hstspreload.appspot.com
– tylerl
2015年1月16日15:25
@ tylerl,hstspreload.appspot.com仅具有一个输入框。您将如何指定证书?
–起搏器
15年1月19日在8:28
#2 楼
这是Google的一个名为Certificate Transparency的项目,该项目试图修复SSL证书系统中的缺陷。它主要有三个主要目标。 (摘自http://www.certificate-transparency.org/what-is-ct)
使CA不可能(或至少非常困难)发布SSL域的证书,而该域的所有者看不到该证书。
提供一个开放的审核和监视系统,该系统可以使任何域所有者或CA确定证书是错误还是恶意发行的。
保护用户(尽可能)避免被错误或恶意颁发的证书欺骗。
来源:http://www.certificate-transparency.org/certificate-transparency-in-chrome
#3 楼
自2015年1月1日起,所有EV证书都必须具有公共审核记录(签名证书时间戳记)。包含这些记录的最常见方式是通过嵌入式SCT。此方法在证书文件本身中包括一个新的证书扩展名/ OID(1.3.6.1.4.1.11129.2.4.2)。对于OV和DV证书,您可以请求CA将证书添加到它的CT日志。我知道DigiCert将做到这一点。最终,这些证书类型也可能需要启用CT。
为了嵌入SCT,在CA为您的证书启用了证书之后,您需要重新发行您希望拥有公共审计记录的证书。
#4 楼
Chrome浏览器报告证书“没有公共审核记录”的确切含义是什么?
我认为Tyler在解释消息和CT方面做得很好。
基于@Colonel Panic对测试站点的评论,这是最终实体(服务器)证书的外观。注意:您必须使用TLS 1.0(或更高版本)和服务器名称指示来获取正确的证书。这就是下面的
-servername
选项。$ openssl s_client -connect embed.ct.digicert.com:443 -tls1 -servername embed.ct.digicert.com | \
openssl x509 -text -noout
depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA
verify error:num=20:unable to get local issuer certificate
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:e0:aa:80:19:13:06:8a:28:73:f0:24:29:3e:e4:61
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA
Validity
Not Before: Nov 13 00:00:00 2014 GMT
Not After : Nov 18 12:00:00 2015 GMT
Subject: C=US, ST=Utah, L=Lehi, O=DigiCert, Inc., CN=embed.ct.digicert.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:9a:64:73:61:53:66:b8:aa:80:c7:cc:53:67:6a:
df:da:a9:b1:6a:c5:53:63:55:5f:14:4c:b3:27:d1:
3c:e4:0a:1a:e7:16:48:bc:15:46:7e:63:e8:27:3c:
c5:28:bd:79:cf:34:d5:9a:67:1e:0c:27:6e:ec:00:
5e:69:38:5b:a7:16:4f:b9:09:ec:fc:7e:f2:41:b7:
f9:54:f4:6c:c3:22:a6:f5:99:f4:be:9d:64:26:75:
9e:b2:b9:16:d7:f5:51:9f:53:ce:74:ca:d6:d6:7a:
4a:d4:4d:0e:4d:73:93:30:3c:b9:b8:1d:a0:d8:94:
8c:59:7e:82:a4:4c:82:fc:c3:73:7f:b1:56:28:4e:
b5:f7:73:53:ac:7b:30:a4:bc:b9:6c:c0:b6:67:0d:
19:5e:40:22:11:11:8c:6d:3a:87:47:08:e6:5c:7b:
17:7c:64:7a:a1:ff:8c:7c:37:b6:b7:91:2c:c2:90:
7e:cc:48:1f:57:1e:f9:db:d4:ac:cf:d9:2b:60:ff:
13:2d:88:c5:7e:d8:eb:ec:ed:85:d7:9e:f9:56:32:
ca:c1:6b:24:64:9f:63:ba:83:ee:a1:85:4a:e3:ad:
45:8c:92:95:3a:e0:80:91:9b:60:b5:75:88:86:4e:
0f:81:8c:b5:f4:77:fd:e5:f3:36:f6:33:d6:2b:a0:
c4:91
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:0F:80:61:1C:82:31:61:D5:2F:28:E7:8D:46:38:B4:2C:E1:C6:D9:E2
X509v3 Subject Key Identifier:
88:4F:83:16:87:AD:AE:1E:FF:04:4A:79:66:92:C6:9F:62:69:4F:B1
X509v3 Subject Alternative Name:
DNS:embed.ct.digicert.com
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl3.digicert.com/ssca-sha2-g3.crl
Full Name:
URI:http://crl4.digicert.com/ssca-sha2-g3.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.1.1
CPS: https://www.digicert.com/CPS
Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2SecureServerCA.crt
X509v3 Basic Constraints: critical
CA:FALSE
CT Precertificate SCTs:
Signed Certificate Timestamp:
Version : v1(0)
Log ID : A4:B9:09:90:B4:18:58:14:87:BB:13:A2:CC:67:70:0A:
3C:35:98:04:F9:1B:DF:B8:E3:77:CD:0E:C8:0D:DC:10
Timestamp : Nov 13 16:57:03.632 2014 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:06:14:6A:E3:6D:0F:84:5D:6A:98:E7:29:
94:80:8B:F2:A4:23:85:68:4E:F9:BC:50:7C:FF:7B:94:
EB:20:54:82:02:21:00:91:63:83:FD:F6:31:5E:38:08:
AF:A7:5E:00:B7:0B:9B:1F:8B:FD:4D:7E:49:3C:43:E6:
64:E5:4B:F9:60:D7:89
Signed Certificate Timestamp:
Version : v1(0)
Log ID : 68:F6:98:F8:1F:64:82:BE:3A:8C:EE:B9:28:1D:4C:FC:
71:51:5D:67:93:D4:44:D1:0A:67:AC:BB:4F:4F:FB:C4
Timestamp : Nov 13 16:57:03.619 2014 GMT
Extensions: none
Signature : ecdsa-with-SHA256
30:45:02:20:61:4F:69:89:80:6A:62:2D:8E:A2:D0:24:
A5:E2:1D:74:67:51:77:C1:9B:DE:99:DE:16:56:2B:02:
77:A8:25:49:02:21:00:D3:41:6C:5D:88:40:F0:7A:FE:
E0:25:09:86:71:63:86:49:54:DD:96:E4:B5:9B:4A:84:
65:A9:25:12:F1:B7:E0
Signature Algorithm: sha256WithRSAEncryption
62:0c:d1:51:08:8a:a3:d1:df:bc:53:ba:e9:58:67:41:ea:5f:
e3:51:f2:0b:9d:24:b4:77:6a:cf:96:ff:c5:ce:1c:55:1e:77:
8a:49:46:7d:19:ef:52:4f:d3:24:b1:f2:95:60:67:40:d4:d1:
f4:27:e4:66:55:45:c6:a5:51:a6:87:d0:09:af:f6:48:9b:df:
24:c9:28:ad:47:b9:f6:a3:86:cb:64:64:3d:90:92:0e:94:f7:
d2:8b:d6:79:b4:df:f2:3f:f5:6e:ea:08:b3:b0:37:87:a3:30:
a7:f1:db:b7:86:b2:39:64:35:93:ee:5f:7b:01:51:5f:b1:e1:
e0:d1:5d:a6:e6:a3:53:3f:66:97:16:8f:18:c4:fa:fc:8e:85:
79:a1:95:7b:69:0b:f5:a4:92:1f:04:cf:ed:f6:95:e3:8f:b4:
2a:6a:be:0c:a2:b6:53:99:5d:50:78:23:1c:fb:cb:2e:1d:be:
b5:8d:83:2e:08:96:f8:c9:be:96:13:ed:61:0f:cf:57:44:ff:
3a:d5:10:b0:bd:08:1f:27:c4:cf:97:17:e8:6a:62:bc:6d:e9:
64:39:a0:36:79:d6:02:84:b7:47:26:9b:5d:b1:92:aa:f1:36:
1a:31:9e:27:f2:25:54:89:17:ac:56:54:b0:e0:41:67:e4:b8:
7b:e0:2c:88
如果您运行私有PKI,我不清楚如何实际创建其中之一。 OpenSSL支持OID:
$ grep -R "1.3.6.1.4.1.11129.2.4.2" *
crypto/objects/obj_dat.h:951, /* OBJ_ct_precert_scts 1 3 6 1 4 1 11129 2 4 2 */
crypto/objects/objects.txt:1 3 6 1 4 1 11129 2 4 2 : ct_precert_scts : CT Precertificate SCTs
和:
$ grep -R ct_precert_scts *
crypto/objects/obj_dat.h:0x2B,0x06,0x01,0x04,0x01,0xD6,0x79,0x02,0x04,0x02,/* [6191] OBJ_ct_precert_scts */
crypto/objects/obj_dat.h:{"ct_precert_scts","CT Precertificate SCTs",NID_ct_precert_scts,10,
crypto/objects/obj_dat.h:951, /* "ct_precert_scts" */
crypto/objects/obj_dat.h:951, /* OBJ_ct_precert_scts 1 3 6 1 4 1 11129 2 4 2 */
crypto/objects/obj_mac.num:ct_precert_scts 951
crypto/objects/objects.txt:1 3 6 1 4 1 11129 2 4 2 : ct_precert_scts : CT Precertificate SCTs
crypto/x509v3/v3_scts.c: {NID_ct_precert_scts, 0, NULL,
include/openssl/obj_mac.h:#define SN_ct_precert_scts "ct_precert_scts"
include/openssl/obj_mac.h:#define LN_ct_precert_scts "CT Precertificate SCTs"
include/openssl/obj_mac.h:#define NID_ct_precert_scts 951
include/openssl/obj_mac.h:#define OBJ_ct_precert_scts 1L,3L,6L,1L,4L,1L,11129L,2L,4L,2L
所以有演示/显示支持,但没有在OpenSSL的自说明代码中如何使用它的示例。通常,自我文档会通过功能在子命令中的使用显示在
<openssl src>/apps
目录中。证书?。评论
有人可以用外行的方式回答吗?网站所有者如何解决此问题?我们需要购买新证书吗?如果是这样,我们从哪里得到?我所有的站点都使用Register.com SSL证书,并且所有这些站点都收到此可怕的消息,吓跑了客户!
– MC9000
2015年4月21日在23:17
哦,用外行的话来说:准入门槛刚刚提高。如果您正在运行私有PKI,则将被迫从参与的CA购买证书。参与的CA必须发布经过认证的日志,以表明它们正在为其授权的域颁发证书。另请参阅CT常见问题解答,以了解其他两种方式。
–user29925
2015年4月21日在23:47
存在此问题的原因是:(1)CA不负责任或不负责任; (2)过去我们经历了许多CA失败。 CA不负责或不负责的原因是浏览器和CA在CA / Browser论坛上相互勾结。他们制定了适合自己口味的规则(是的,浏览器很复杂)。浏览器安全真是个玩笑...
–user29925
2015年4月21日在23:48
看来没有办法购买更“昂贵”的证书,! (这很荒谬,如果不对CA负责,那么为什么我们要为证书价格强奸?!我们要支付什么?!)
– MC9000
2015年4月23日在3:46
如果您正在运行私有PKI系统,则必须启动自己的日志服务器,并向Chrome添加命令行标志以信任它。然后,您必须从上述日志中获取SCT,然后使用TLS扩展名发送它。
– StackExchange用户
15年5月9日在16:12
评论
我看到您必须截屏才能导出消息。如果您认为将连接信息复制到Chrome之外更容易,请投票支持code.google.com/p/chromium/issues/detail?id=254249有没有人找到公共审计记录的例子?
有关公共审核记录的示例,请参见embed.ct.digicert.com。这是一个目的测试站点。也许明年我们会在真实网站(很可能是Google和Twitter)上看到透明度证明。
2015年2月更新:twitter.com现在可在Chrome浏览器中“公开审核”。您将看到一个链接“透明度信息”,以打开一个对话框“签名证书时间戳查看器”。