<story><title>Wildcard Certificates Coming January 2018</title><url>https://letsencrypt.org//2017/07/06/wildcard-certificates-coming-jan-2018.html</url></story><parent_chain><item><author>dijit</author><text>I strongly dislike wildcard certificates.&lt;p&gt;I worked in a few places that had a *.company.com which covered, obviously, everything under that domain.&lt;p&gt;That meant if that wildcard cert leaked then our EV cert for, say, checkout.company.com would be essentially compromised too.&lt;p&gt;Not to mention. If you have a wildcard cert it&amp;#x27;s rather likely you&amp;#x27;re passing those certs around servers, lots of scope for leakage.&lt;p&gt;I really think that if you feel the need to do wildcard certificates, then you should at least try to figure out another way around it. I&amp;#x27;m not saying you absolutely must never use them, but be incredibly mindful of what is at stake and limit the scope and availability of such certs as much as possible.&lt;p&gt;For instance. Don&amp;#x27;t put the same wildcard on mail servers and IM servers and git servers and etc; a compromise of one will compromise them all and the revokation system is not good enough.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.dijit.sh&amp;#x2F;please-stop-advocating-wildcard-certificates&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.dijit.sh&amp;#x2F;please-stop-advocating-wildcard-certif...&lt;/a&gt;</text></item></parent_chain><comment><author>mnutt</author><text>I agree that wildcards aren&amp;#x27;t great if they&amp;#x27;re being passed around an organization to avoid registering a few extra certs, but they are very useful in a few circumstances such as sandstorm.io: every app session uses a different subdomain to prevent cookie leakage, and registering that many certs would overwhelm LE. I&amp;#x27;d imagine there are other cases out there involving automatically created subdomains that will benefit.</text></comment>
<story><title>Wildcard Certificates Coming January 2018</title><url>https://letsencrypt.org//2017/07/06/wildcard-certificates-coming-jan-2018.html</url></story><parent_chain><item><author>dijit</author><text>I strongly dislike wildcard certificates.&lt;p&gt;I worked in a few places that had a *.company.com which covered, obviously, everything under that domain.&lt;p&gt;That meant if that wildcard cert leaked then our EV cert for, say, checkout.company.com would be essentially compromised too.&lt;p&gt;Not to mention. If you have a wildcard cert it&amp;#x27;s rather likely you&amp;#x27;re passing those certs around servers, lots of scope for leakage.&lt;p&gt;I really think that if you feel the need to do wildcard certificates, then you should at least try to figure out another way around it. I&amp;#x27;m not saying you absolutely must never use them, but be incredibly mindful of what is at stake and limit the scope and availability of such certs as much as possible.&lt;p&gt;For instance. Don&amp;#x27;t put the same wildcard on mail servers and IM servers and git servers and etc; a compromise of one will compromise them all and the revokation system is not good enough.&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.dijit.sh&amp;#x2F;please-stop-advocating-wildcard-certificates&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.dijit.sh&amp;#x2F;please-stop-advocating-wildcard-certif...&lt;/a&gt;</text></item></parent_chain><comment><author>hakanensari</author><text>There are legitimate use cases: for instance, a multi-tenant app that designates tenant by subdomain.</text></comment>