一些客户端接受 SSL 证书；其他人拒绝它
Posted
技术标签:
【中文标题】一些客户端接受 SSL 证书；其他人拒绝它【英文标题】：Some clients accept SSL cert; others reject it 【发布时间】：2014-10-03 04:46:01 【问题描述】：一些 HTTP 客户端接受此证书，而另一些则不接受。有什么不同？
Java 拒绝它。
((javax.net.ssl.HttpsURLConnection)new java.net.URL("https://www.lucidpress.com")
.openConnection())
.getInputStream()
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: 没有主题 找到与 www.lucidpress.com 匹配的备用 DNS 名称。 在 sun.security.ssl.Alerts.getSSLException(Alerts.java:192) 在 sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1715) 在 sun.security.ssl.Handshaker.fatalSE(Handshaker.java:257) 在 sun.security.ssl.Handshaker.fatalSE(Handshaker.java:251) 在 sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1168) 在 sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153) 在 sun.security.ssl.Handshaker.processLoop(Handshaker.java:609) 在 sun.security.ssl.Handshaker.process_record(Handshaker.java:545) 在 sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:963) 在 sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1208) 在 sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1235) 在 sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1219) 在 sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:440) 在 sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185) 在 sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139) 在 sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
Python 请求拒绝它。
import requests
requests.get('https://www.lucidpress.com')
Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 55, in get
return request('get', url, **kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/api.py", line 44, in request
return session.request(method=method, url=url, **kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 456, in request
resp = self.send(prep, **send_kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 559, in send
r = adapter.send(request, **kwargs) File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 382, in send
raise SSLError(e, request=request) requests.exceptions.SSLError: hostname 'www.lucidpress.com' doesn't match either of '*.lucidchart.com', 'lucidchart.com'
cURL 接受它。
$ curl -v https://www.lucidpress.com
关于 connect() 到 www.lucidpress.com 端口 443 (#0) 正在尝试 54.236.129.63... 已连接 成功设置证书验证位置： CAfile：无 CApath：/etc/ssl/certs SSLv3、TLS 握手、客户端问候 (1)： SSLv3、TLS 握手、服务器问候 (2)： SSLv3、TLS 握手、CERT (11)： SSLv3、TLS 握手、服务器密钥交换 (12)： SSLv3，TLS 握手，服务器完成 (14)： SSLv3、TLS 握手、客户端密钥交换 (16)： SSLv3，TLS 更改密码，客户端问候 (1)： SSLv3，TLS 握手，完成 (20)： SSLv3，TLS 更改密码，客户端问候 (1)： SSLv3，TLS 握手，完成 (20)： 使用 DHE-RSA-AES256-SHA 的 SSL 连接 服务器证书： 主题：OU=域控制已验证； CN=*.lucidpress.com 开始日期：2014-05-12 16:20:34 GMT 有效期：2015-07-09 22:19:45 GMT subjectAltName：www.lucidpress.com 匹配 发行人：C=US； ST=亚利桑那州； L=斯科茨代尔； O=GoDaddy.com, Inc.；欧=http://certs.godaddy.com/repository/; CN=Go Daddy Secure 证书颁发机构 - G2 SSL 证书验证正常。
wget 拒绝它。
wget https://www.lucidpress.com
--2014-08-09 19:55:41-- https://www.lucidpress.com/ 正在解析 www.lucidpress.com (www.lucidpress.com)... 107.23.98.6, 54.236.129.63, 54.88.154.168 连接到 www.lucidpress.com (www.lucidpress.com)|107.23.98.6|:443... 已连接。 错误：否 证书主题备用名称与请求的主机名匹配 'www.lucidpress.com'。要不安全地连接到 www.lucidpress.com，请使用 '--no-check-certificate'。
Chrome、FF 和 IE 都接受。
为什么行为不同？
【问题讨论】：
“SSLError: hostname 'www.lucidpress.com' 不匹配 '*.lucidchart.com', 'lucidchart.com'” – 看起来像提供的 SSL 证书适用于不同的域…… @CBroe，那为什么 cURL 和浏览器会接受呢？ 尝试验证在这两种情况下都提供了相同的证书。 @jww，如果有帮助，我相信www.lucidchart.com 和www.lucidpress.com 实际上可能是同一个主机，试图根据主机名提供证书。
@Paul - 添加了有关 DNS、SNI 和证书的附加信息。我不敢相信我没有注意到这些名字是不同的......
【参考方案1】：
一些 HTTP 客户端接受此证书，而另一些则不接受。有什么不同？
简短的回答：负载平衡、虚拟主机和 SNI。
长答案...首先，这是对证书的分析。我们需要仔细检查以确保没有明显的错误。
从下面的转储中，公用名中有一个通配符 DNS 名称。 IETF 和 CA/浏览器论坛均不赞成在 CN 中放置 DNS 名称。应在 CN 中放置一个“友好名称”，因为它会显示给用户。虽然它已被弃用，但它并未被禁止。
相反，DNS 名称应该放在主题备用名称中。应该有两个。第一个是lucidpress.com，第二个是*.lucidpress.com。您只需要lucidpress.com，因为通配符需要匹配标签。
作为参考，IETF 在RFC 6125 第 3.1 节 服务器身份 中弃用了 CN 中的 DNS 名称；和第 6.4.4 节 检查通用名称。
CA/浏览器论坛在Baseline Requirements (BR) 第 9.2.2 节 主题公用名字段 中弃用 CN 中的 DNS 名称。此外，根据 CA/B，主题备用名称 是必需的。请参阅第 9.2.1 节 主题备用名称扩展。
相关：RFC 6125 第 6.4.3 节也不允许将*.lucidpress.com 匹配到lucidpress.com。 CA/B BR 在第 11.1.3 节中涵盖了通配符，但没有讨论匹配规则。
有了上面的背景信息和下面的证书，这就是发生的事情。
默认证书中有 2 个名字。它默认由 Apache 提供，因为它是 first virtual host in the configuration file。
lucidchart.com
*.lucidchart.com
您在 Lucid Press 的证书中有 2 个名字。
lucidpress.com
*.lucidpress.com
我认为区别在于服务器名称指示 (SNI)。它是 TLS 扩展，因此您需要 TLS 1.0 或更高版本。那些没有问题的人获得了 Lucid Press 证书并使用 TLS 1.0 或更高版本和 SNI；那些有问题的人获得默认证书并使用 SSLv3 或没有 SNI。 Windows XP 将使用 TLS 1.0 但不 SNI，因此由于部署基础，它经常在现场体验。
浏览器接受它是因为它们使用 TLS 1.0 或更高版本并发送 SNI 扩展。因为 SNI 允许您的 Apache 服务器在握手期间选择正确的证书，所以不存在名称匹配问题。
Java 拒绝它，因为它使用 SSLv3，即使您说 SSLContext.getInstance("TLS");。您必须跳过一些障碍以确保您真正获得 TLS 1.0 及更高版本。 Stack Overflow 上有几个关于它的问题。例如，请参阅Which Cipher Suites to enable for SSL Socket?。
Python 拒绝它，因为我猜你正在使用 2.x，或者你正在允许 SSLv3。您需要 3.0 或更高版本才能获得 SNI。请参阅 Python 常见问题解答中的 Python 3 Support?。
wget 在version 1.14 中添加了对 SNI 的支持。我怀疑wget 没有启用它或使用 SSLv3。
cURL 可能会确保使用 SNI（如果可用）。 Daniel 非常周到，他努力确保开箱即用的无故障体验和安全姿势。
在 OpenSSL 转储中，感兴趣的选项是 -tls1 -servername。您可以通过省略-servername 来获得没有 SNI 的TLS。所以你需要tls1 和-servername <host>。
$ openssl s_client -tls1 -servername www.lucidpress.com \
-connect www.lucidpress.com:443 | openssl x509 -text -noout
depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify error:num=19:self signed certificate in certificate chain
verify return:0
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12250220837273305 (0x2b8582cd6cfed9)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certs.godaddy.com/repository/, CN=Go Daddy Secure Certificate Authority - G2
Validity
Not Before: May 12 16:20:34 2014 GMT
Not After : Jul 9 22:19:45 2015 GMT
Subject: OU=Domain Control Validated, CN=*.lucidpress.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:c8:e0:f6:77:03:c9:5e:cb:51:e3:d3:7a:b6:60:
d9:3d:60:26:9c:4b:00:c5:cb:b1:55:2e:d9:ee:f5:
08:8d:b7:64:e9:31:2e:83:e4:24:f3:89:4e:46:87:
b8:55:b6:34:0a:c9:3b:55:08:10:77:13:7e:85:d6:
8c:fa:06:dd:c1:7f:fa:9e:13:c8:1a:d8:36:22:3c:
cb:16:9f:cb:c7:5b:7c:7c:0b:6d:c3:ef:24:45:15:
5a:7a:38:dd:df:83:eb:c3:ea:9b:57:d5:8f:d8:6c:
ff:33:4a:21:02:2a:92:9a:e0:5d:58:51:75:07:b6:
ad:21:8c:34:91:20:f5:00:9e:f6:dd:90:7e:a8:60:
0e:14:73:de:90:a1:f4:29:83:a0:d8:9d:29:e5:de:
c5:cb:b5:36:84:ba:30:d4:a9:9f:b9:bf:89:26:e5:
80:5a:f6:3b:27:cc:6d:3f:31:1e:cc:51:09:12:73:
a6:de:da:b9:a4:19:86:68:7f:e6:2b:c7:3b:a6:ce:
6a:5a:dd:c9:ac:61:18:80:f5:d4:f1:6a:70:2c:9f:
8f:af:a6:c5:1d:78:97:97:90:92:6c:21:61:39:ce:
f8:c9:99:e2:02:b5:ce:ba:dc:f4:46:ba:e3:1f:ec:
ce:a5:e4:6b:56:1e:e6:20:89:44:7b:2c:9f:3a:c4:
33:f1
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.godaddy.com/gdig2s1-59.crl
X509v3 Certificate Policies:
Policy: 2.16.840.1.114413.1.7.23.1
CPS: http://certificates.godaddy.com/repository/
Authority Information Access:
OCSP - URI:http://ocsp.godaddy.com/
CA Issuers - URI:http://certificates.godaddy.com/repository/gdig2.crt
X509v3 Authority Key Identifier:
keyid:40:C2:BD:27:8E:CC:34:83:30:A2:33:D7:FB:6C:B3:F0:B4:2C:80:CE
X509v3 Subject Alternative Name:
DNS:*.lucidpress.com, DNS:lucidpress.com
X509v3 Subject Key Identifier:
CA:97:CC:32:09:20:3E:5F:23:05:4C:DD:F2:DA:4B:1C:E5:02:E8:69
Signature Algorithm: sha256WithRSAEncryption
4e:0c:8e:af:d5:c7:06:9e:b9:2c:36:97:d0:9e:1c:84:e8:e1:
69:5a:36:a3:4f:9f:81:c9:78:5d:ca:35:df:63:be:23:88:4c:
ba:eb:17:15:22:78:96:5d:5f:dc:3b:fa:cf:14:b6:e9:3a:fe:
28:19:1c:85:d2:1b:23:b3:79:6d:b2:1d:76:6b:84:97:80:43:
1b:c0:b7:14:78:75:f9:47:31:6e:21:56:0d:5e:73:ed:d3:b2:
4b:ab:dc:b0:af:18:ee:2d:bb:65:ff:c7:cb:ff:53:64:8f:a5:
e8:aa:45:da:fc:0f:b5:8f:da:0f:3e:b1:3b:d0:47:49:52:af:
8d:f7:a3:42:3b:d3:a1:f4:a1:22:d5:fe:2f:4c:59:b4:18:3f:
62:1e:4e:56:65:9b:2b:d6:76:cd:29:74:d6:74:a4:7b:bb:6f:
b2:1d:45:12:67:14:b3:06:a7:36:ee:3a:48:d1:d6:80:2b:fa:
6d:8b:64:01:0f:1e:51:48:0f:8b:e3:7d:13:86:79:a2:b2:04:
05:cb:8d:07:35:d9:fa:7e:6d:5d:42:c0:a5:f4:b2:8e:57:53:
24:b3:aa:e6:92:b1:70:07:73:98:00:91:9b:0f:3e:6e:fe:1d:
78:7c:57:68:47:d7:8e:6f:1a:64:26:7b:69:f5:b1:13:c2:71:
2d:ac:56:b6
$ dig www.lucidchart.com
; <<>> DiG 9.8.5-P1 <<>> www.lucidchart.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19608
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.lucidchart.com. IN A
;; ANSWER SECTION:
www.lucidchart.com. 8 IN CNAME chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com.
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 10 IN A 107.23.98.6
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 10 IN A 54.236.129.63
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 10 IN A 54.88.154.168
;; Query time: 23 msec
;; SERVER: 172.16.1.10#53(172.16.1.10)
;; WHEN: Sun Aug 10 00:02:52 EDT 2014
;; MSG SIZE rcvd: 160
$ dig www.lucidpress.com
; <<>> DiG 9.8.5-P1 <<>> www.lucidpress.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34260
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.lucidpress.com. IN A
;; ANSWER SECTION:
www.lucidpress.com. 599 IN CNAME chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com.
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 59 IN A 54.88.154.168
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 59 IN A 107.23.98.6
chart-production-webserver-1858537325.us-east-1.elb.amazonaws.com. 59 IN A 54.236.129.63
;; Query time: 48 msec
;; SERVER: 172.16.1.10#53(172.16.1.10)
;; WHEN: Sun Aug 10 00:02:38 EDT 2014
;; MSG SIZE rcvd: 160
如果有兴趣，这是来自sslscan：
Prefered Server Cipher(s):
SSLv3 256 bits DHE-RSA-AES256-SHA
TLSv1 256 bits DHE-RSA-AES256-SHA
TLSv1.1 256 bits DHE-RSA-AES256-SHA
TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384
【讨论】：
我使用的是 Python 2.x。出色的分析。 谢谢。我怀疑 SNI 是实现虚拟主机（一个主机，多个主机名）的唯一方法，是吗？ @Paul - 是的，您需要 (1) 每个主机的唯一 IP；或 (2) 客户端的 SNI（服务器会做正确的事情）。您不能使用主机标头，因为在发送和解析请求时已经发生 SSL 握手。 我确实在使用 wget 1.13.4，这是 Ubuntu 12.04 的默认 PPA 中的版本。 Ubuntu 13.04+ 有 wget 1.14。 @Paul - IETF 正在开展的其他工作可能对这里有所帮助：Application Layer Protocol Negotiation。您可以从 HTTP 开始并使用主机标头，然后切换到 HTTPS。但目前只是草稿。以上是关于一些客户端接受 SSL 证书；其他人拒绝它的主要内容，如果未能解决你的问题，请参考以下文章
为啥 Python 的“请求”拒绝我的 SSL 证书，浏览器接受