&gt; But consider an attacker who pivots onto your entire infrastructure to serve any content they desire.<p>I mean, if we&#x27;re talking about a situation where an attacker <i>controls</i> your webserver, then that&#x27;s pretty much game over, right? They can read and write to <i>everything</i> your server can, including SSL private keys, SQL databases, etc., etc., etc...<p>&gt;  Presumably your DNS provider passwords are stored in a password manager outside of that infrastructure. ... It seems that would have prevented the abuse in the OP, right?<p>Doing DNS-record-alteration-only verification would have prevented the scenario described in TFA, yeah. But, there are a couple of things to consider:<p>* DV certs provide nothing more than HTTPS, without the scary &quot;THE BROWSER DOESN&#x27;T RECOGNIZE THIS CERT ISSUER!!11&quot; dialog. They <i>don&#x27;t</i> provide the additional UI cues that EV certs do. So, their phishing utility is <i>rather</i> limited.<p>* Society as a whole benefits <i>far</i> more from thwarting passive dragnet surveillance than it does from putting roadblocks in the way of occasional unauthorized and unwanted issuance of a DV cert to someone who has improperly (effectively) gained control of someone else&#x27;s web server or DNS zone.<p>* TFA is primarily a scare-piece from a traditional CA &lt;strike&gt;that&#x27;s likely sad that their revenue stream from DV issuance is going to vanish.&lt;&#x2F;strike&gt;<p>Ugh. I actually got off my ass and did some research... it seems that Trend Micro doesn&#x27;t issue DV certs. [0] Mea culpa.<p>[0] <a href="http:&#x2F;&#x2F;esupport.trendmicro.com&#x2F;solution&#x2F;en-US&#x2F;1097653.aspx" rel="nofollow">http:&#x2F;&#x2F;esupport.trendmicro.com&#x2F;solution&#x2F;en-US&#x2F;1097653.aspx</a>