SSL 萬用字元證書和“www”子子域

我有一個萬用字元 SSL 證書*.example.com。

我正在使用 Nginx，並將 HTTP 的所有流量重定向到 HTTPS，並重寫 URL 以刪除 www 子域（如果有的話）。

所以它有，

1. http://subdomain.example.com —>https://subdomain.example.com
2. http://www.subdomain.example.com —>https://subdomain.example.com
3. https://www.subdomain.example.com —>https://subdomain.example.com
4. https://subdomain.example.com —>https://subdomain.example.com

但是，由於我的證書是 for *.example.com，因此案例 3 在 chrome 中出現 SSL 錯誤（“這可能不是您要查找的站點！”），但是如果您點擊它，它將被重定向，一切都很好。

我明白為什麼，因為初始連接是用於帶有 www（2 級子域）的 HTTPS，這與萬用字元證書上的內容不匹配。

我認為一個解決方案是獲得一個額外的證書*.*.example.com來覆蓋www.*.example.com。但這似乎行不通。我與 Namecheap 和 Comodo 的代理商進行了交談，他們都說*.*.example.com不可能。

我還看到這篇文章說：

SSL 可以與多級萬用字元一起使用嗎？

隨著 Firefox 3.5 的發布，所有主流瀏覽器只允許單級子域與包含萬用字元的證書名稱匹配，符合 RFC 2818。

換句話說，證書*.mydomain.com適用於one.mydomain.comortwo.mydomain.com但不適用one.two.mydomain.com。

有針對這個的解決方法嗎？能夠覆蓋www.*.example.com？

萬用字元證書僅深入一級。您將需要獲得一個萬用字元，該萬用字元還具有所有www.<subdomain>.example.com站點的主題備用名稱。這將允許重定向發生。

除了將有效證書放在兩級深子域上之外的任何解決方案都將不起作用，因為 SSL 握手將始終發生在任何重定向或重寫之前。

小的解決方法是在建立 SSL 連接之前重寫 URL，但是在獲得此域名的證書之前，您永遠不會在沒有警告的情況下讓https://www.subdomain.mydomain.com正常工作。像這樣的東西：

server {
listen 111.222.333.444:80;
server_name www.subdomain.mydomain.com;

rewrite ^ https://$host$request_uri permanent;
}

server {
listen 111.222.333.444:443
server_name subdomain.mydomain.com
ssl on;
...
}

引用自：https://serverfault.com/questions/520556