SSL通配符证书和“www”

我有* .example.com的通配符SSL证书。

我正在使用nginx,并将http的所有stream量redirect到https,还重写了不带尾随www的URL(如果有的话)。

所以呢,

  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

但是,由于我的证书是* .example.com,案件3在chrome('这可能不是您正在查找的网站!')中获取SSL错误,但是如果您点击它,则会被redirect,一切都很好。

我明白了为什么,因为最初的连接是用于https的www(2级子域),它与通配符证书上的内容不匹配。

我认为解决scheme是获得*.*.example.com的附加证书来覆盖www.*.example.com 。 但似乎是行不通的。 我和来自namecheap和comodo的代理交谈过,并且都说*.*.example.com是不可能的。 我也遇到了这篇文章

有针对这个的解决方法吗? 为了能够覆盖www.*.example.com

  • 通配符SSL之间的区别
  • 双通配符SSL证书
  • 3 Solutions collect form web for “SSL通配符证书和“www””

    通配符证书只能进入一个级别。 您将需要获得一个通配符,该通配符还具有所有www.<subdomain>.example.com站点的备用名称。 这将允许redirect发生。

    除了在两级深度子域上放置有效证书之外的任何解决scheme都将不起作用,因为SSL握手将始终在任何redirect或重写之前发生。

    小的解决方法是在build立SSL连接之前重写URL,但是在获得此域名的证书之前,您将永远无法使https://www.subdomain.mydomain.com正常工作,而不会收到警告&#x3002; 类似的东西:

     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; ... } 

    问题是通配符证书如何工作。 他们只能在您看到的第一级子域上工作。 要解决这个问题,你需要使用一个PTRlogging来指向www.subdomain.domain.com到subdomain.domain.com,它应该是服务器不可见的。

    服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器.