SSL certificate authorities put us all at risk by handing out certs for "mail" "webmail" and other unqualified domains


14 Responses to “SSL certificate authorities put us all at risk by handing out certs for "mail" "webmail" and other unqualified domains”

  1. Anonymous says:

    I am a person who regularly orders and renews several SSL certificates through one of the providers above as a reseller, through an online web ordering tool provided by them.

    In the past, you could order a domain name for anything. There was an option to clarify the information presented in the CSR, but you did not have to validate it. There was also a checkbox that simply said “I certify I own this domain” or something to that affect, but your order would go through regardless. I’ve made more than one mistake on my csr with regards to a typo and I still received the certificates (things like mydomain.comx or Typically, I would have my request returned via email within a minute regardless of any error.

    Since the breach a couple weeks ago, these request now take 2-4 days to return an order, and I am being scrutinized for details like my company name being different than the whois entry, or having the the incorrect address (zip code) for one of my submissions.

    Though it doesn’t account for the negligence in the lack of auditing of the reseller customers, I think that the company I am working with is actually taking proper measures to increase security and finally review these submissions.

  2. Anonymous says:

    If your company has a server named “mailserver” using unqualified certs, and you have a typically configured corporate laptop, you can’t safely use it outside the company’s office building.

    Scenario: You go to starbucks. I’m there with my laptop and my nice, fully validated “mailserver” cert on my machine. You boot, and your email agent sends me your password. Have a nice day!

    In case anybody wonders why this happens, it’s because Old Fart Unix Bigots are still telling everyone to use unqualified names for hosts just like they did at Berkeley when everyone used the R-utilities and dropped acid on the job. This breaks lots of SSL stuff unless you get an unqualified cert.

    At any *nix shell prompt (use bash on linux) just type “unname -n” and hit enter. If the name that comes back is unqualified – like say “mailserver” instead of “” – then your sysadmin need re-education. There is no excuse for using unqualified host names on the hosts themselves – the DNS system replaced host tables 20 years ago or more, your resolver will automagically supply the domain for you if you can’t type.

  3. Anonymous says:

    In this instance, the organization should be signing its own certs and have an in house CA cert distributed to all clients.

  4. traalfaz says:

    So let’s revoke the CA trust for any authority that does this. Let the fun begin!

  5. ColHapablap says:

    “Such an attacker would be able to perfectly forge the identity of your organization’s webmail server in a “man-in-the-middle” attack!”

    This really only works if you’re accessing the webmail server on the local network using an unqualified domain name. In which case, the attacker would also have to be on the local network, or have some other clever way of routing the local traffic to a remote server in the “middle”.

  6. Joe says:

    The reason why people ask for, and get, SSL certificates like this is because of a defect in the way browsers do SSL connections. Let’s say that my company has an Exchange server whose address is If it speaks HTTP, I can talk to it with http:://exchange or just “exchange”. But if I type https://exchange, both IE and Firefox throw a fit, with a long scary message that the cert is for the wrong host, This is even though, when the browser asked for the translation of “exchange”, it knew or should have known that the match was found by expanding “exchange” to “”. So what we need to do is fix browsers so they don’t scream about “name mismatches” that are not mismatches at all. Then and only then can we revoke those bogus SSL certificates on hostnames with no dots in them.

    • dculberson says:

      Could the web server redirect a request for https://exchange to

    • Todd Knarr says:

      @Joe: the problem is that the browser *doesn’t* know the match was found at “”. The browser asked the local resolver for “exchange”. The local resolver returned the IP address. Only the local resolver knows it failed to get an address for “exchange”, appended the domain suffix “”, tried again and got a result, and the resolver isn’t telling. That makes it possible to use hostnames on the local network without apps knowing anything about what the local network’s called, and you can change the local DNS domain by changing configuration just within the resolver. Now though there’s a mismatch between how things were designed (apps are oblivious to the local network configuration) and what we want to do (apps are sensitive to the local network configuration).

      • Joe says:

        Sorry, Todd, I’m not buying it. True, the resolver is the place where was added, but when the browser sees the mismatch, it can guess that this is what has happened, and it can verify the guess by asking for and verifying that the IP address is the same. Alternatively it could just directly access

        Your explanation describes internal details that aren’t the user’s concern. The important point is that when the browser is capable of verifying that the correct host was reached, it should just do so instead of alarming the user.

    • Anonymous says:

      The defect is in your user, and in your host resolution. You should

      a. never use “http://exchange/” but always use “http://exchange.mydomain.tld/”

      b. have either hosts files on the machines that maps exchange.mydomain.tld to the local IP address, OR

      c. have an internal DNS.

      The latter is VERY easy to do on a Windows domain, as DNS is a necessary part of ActiveDirectory, and ActiveDirectory is a necessary part of Exchange Server. So no, there is no bloody excuse for an unqualified cert for the hostname “exchange”.

  7. show me says:

    They didn’t hand out certs for “mail” and “webmail”, at least not according to the article. The article says “What if” they handed out these certs.

    • Anonymous says:

      I did read the article.

      In the Observatory we have discovered many examples of CA-signed certificates unqualified domain names. In fact, the most common unqualified name is ‘localhost’, which always refers to your own computer! It simply makes no sense for a public CA to sign a certificate for this private name. Some CAs have signed many, many certificates for this name, which indicates that they do not even keep track of which names they have signed. Some other CAs do make sure to sign ‘localhost’ only once. Cold comfort!” Palmer, the technology director of the EFF, wrote in an analysis of the certificate data.

      Nice try, though. You work for Verisign?

  8. Hisso says:

    @Joe, it doesn’t matter if you “buy it” or not. Todd’s description is technically accurate and it *does* make it hard for browsers to meaningfully know if they’ve connected to the “correct” host.

    I might also add that the local resolver may be configured to have search paths. When the resolver responds with an IP address the caller *does not know* if the resolver found that partial hostname by looking at the domain name or any of the additional domains listed in the search path.

    In addition, the resolver library on *all operating systems* will search “down the domain” if it can’t resolve an address. So if I type in “exchange” and my domain is “” the resolver may search:


    The caller will not know which of these addresses was actually matched.

    I guess a browser *could* do a “reverse lookup” on the IP address to try and get a fully qualified domain name — but it’s not guaranteed to work and will probably still result in a name mismatch.

    No, the article is correct. The problem is not the browser. The problem is the certificate authorities doing the wrong thing.

  9. Zan says:

    The easy answer to that “flaw” is to set up a dumb-simple web server on http://exchange to forward people to (you may need to put your exchange webmail server on a non-standard port if your users are using an https anywhere plugin).

Leave a Reply