With the proliferation of low-cost automated CAs what can be done to mitigate the attack of someone doing a spear phishing attack to get a login to our webmail system, then using an automated service like RapidSSL to issue a new certificate for widgetco.com to [email protected]?

I am sure some eyebrows would be raised at RapidSSL, if someone like google.com requested a certificate. Is there anything I can do too?

  • 3
    Don't most (all?) ssl providers only allow verification from a specific list of email addresses for a given domain? Commented Jun 2, 2013 at 16:32
  • Bogus certificates can be detected using Certificate Transparency. For more info, see certificate-transparency.org
    – Rob W
    Commented Apr 12, 2016 at 13:38
  • For really important stuff, it's worth it to get an EV (extended validation) certificate which will display also company name in the browser. These are somewhat harder to get through simple phishing attacks.
    – jpa
    Commented Aug 13, 2016 at 15:07

4 Answers 4


This is really a matter of each CA's policies. Most of them require proof of ownership of a domain before issuing a certificate. Even with cheap CAs this usually involves either verifying an e-mail can be received by a WHOIS contact or making entries in the DNS records for the domain.


I agree with AJ that even cheap CAs involve verifying emails from data retrieved from a WHOIS request. But this sort of verification often has many holes in it and doesn't cryptographically ensure the validation. That is an attacker who can eavesdrop/alter unencrypted traffic on the internet can potentially:

  • intercept the email sent over the internet from the CA (SMTP is plaintext protocol; only sometimes sent with TLS),
  • alter the DNS response (again often sent in plaintext) for the domain of the administrative contact where the email is sent to,
  • do an ARP spoofing attack on the CA which again directs traffic from the CA to another computer,
  • alter the WHOIS request the CA makes (replacing the administrative contact email address with an attacker controlled address).

An attacker who can pull off any of these attacks should be able to then generate a CA-signed certificate. Again, these generally aren't the types of attacks that script kiddies could do, but an ISP or government potentially could do.

  • 2
    It's worth pointing out that a governmental agency that is local to the CA could also probably just force the CA to issue a cert without much in the way of tricks if they really wanted to. Commented Jun 2, 2013 at 19:42
  • @AJHenderson - Agree completely. My point was the (weak) verification of free certificates has holes that people who can alter HTTP traffic may also be able to attack (not that powerful adversaries wouldn't have other options). Personally, I couldn't force you to go to the wrong IP when you try looking at security.stackexchange.com (as I don't control computers/routers in the path from your computer to SEC.SE), but others can (e.g., on your/SEC.SE local network or control a router between you). Not to say its hopeless; there are solutions (e.g., DNSSEC, doing WHOIS over TLS, etc.)
    – dr jimbob
    Commented Jun 2, 2013 at 20:22
  • well actually for sec.se it is hopeless since there is no SSL so DNSSEC wouldn't do any good if they can fake an IP address. But yes, I get your point. Commented Jun 3, 2013 at 4:32
  • @AJHenderson - Sorry that was confusing--I tried making two points. (1) While eavesdropping/altering HTTP/unencrypted data is straightforward to a local attacker (on your network/access your computer); I couldn't get you to go to an IP I control when you type the URL of sec.SE, even over HTTP with no crypto. A CA doing validation using unencrypted data over the internet is not trivial to attack; an average adversary can't MitM a CA doing a WHOIS query; most email uses TLS, etc. (2) Even so, crypto (DNSSEC, etc) could stop powerful adversaries (who in principle could do those attacks).
    – dr jimbob
    Commented Jun 3, 2013 at 14:40

Browser and OS vendors (Firefox, Chrome, Microsoft...) include CA certificates in their default "trusted CA store" under some stringent conditions about how the CA operates -- its Certification Practice Statement. The premise is that if a CA misbehaves, e.g. by being too easy to swindle into issuing forged certificates, then the browser/OS vendors will remove the CA from the default trusted CA store. And the browser/OS vendors will do that only if it fits their own interest, a concept which is best expressed in financial terms.

So the only thing you can do, really, is to keep your lawyer primed and ready to fire. If a CA misbehaves and issues a fake certificate for your domain, threaten the CA, and threaten the browser/OS vendors, who must, by necessity, be the ones who ensure the cleansing of default trust stores. Ultimately, it is all a question of market pressure. "Fear will keep the local systems in line."


AJ got it right, there's very little a customer can do. The nature of this system is interesting in that it doesn't matter what the customer does, they can still be victimized. Going with a top-tier CA (and probably paying more) doesn't make you safe, any of the other CAs can issue a cert for your domain.

In a sense, the browser makers are the real customers of the CA. They accept and use the product of the CAs in the form of signed certs. If a CA behaves badly or has poor practices that lead to malicious certs, the browsers manufacturers can choose to remove that CA from their trusted store. That's probably a difficult call because removing a CA could impact a huge number of sites and businesses.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .