阿里云的这个 SSL 证书认证真是有趣

2017-03-30 16:59:30 +08:00
 smileawei
申请阿里云证书的时候。提示框中一段提示:
CA 公司会优先检查 HTTPS 地址,如果域名开启了 HTTPS 服务,请确保证书是有效且可信机构颁发的,以免无法通过验证。

一台服务器上已经部署了一个 A 站点的 SSL 证书。这时候需要申请 B 站点的 SSL 证书。使用文件验证的话。按照阿里云 SSL 验证的逻辑,会在我未部署过 B 站点 SSL 证书的情况下访问 https://B 这个时候会拿到 A 站点的 SSL 证书并提示不可信。然后验证需要证书是有效且可信机构颁发。

这就尴尬了。

拿不到 DNS 管理权限。就没法通过阿里云申请 SSL 了。
10481 次点击
所在节点    全球工单系统
29 条回复
RqPS6rhmP3Nyn3Tm
2017-03-30 17:02:38 +08:00
把 Nginx 的 listen 443 ssl 删掉试试
smileawei
2017-03-30 17:04:24 +08:00
@BXIA 其实直接 ban 掉服务器的 443 就能解决。但是这个检查的逻辑真是有意思。
RE
2017-03-30 17:15:24 +08:00
这逻辑为啥问题?
你的 B 站点未部署 SSL 却响应了 A 的 SSL ,那是你服务器配置的问题。
优先检测 HTTPS 协议是 CA 公司的检测,也不是阿里的检测,何况只是优先检测 HTTPS 而不是不检测 HTTP
ovear
2017-03-30 17:37:50 +08:00
@RE 问题很大啊,如果你的服务器上不止一个网站。
a.b.com
b.b.com
如果这时候 a.b.com 的证书已经颁发并正常使用了
b.b.com 没有颁发,遇到上面的规则该怎么办
RE
2017-03-30 17:42:21 +08:00
@ovear
奇了怪了,这有啥问题?
如果原先的 a.b.com 的证书仅仅颁发给 a.b.com ,那就不应该响应给 b.b.com
如果是颁发给 *.b.com 的那就算响应给 b.b.com 也不会出现楼主说的 SSL 不正确的问题, HTTPS 照样可以访问啊。

b.b.com 看作一个独立网站的话(本来就是独立网站)该怎么配置 SSL 本来就不应该和服务器上另一个网站冲突,即便有 100 个站点也可以区分开,这跟服务器已经有多少个网站、域名有多少个子域都没关系。
RE
2017-03-30 17:43:33 +08:00
@ovear 既然 b.b.com 还没证书,自己非要监听 443 端口监听 https 协议,怪阿里云?怪 CA ?
kn007
2017-03-30 17:46:49 +08:00
这看起来没毛病啊。。符合逻辑。。。
ovear
2017-03-30 18:33:53 +08:00
@RE 你是不是没有搞清楚 端口和 Host 的区别。
对于一个 virtual host ,只要服务器上监听了 443 ,就会可以有响应。响应完毕之后( SSL 握手结束)才有所谓的 HOST 头( HTTP 协议)
阿里云这条规则肯定对应的 SNI 没有出现前,一个独立 IP 只能对应一个 SSL 证书。

那么请问一件事,谁规定了 a.a.com 一定要跟 b.b.com 两个 IP 放,我使用 SNI 的话,就不能避免在 http 服务器找不到对应的 vhost 的时候返回一个默认证书为了保证 443 正常回复数据。

我觉得你还不要忙着喷我,自己想一想自己说的话。如果有解决方法欢迎给出。
至于 A 网站和 B 网站分开两个 IP 放,这种话就不要说了。。
RE
2017-03-30 18:40:13 +08:00
@ovear 笑死我了,还能扯那么多,我自己的 VPS 就一个 IP 地址,十多个域名,七八个有 SSL ,其它的没有就响应 80 端口就行了,你真的搞懂 nginx / apache / iis 的配置了么???????
just1
2017-03-30 18:40:18 +08:00
明明是 443 端口 default_server 的问题。。。
RE
2017-03-30 18:47:58 +08:00
@ovear

真正要好好想想自己说的话的人是你,来,给你科普一下。

只要开放了 80 / 443 端口的访问,并且建立了 HTTP 服务,不管是基于 APACHE / NGINX 还是 IIS ,就有一个“默认网站”的概念,说的简单点,就是直接访问 IP 地址的时候,响应的网站。

如果你给 default 站点配置了 a.b.com 证书,那服务器上的其它站点只要是没有 SSL 的、却以 https 访问,就会响应 a.b.com 的证书,例如你访问了 b.b.comb.b.com 却没配置自己的 SSL 同时又监听了 443 端口。

你要解决方案?

解决方案就是 default 不应该放任何网站。

既然你知道 virtual host 那就多建立一个 a.b.com 的站点配置,而 b.b.com 是另一个配置,以此类推。

------

反过来说,即便不是阿里云,即便不是 CA 的规则,也要确保用浏览器能正确访问,才是硬道理。如果你给 b.b.com 响应了 a.b.com 的证书,浏览器访问也照样出错。
ovear
2017-03-30 18:56:23 +08:00
@RE 年轻人脾气不要这么差,小心以后出去吃大亏。。

