通配符SSL证书，自定义域名和Cloudflare(Wildcard SSL Certificates, Custom Domain Names, and Cloudflare)

通配符SSL证书，自定义域名和Cloudflare(Wildcard SSL Certificates, Custom Domain Names, and Cloudflare)

我有一个带通配符SSL证书的域名（ https://domainA.com ）。 我的用户使用自定义子域名（ https://user1.domainA.com ）。 我的用户希望使用指向其子域的自定义域（从https://domainB.com到https://user1.domainA.com的 CNAME记录）。

这些自定义域的问题是它们在浏览器中抛出SSL警告，因为SSL证书（https：//*.domainA.com）上的域名与用于访问该页面的域名不匹配（ https ：//domainB.com ）。

输入Cloudflare。

通过使用Cloudflare的完整SSL服务，在https://domainB.com上 ，我可以禁止SSL警告，以便用户不会遇到任何问题。 我知道存在SSL警告（因为禁用Cloudflare会导致警告重新出现），但Cloudflare会默默地解除警告并继续加密。

此外，通过使用完整SSL，我理论上在用户和服务器之间完全加密流量。

我的问题与此解决方案的安全性/合法性有关，要对用户可能希望用于访问其网页的任何域（ https://domainB.com,https: //domainC.com ）应用SSL加密（ https： //user1.domainA.com ）。

这样安全吗？ 这样安全吗？ 这是负责任的吗？

I have a domain with a wildcard SSL certificate (https://domainA.com). I have users who use custom subdomains (https://user1.domainA.com). I have users who wish to use custom domains that point to their subdomains (CNAME records from https://domainB.com to https://user1.domainA.com).

The problem with these custom domains is that they throw an SSL warning in the browser, as the domain name on the SSL certificate (https://*.domainA.com) does not match the domain name being used to access the page (https://domainB.com).

Enter Cloudflare.

By using Cloudflare's Full SSL service, on https://domainB.com, I can suppress the SSL warning so users experience no problems. I know that the SSL warning exists (as disabling Cloudflare will cause the warning to re-appear), but Cloudflare silently dismisses the warning and proceeds with the encryption.

Also, by using Full SSL, I am theoretically encrypting traffic completely between the user and the server.

My question has to do with the security/legitimacy of this solution, to apply SSL encryption any domains (https://domainB.com, https://domainC.com) that users may wish to use to reach their pages (https://user1.domainA.com).

Is this secure? Is this safe? Is this responsible?

最满意答案

这有几个因素。

一个是你对CloudFlare的信任程度。 在解密用户与用户之间的隧道并将其重新加密到源服务器之前，他们将以纯文本形式查看用户的流量。

其次，CloudFlare没有使用完整SSL（非严格）选项对服务器证书进行任何验证。 这意味着它不仅仅是域匹配：没有任何证书属性：发行者，时间范围等。 因此，有人可以在CloudFlare和您之间进行中间人攻击。

所以，我不会说它非常安全或安全，但它实际上取决于HTTPs通道上传递的数据类型。

如果你非常担心你的话，可能值得考虑从https://domainB.com到https://userX.domainA.com的 HTTP 301重定向而不是去CNAME记录，并使用CloudFlare的Full（严格）SSL用户数据。

There are a few factors to this.

One is how far you trust CloudFlare. They will see your users' traffic in plaintext, after decrypting the tunnel between them and the user and before re-encrypting it to the origin server.

Secondly, CloudFlare are not doing any validation of the server's certificate with the Full SSL (non-strict) option. This means that it's not just about domain matching: none of the cert attributes: issuer, time range et al are checked. Hence, someone can do a Man-in-the-middle attack between CloudFlare and you.

So, I wouldn't say it's very safe or secure, but it really depends on the type of data passing on your HTTPs channel.

It might be worth considering HTTP 301 redirect from https://domainB.com to https://userX.domainA.com rather than going for CNAME records, and using CloudFlare's Full (strict) SSL, if you're strongly concerned about your users' data.