在一个使用tls在公网上传输数据的应用里,出现了以下症状:
1.如果使用挂靠在Cloudflare上的域名,应用在tls握手时会报告CN/CA错误(该应用由于特定原因,其信任的CA需要手动指定,不会信任其他来源的CA),原来指定的是应用服务端所使用的Lets Encrypt的CA。
2.把域名换成服务端的ip来绕过Cloudflare,工作就正常了。
在思考了半天后,终于发现了我犯的一个低级错误。
TLS流量和HTTP Plain流量不同,在被CDN转发的时候会被解密,在客户端和CDN进行TLS握手的时候,CDN会提交CDN服务器域名的证书,(在Cloudflare里称为Edge Certificates),该证书是签发给CDN服务器域名的,客户端一检查,发现CN和CA都和服务端对不上,就寄了。
在这种情况下,肯定不能再要求客户端去检查CN了(因为CDN服务器的域名是在频繁变动的),但如果想保持服务端的数据是使用TLS加密的,可以使用 Cloudflare的Origin Certificates功能。
Origin Certificates是由Cloudflare签发给服务端的证书,有效期默认特别长。将该证书添加到服务端代替原来的LetsEncrypt,从CDN出来去服务端的流量就会用这个证书进行TLS加密,过程大致如下。
客户端<===>Edge Cert<===>CDN服务器<===>Origin Cert<===>服务端
这样的过程,既利用了CDN,又实现了全程的TLS加密,满足了安全性和便捷性的要求。
另外开启Origin Certificates的时候,TLS的总设置应该调到Full或者Full Strict的位置,不然Origin Cetificates不能生效,从CDN到服务端的流量就不能受到TLS的保护。
在这种情况下如果要绕过CDN直接连接服务端,只需要让客户端信任Origin Certificates,然后打开Cloudflare DNS的Bypass或者用服务器ip直接连接就好了。