另外你还是仔细看下我下面说的内容吧,没准可以帮到你。

端口和协议所在的层级都不一样,

我顺便详细说明下吧,可能我的表达也不是很清楚

首先科普下上面为什么说 端口 和 协议 是不同层级。
首先,端口是承载信息传递的一个通道,而 协议 是传输信息的一个规范。
通俗点比喻就是,你用 QQ 跟别人聊天,双方用的是英语,还是法语还是中文。
QQ 就可以类比为端口,使用的语言就可以比喻成协议

对于一个 IP ,只要监听了端口,那么就可以传输数据,比如说之前 https://www.v2ex.com/t/348752 说的, 80 端口也可以传输非 HTTP 数据。
好了,前提结束。

我的假设是,服务器支持 SNI ,且已经有线上的业务、域名有有效证书,能提供正常的 HTTPS 服务,那么此时 443 端口是通的,且能正常服务的(标准 HTTPS 协议)。
那么对于原始 HTTPS 协议,也就是 HTTP over SSL/TLS ,此时的服务端是无脑返回设置的证书,也就是 a.a.com 的证书,此时不存在一个 IP 对应多个 HTTPS 证书。所以也就可以做到 @RE 所说的不监听 443 端口。

但是问题在于,现在 SNI 出现了,在 TLS 加密握手之前,会传输一个 common name ,也就是所谓的 host name 。然后服务端根据 host 来确定返回哪个证书。这时候, IP 和证书的关系就变成了 一对多 关系。
所以阿里的这个规则就有问题了,也就是 @just1 说的 default_server 的问题。

我们这个场景, a.a.com 是正常服务的,说明服务端已经监听了 443 端口。而此时通过 443 端口访问 b.b.com 的时候,服务端会因为找不到该 common name 对应的证书,从而返回默认证书。
这个根据不同的服务端不同,比如说 Apache2.0 时代是按照 Host name 排序,返回第一个 Host 。而 Apache2.2/2.4 Nginx 以及衍生发行版,则是采用载入配置的第一个 host 最为默认的 default server 。


所以这时候问题就产生了,因为服务器返回了一个不是 b.b.com 的有效证书(包括 common name 不匹配 和 证书不受信任)。

我想说的是这么个问题。

至于对于某位同学,我是觉得,如果有解决方法不妨分享出来,没必要搞针对攻击。大家都是在讨论这个问题而已。
ovear
2017-03-30 19:02:17 +08:00
@RE 麻烦参考上面回答下列问题

1 、 default server 是怎么决定的
2 、 HTTPS 、 HTTP 、 STL 之间的关系
3 、 HTTPS 的握手过程大概有几个步骤
4 、网站没有内容就能阻断 HTTPS 握手了么?
rrfeng
2017-03-30 19:02:58 +08:00
看到这个讨论我想到一个问题:

server 段的 listen 443 其实是全局的,只要一个 virtual host 开启了 443 ,那么这个服务器就会响应 ssl 连接。
1. 不支持 SNI 的情况下,直接返回某个证书(不能判断域名)
2. 支持 SNI 的情况下,如果某个域名没有配置证书,那么也会返回另一个域名的证书

感觉无解
RE
2017-03-30 19:54:15 +08:00
@ovear 看到 14 楼 @rrfeng 说的后恍然大悟,并不能因为某个 virtual host 没有启用 https 而断了通过 443 而来的请求,而只要有请求进来总会返回某个证书。

感谢!
RE
2017-03-30 19:57:08 +08:00
@ovear 这么说的话,如果 CA 只检测 https 的链接,证书不符也就不去检测 http 的,那逻辑确实有问题了。除非把域名临时指向一个没有配置任何证书的服务器上。
bin456789
2017-03-30 20:32:58 +08:00
看到各位的回答真是高端

不过我觉得这事很简单
就是 ca 模拟正常的浏览器下载那个文件,能下载而且文件内容也匹配就通过验证
不就这么简单?
RE
2017-03-30 21:02:53 +08:00
@bin456789 问题在于 CA 首先访问的是 https 的地址,例如:

https://http://www.example.com/.wellknown/pki-validation/fileauth.txt

但一般情况下,要申请的域名是没有 SSL 证书的,所以上面这个地址并不能正确响应,如果用浏览器访问会提示证书错误。然后 CA 就认为是内容不符合,验证无法通过。

只能是关闭这台服务器的所有 443 端口, CA 发现 https 无法访问的时候才会去访问 http 的地址。

无法访问 ≠ 证书不正确。
RE
2017-03-30 21:03:22 +08:00
@bin456789 上面手误多复制了一个 http://
bin456789
2017-03-30 21:44:47 +08:00
@RE
先套个 Let's Encrypt 之类的证书就行了嘛
或者换个验证方式,不是应该有 cname txt 之类的验证吗?

阿里云的规矩就只有 https 可信这一条
虽然这个规矩好像是有点问题,但是解决的方法有很多
但是又不愿先搞个 Let's Encrypt ,又不愿关闭 443 ,又不能动 dns ,这不是自己捉虫吗?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/351518

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX