New SSL Server Rules Go Into Effect Nov. 1

← Back to Stories (view on slashdot.org)

New SSL Server Rules Go Into Effect Nov. 1

Posted by Soulskill on Friday July 25, 2014 @06:01AM from the encrypt-your-calendars dept.

alphadogg writes: Public certificate authorities (CAs) are warning that as of Nov. 1 they will reject requests for internal SSL server certificates that don't conform to new internal domain naming and IP address conventions designed to safeguard networks. The concern is that SSL server digital certificates issued by CAs at present for internal corporate e-mail servers, Web servers and databases are not unique and can potentially be used in man-in-the-middle attacks involving the setup of rogue servers inside the targeted network, say representatives for the Certification Authority/Browser Forum (CA/B Forum), the industry group that sets security and operational guidelines for digital certificates. Members include the overwhelming bulk of public CAs around the globe, plus browser makers such as Microsoft and Apple. The problem today is that network managers often give their servers names like 'Server1' and allocate internal IP addresses so that SSL certificates issued for them through the public CAs are not necessarily globally unique, notes Trend Micro's Chris Bailey.

92 comments

Min score:

Reason:

Sort:

Why? by Ark42 · 2014-07-25 06:15 · Score: 5, Insightful

Why are people using public CAs and purchased certificates for private networks?
Wouldn't it make more sense to set up your own internal CA, or at least just force via policy certain certificates onto each computer's browser as trusted?

--
Morphing Software
1. Re:Why? by Anonymous Coward · 2014-07-25 06:28 · Score: 5, Funny
  
  Also, why were the CAs *ever* granting these certs? And is it too late to get one for "localhost"?
2. Re: Why? by tysonedwards · 2014-07-25 06:29 · Score: 4, Insightful
  
  If all of those devices were centrally managed, sure. Let's say that instead you are a college, with dorms, and an internal network that those in the dorms can use with direct access to things like Mail and whatever, or a BYOD scenario where users are allowed to use their cell phones to get email and even be on wifi, but you want to respect your employees privacy on their private purchased devices rather than adding them to an MDM.
  
  Do you really want to bug those user's repeatedly with self signed cert validation prompts or just say "okay, $30 / year is worth avoiding the helpdesks"?
  
  In most cases, yes, a CA and group policies makes the most sense though and should be the answer. There are just a few fringe cases where it is easier to pay the few bucks than waste the time explaining why the user is in fact safe and just press okay.
  
  --
  Thirty four characters live here.
3. Re:Why? by gregsmac · 2014-07-25 06:29 · Score: 2
  
  I think it is because for 300 bucks a year, you can have a CA issue a cert without having to manage a cert server in your own environment. Not to mention hardware cost, server license cost, maintenance cost...etc.
4. Re:Why? by LiENUS · 2014-07-25 06:34 · Score: 1
  
  Not to mention hardware cost, server license cost, maintenance cost...etc.
  I dont think a cert server works the way you think it does.
  I mean technically it has costs... but theres not a lot of reason you can't use a $300 convertible tablet pc handle your ca cert virtually indefinitely, it doesn't have to be turned on after you finish signing certs until its time to sign another batch...
5. Re:Why? by Anonymous Coward · 2014-07-25 06:35 · Score: 0
  
  It's not even a browser issue. You install the necessary root certificate once (a simple procedure on most operating systems) and all browsers (etc) will find it.
6. Re:Why? by gregsmac · 2014-07-25 06:38 · Score: 1
  
  That's crazy talk. maybe in a small shop a tablet PC could be entrusted to such an important role. In the larger environments I don't think that would fly. Risk team would never allow it.
7. Re: Why? by QuietLagoon · 2014-07-25 06:47 · Score: 4, Informative
  
  ...Do you really want to bug those user's repeatedly with self signed cert validation prompts or just say "okay, $30 / year is worth avoiding the helpdesks"? ...
  They are bugged only once, and then they accept the cert locally. Or the college provides an easy way for the BYOD people to acquire the college's cert.
  There is no need for an official CA to issue a cert for Server1 at IP address 10.2.1.2. No need whatsoever. And, as proof of that, starting in November, the official CAs will stop issuing those types of certs.
8. Re:Why? by unrtst · 2014-07-25 06:48 · Score: 1
  
  That's crazy talk. maybe in a small shop a tablet PC could be entrusted to such an important role. In the larger environments I don't think that would fly. Risk team would never allow it.
  ... is that the same risk team that would authorize the purchase of a public cert for "Server1"?
  I think the original point was that it takes almost nothing to sign certs. There need not be any significant investment.
9. Re: Why? by Anonymous Coward · 2014-07-25 06:53 · Score: 1
  
  Are you connecting to that self signed cert that is university owned or that self-signed cert that is setup by my evil laptop on the wifi network?
  For trust to occur you need authentication as well as authorization. The external CA authentications your connection, which enables you to safely authorize yourself with the remote party.
  Security 101, don't use self-signed certificates if you cannot control the CA (eg an internal network where you import your internal CA into all of your devices). With BYOD you simply cannot use a self-signed certificates. Your potential attack surface than increases.
10. Re:Why? by MightyMartian · 2014-07-25 06:57 · Score: 2
  
  I have to confess, I'm pretty mystified. For our own internal servers, I have my own CA, and can see no reason why I would want to have someone else sign internal certs.
  Sounds like yet another way in which the commercial CAs scam stupid CIOs out of cash.
  
  --
  The world's burning. Moped Jesus spotted on I50. Details at 11.
11. Re: Why? by blueg3 · 2014-07-25 07:02 · Score: 2
  
  They are bugged only once, and then they accept the cert locally.
  Not necessarily. On Chrome, for example, accepting a self-signed cert long-term isn't the default behavior. Even that isn't a great idea: you have no knowledge of whether the self-signed cert is legitimate or not without a substantial out-of-band communication of technical information to nontechnical people, which isn't cheap. A college network is a good example: it should be treated as a hostile network, so MitM against a self-signed cert within your private network is very much a reality.
  
  Or the college provides an easy way for the BYOD people to acquire the college's cert.
  Doing that at a large scale for technically-inclined people costs more than a public CA cert. Once you have to support regular users, it's way more expensive.
  
  There is no need for an official CA to issue a cert for Server1 at IP address 10.2.1.2
  Certs don't include IP address. When you get a cert for server1.internal.unm.edu, they don't know what IP address(es) it will be bound to, and they don't and shouldn't care.
  
  No need whatsoever.
  There certainly is a need. It's to enable devices that want SSL but aren't configured to trust your internal CA to securely identify your server. There are lots of reasons for "aren't configured to trust your internal CA" to happen.
  
  And, as proof of that, starting in November, the official CAs will stop issuing those types of certs.
  They're going to require that certs they issue are for domains that are tied to an external domain. For example, mail.internal.unm,edu. This doesn't negatively impact people's ability to have public CA certs for internal resources. Nor should it.
12. Re: Why? by Cley+Faye · 2014-07-25 07:07 · Score: 1
  
  Are you connecting to that self signed cert that is university owned or that self-signed cert that is setup by my evil laptop on the wifi network?
  [...]
  With BYOD you simply cannot use a self-signed certificates. Your potential attack surface than increases.
  That's why the previous poster said "Or the college provides an easy way for the BYOD people to acquire the college's cert."
  You don't have to trust any self-signed certificate that the web server throws at you. You go to the official, public website of your uni/work/whatever (or to the IT dept. if they want to do this by hand), and grab the CA cert there. You trust this website, it can have a regular certificate issued by any public authority, and using this newly downloaded cert. as a CA, you can safely connect to anything your workplace have in it's private network.
  The only hindrance is that the users have to install this certificate once. Through easy GUI.
13. Re: Why? by Albanach · 2014-07-25 07:07 · Score: 2
  
  The parent is spot on. If you need to self-sign, then you need the client to trust your signing authority, not simply to trust your self-signed certificates.
  Asking them to trust your certificates means teaching them to ignore and click through an important security warning. It not only poses a danger to your users in their internet use elsewhere, but also to your own servers as someone can set up a MITM attack and you have already trained your users to ignore the warning presented by the browser.
  Widely trusted SSL certificates can be had for under $10. Wildcard certificates for under $100. There is no reason to have a self-signed certificate on anything public or employee facing.
14. Re:Why? by Cley+Faye · 2014-07-25 07:11 · Score: 1
  
  it doesn't have to be turned on after you finish signing certs until its time to sign another batch...
  To be fair, with OCSP you need something that's online all the time your certificates are used. But unless you have hundreds of peoples checking your certificates simultaneously, any low-end contraption can handle it.
15. Re:Why? by afidel · 2014-07-25 07:25 · Score: 1
  
  So you use a VM, marginal cost is near zero for a 4GB VM in todays world.
  
  --
  There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
16. Re: Why? by unrtst · 2014-07-25 07:34 · Score: 2
  
  I have trouble seeing any of the justifications for getting a public CA cert for a name like "Server1" with an internal IP.
  You could use your own internal CA, as others have noted. There is overhead to doing so and, being lazy, just buying the public cert may have seemed like an option.
  However, one could simply use a real DNS entry, and all would be fine. Ex. server1.int.my-domain.com. Setup the "int.my-domain.com" on dns servers that all your internal hosts can see (they're all internal, so that can't be TOO difficult, and it doesn't hurt if that's visible from external). It's really quite easy to setup DNS, and it's cheaper, and it'll work with the CA just fine, and will work if/when you move the service to a public IP, or if you adopt an internal CA, etc etc etc. Why NOT do this? You can even host your DNS for free somewhere online.
17. Re: Why? by jythie · 2014-07-25 08:00 · Score: 1
  
  There are also a few edge cases (in windows) where accepting a self signed certificate requires fiddling with the registry. Microsoft designed a few of its services with the idea that everyone would have a CA signed certificate.
18. Re: Why? by Anonymous Coward · 2014-07-25 08:02 · Score: 0
  
  Do you really want to bug those user's repeatedly with self signed cert validation prompts or just say "okay, $30 / year is worth avoiding the helpdesks"?
  Or, you could just do something intelligent, like issue the certificate for a real fqdn.
  Instead of having a certificate for "server1", it should be for "server1.building.company.com".
  Moreover, how is a CA issuing a certificate for "server1"? That goes against the rules - the CA is supposed to verify that they are issuing the certificate to the legitimate owner.
  There are different levels of verification, but even the cheapo certificates will do DNS/whois lookup to make sure they are issuing a certificate to someone who appears to own the domain.
  No one is the owner of "server1", and CAs should never have issued certificates for that.
19. Re:Why? by El_Muerte_TDS · 2014-07-25 08:12 · Score: 4, Insightful
  
  Because of money.
20. Re:Why? by cps42 · 2014-07-25 08:24 · Score: 1
  
  Without addressing the correctness of the process, the Microsoft Exchange documentation suggests a SAN certificate for the Exchange servers that includes the public names and internal names on the same certificate. Lync does the same thing.
  While this reduces services and split-naming confusion, it also puts your internal naming convention in the public certificate. People do it because MSFT says so. This Exch2007 article (Yes, old, but the first link in google. There are more examples.) says to put the NetBios name in as well: http://blogs.technet.com/b/exc...
21. Re: Why? by Anonymous Coward · 2014-07-25 08:55 · Score: 0
  
  ... or just use a real domain.
22. Re: Why? by corychristison · 2014-07-25 09:10 · Score: 1
  
  Agree with this completely.
  Even if the application is only accessible within the private network, there is nothing stopping them from using their external DNS (eg. someapp.bigcorp.tld) and point it at an internal IP, then properly set up an SSL Certificate. But if it is only accessible within the private network, do you really need it wrapped up in SSL at all?
  Using poorly configured hostnames only accessible within the network is plain stupid. At the /very least/ set it up on a domain within the network, so it has a suffix identifiable to your network.
  Self signed certs are ONLY useful for development environments across networks.
  CA signed certs are cheap, typically around $10 for one without the bells and whistles. I personally set up a wildcard certificate for one of my own projects a few months ago. I paid about $75.
23. Re: Why? by Z00L00K · 2014-07-25 09:24 · Score: 3, Informative
  
  Assuming the CA can be trusted.
  I'm not trusting the CAs that exist to not reveal key data to NSA or other organization.
  
  --
  If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
24. Re: Why? by I_Wrote_This · 2014-07-25 11:27 · Score: 1
  
  There is no need for an official CA to issue a cert for Server1 at IP address 10.2.1.2.
  But certificates are given for names , not addresses, and you don't specify any address in the request.
25. Re: Why? by I_Wrote_This · 2014-07-25 11:31 · Score: 1
  
  Do you really want to bug those user's repeatedly with self signed cert validation prompts...
  No - you set up a Web base CA that let's them request certificates (and that CA ensures that they are only valid for local-network names), and publish the root certificates on that site, with instructions for how the users can load them into their systems/browsers.
  Then they don't get prompted for locally-issued certificates.
26. Re: Why? by Anonymous Coward · 2014-07-25 11:50 · Score: 0
  
  At this point, a self-signed cert may be *more* trustworthy than a CA-granted cert.
27. Re: Why? by fishbowl · 2014-07-25 12:32 · Score: 1
  
  Many situations require the encryption of SSL without necessarily requiring the authentication of SSL. This is the case when the risk is more from something like accidentally or casually disclosing sensitive information and there is little or no risk of intentional attack, but where there are liabilities for routine exposure. This scenario isn't really a job for SSL, but what else do we have to work with?
  
  --
  -fb Everything not expressly forbidden is now mandatory.
28. Re: Why? by cr0nj0b · 2014-07-25 13:32 · Score: 1
  
  Exchange is a big reason for getting a certificate that contains internal domains.
  You get a single UCC Certificate that contains mail.domain.com and mail.company.local
  first result from google for UCC cert
  http://support.godaddy.com/hel...
29. Re:Why? by cr0nj0b · 2014-07-25 13:35 · Score: 1
  
  mod parent up. this is an important point for Microsoft shops.
  changing your internal Active directory structure from company.local to ad.company.com is a major pain and error prone.
30. Re:Why? by mysidia · 2014-07-25 14:27 · Score: 1
  
  or at least just force via policy certain certificates onto each computer's browser as trusted?
  That works fine for Internet Explorer on Windows via group policy.
  It doesn't work for Firefox or Java (separate private trusted certificate storage databases).
  More importantly: It doesn't work for iPhones, Androids, or macs accessing intranet resourses, or that require a valid certificate to setup Activesync connection.
31. Re: Why? by Anonymous Coward · 2014-07-25 14:29 · Score: 0
  
  Split DNS kids, that's what we do. Internal mail server: mail.contoso.com external: mail contoso.com. DNS handles the internal namespace. Done. As an architect, I can vouch that this is best practice. OK trolls: go. I won't be listening.
32. Re: Why? by jrumney · 2014-07-25 15:07 · Score: 1
  
  The CA doesn't get key data.
33. Re: Why? by arglebargle_xiv · 2014-07-25 16:56 · Score: 1
  
  And, as proof of that, starting in November, the official CAs will stop issuing those types of certs.
  Not quite. As of November, the official CAs will claim that they've stopped issuing those types of certs. When something like the SSL Observatory points out that they're still issuing them, they'll say that this (and the other 8,192 times they did it) was a one-off mistake and they've updated their policies to make sure it never happens again. Then when they get caught again they'll say that it was test certificates that accidentally escaped. After that, they'll stop responding to reports. And we'll all be much, much safer, and phishing will be eradicated once and for all.
34. Re: Why? by Z00L00K · 2014-07-25 17:50 · Score: 1
  
  They get enough to be able to provide a man in the middle attack.
  
  --
  If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
35. Re:Why? by ruir · 2014-07-25 20:31 · Score: 1
  
  Because the whole certificate chain of trust business is a sham, so let be stupid and waste money on your private network too.
36. Re: Why? by ruir · 2014-07-25 20:34 · Score: 1
  
  In a university, *for* internal sites, they can distribute the root certificate to desktop via AD logins for instance, or putting it on a site. Profiles are also a way. They can be distributed in profiles say for wifi use, and it is debatable whether using a private CA for wifi authentication is actually more secure.
37. Re: Why? by ruir · 2014-07-25 20:35 · Score: 1
  
  And to break far more easily the encrypted traffic.
38. Re: Why? by jrumney · 2014-07-25 21:24 · Score: 1
  
  Please expand. Are you saying that the CA signed certificate can contain two public keys, and that browsers will encrypt the session key such that either key's corresponding private key can be used to decrypt it?
39. Re: Why? by Z00L00K · 2014-07-25 22:07 · Score: 1
  
  No, but the CA can provide a certificate suitable for a man in the middle attack that is masking itself as the real server if the CA is compromised.
  That's the weakness with the existing system of public certificate authorities. There are three points that can be compromised instead of two as soon as you have a public CA signing the certificates.
  
  --
  If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
40. Re:Why? by IamTheRealMike · 2014-07-26 00:55 · Score: 1
  
  To be slightly more accurate and less cynical, because their customers asked for one, and because there were no particular rules or guidelines laying out what to do with such requests thus no reason to refuse. Sure, any given CA could refuse on principle, in which case that customer would go to a competitor. That's why the CA system is regulated by browser/OS makers - to keep standards high in the presence of competitive market forces that would otherwise optimise for convenience.
41. Re: Why? by Anonymous Coward · 2014-07-26 07:41 · Score: 0
  
  They are bugged only once, and then they accept the cert locally. Or the college provides an easy way for the BYOD people to acquire the college's cert.
  
  I wish it were this easy. Three major problems (off the top of my head):
  1) Not all devices all you to import root certificates. Telling the end user to call the wireless carrier and/or device vendor to troubleshoot just doesn't work.
  2) You are assuming people are intelligent and can figure out how to accept the self-signed certificate. You assume wrong and this WILL flood the helpdesk + drive up costs.
  3) Man-in-the-middle attacks on campuses. Trivial to setup a rogue AP in the middle of a food court. "Hi, we just reissued a cert, please accept it".
  
  Paying for a additional certs from well-known / trusted CAs is much cheaper than dealing with any of the above.
42. Re: Why? by jrumney · 2014-07-27 02:21 · Score: 1
  
  And if the CA was not in the loop, the CIA could create such a certificate themselves, and it would be just as valid as the certificate created by the real owner to the outside observer. So how is adding the CA increasing the vulnerability again?
43. Re:Why? by Anonymous Coward · 2014-07-27 07:28 · Score: 0
  
  At least one customer of mine uses *.initech.com in their certificate. Utterly insane.
44. Re: Why? by tlhIngan · 2014-07-28 03:34 · Score: 1
  
  They get enough to be able to provide a man in the middle attack.
  If you can do that with a CA, I say you have far more interesting technology than signing a cert.
  A certificate is basically a signed public key. You give the CA the public key, they sign it, which says "I, the CA, certify that this public key belongs toe XYZ Inc".
  That's it. You don't sign private keys (they remain on your server, after all), and your server hands out the certificate during initial security setup. The client looks at the certificate and extracts the public key it'll use to talk to the server.
  No, the way you MITM with a CA is you have to be in the middle, and with a forged cert. Basically you intercept the client's request, hand out your certificate of your public key. The client transmits data to you using that public key, which you decrypt using your private key, log the data, then re-encrypt using the real server's certificate (i.e., public key).
  No, a CA does not need your private key. Unless you ask it generate a keypair for you. If a CA could spy on other traffic, you'd think they'd all be doing it. No, a "compromised" CA really means they have no qualms about issuing a duplicate certificate - e.g., a certificate for *.google.com even though they aren't Google's CA.
45. Re: Why? by Z00L00K · 2014-07-28 03:51 · Score: 1
  
  That would only work if one of the end points are compromised, so by leaving out a third party CA you decrease the sensitive points from three to two. It of course requires the end point owners to have a correct key handling and key exchange, but that is no different from having a CA.
  The only time a CA is useful is if the two communicating parts don't know each other, but in the matter of a bank the person is already a customer and therefore a key exchange can be done at a bank office.
  
  --
  If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Why use public CA an internal server? by Sloppy · 2014-07-25 06:18 · Score: 4, Insightful

Who are these people, that would give a damn about this change?
You don't need an intermediary not-you authority for this job. And in fact, using one can only possibly decrease the security, in the best case scenario. Even the worst most incompetent company in the world, would make a better CA for its internal servers, than the best, most trustworthy public CA.

--
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
1. Re:Why use public CA an internal server? by Anonymous Coward · 2014-07-25 06:32 · Score: 1
  
  Cheaper and easier to convince the PHB to buy a certificate signed by a public CA, than install your own CA certificate on every browser in your company.
2. Re:Why use public CA an internal server? by Anonymous Coward · 2014-07-25 06:38 · Score: 0
  
  But then you'd have to not be completely incompetent and somehow (perhaps through magic? Is magic how it works? And unicorns?) get your internal CA goodness onto employee systems.
  And people who aren't completely incompetent are rarer than you might think.
3. Re:Why use public CA an internal server? by Anonymous Coward · 2014-07-25 06:49 · Score: 2, Informative
  
  Not at all true on several fronts:
  1) Getting security right is actually more difficult than most people imagine. Joe Blow random IT guy *thinks* they know how to do it - and in most cases they are wrong. It may be "hip" to dis public CAs, but you've not seen security failures until you have a random IT person trying to setup something like this as an internal side project.
  2) You are completely disregarding the level of effort and implicit security risks involved in trying to publish a 'private CA' record across an enterprise so that every client on every system will recognize your private CA as being a trust point. In terms of the risks, think about all the ways that such a publishing scheme could allow one to introduce rogue CA certs across your enterprise. Also think about the human aspect - there will be a non-trivial number of people who won't get the private CA cert for some reason and they will then get errors about 'cert XYZ is not trusted, blah blah blah'. Those people will become used to seeing that sort of error and get used to ignoring it, at which point the moment that they hit a cert that is *actually* invalid they will click right past it.
  So in short, trying to setup an internal CA and deal with the publishing aspect of the internal CA within an organization is time consuming and introduces a whole new level of security concerns.
  And by the way, this is not me talking into my hat. I design enterprise software that must be deployed at a multitude of companys and the mistakes and flaws and holes that we find in those internal networks setup by joe-blow average IT guy is astounding.
4. Re:Why use public CA an internal server? by Anonymous Coward · 2014-07-25 08:11 · Score: 0
  
  You are completely disregarding the level of effort and implicit security risks involved in trying to publish a 'private CA' record across an enterprise so that every client on every system will recognize your private CA as being a trust point.
  It's pretty easy with active directory. You can push out additional certificates with firefox. And most management platforms for mobile devices let you push out certificates.
  And for systems that are really public and accessed from uncontrolled devices (such as outlook web access), then yes, it should be a regular certificate from a regular certificate authority.
  But certificate authorities should never be issuing certificates without verifying that they are issuing certificates to the real owner.
  Some CAs are more diligent at this sort of thing, but they should never issue certificates for "server1" since there is no way for anyone to prove they own "server1". That name does not belong to anyone.
5. Re:Why use public CA an internal server? by Tailhook · 2014-07-25 09:52 · Score: 1
  
  It's pretty easy with active directory
  Is that the Win2K3 server that's been manhandled by six former employees/contractors and hosts signing keys protected by passwords that have never changed?
  Just using the word `easy' in IT is a huge red flag. If you're PKI infrastructure is `easy' to use in any sense then you're doing it wrong.
  
  --
  Maw! Fire up the karma burner!
6. Re:Why use public CA an internal server? by Anonymous Coward · 2014-07-26 02:37 · Score: 0
  
  It's pretty easy with active directory
  Is that the Win2K3 server that's been manhandled by six former employees/contractors and hosts signing keys protected by passwords that have never changed?
  Yes, if you have poor documentation & procedures and incompetent people fiddling with your certificate authority that can cause problems. But the same can be said for any other important system: active directory, mail servers, databases, routers, WANs, etc.
  
  Just using the word `easy' in IT is a huge red flag. If you're PKI infrastructure is `easy' to use in any sense then you're doing it wrong.
  Seriously? The best practice is to generate your main CA, then create a delegation to a subordinate CA. Take your main CA offline to reduce the risk of compromise, and issue user & device certificates from the subordinate CA. It's a bit of work to set up correctly, but not that difficult. Establish some standards & policy on the issuing/revoking of certificates, what SANs are allowed (or mandatory), and put trustworthy people in charge.
  Yes, this means that your CA could issue fake certificates for hotmail, which is why you need tracking, auditing and trustworthy people (and users should check SSL certificates in their browser, but that's a different story).
  But automatically distributing your main CA to devices IS easy. It's just a few clicks in active directory group policy. You can roll out a cert8.db file with firefox. Mobile management platforms like Airwatch and others make it easy.
  And I stand by my earlier point, certificate authorities should never be issuing certificates without verifying that they are issuing certificates to the real owner.
  Some commercial CAs are more diligent at this sort of thing, but they should never issue certificates for "server1" since there is no way for anyone to prove they own "server1". That name does not belong to anyone.
  A commercial CA could issue a certificate for server1.building.school.edu, provided that I prove I own school.edu, even if this server is firewalled off and not publicly accessible from the internet.
7. Re:Why use public CA an internal server? by Anonymous Coward · 2014-07-27 05:12 · Score: 0
  
  Yeah, because an internal CA which is set up by someone who doesn't know much about security couldn't possibly have its signing key compromised, making for a super effective spear phishing campaign or facilitating even easier MITM attacks. </sarcasm>
finally by Anonymous Coward · 2014-07-25 06:26 · Score: 1

So the people responsible for enforcing the administrative details of enforcing the spec are finally realizing they have some work to do?
Re:Why aren't they already unique? by Anonymous Coward · 2014-07-25 06:39 · Score: 0

RTFS FFS.

The problem today is that network managers often give their servers names like 'Server1' and allocate internal IP addresses so that SSL certificates issued for them through the public CAs are not necessarily globally unique
Big Problems by TMYates · 2014-07-25 06:48 · Score: 1

This may cause big problems for many of the existing systems out there. How do they determine internal names? Does it require a .com? Will it take into account any new top level domains that opened up? What about certificates for various systems that do not require domain names for communication (I.E. ADFS Signing/Encryption Certificates).

I think it should be required to not mix internal and external names in certificates, but to ban them completely is going to break many things. I know by default Exchange 2010/2013 and Lync Server require internal names in the certificate. You can split the bound IPs and use 2 different certificates, but it makes things more difficult to configure and manage. No to mention that Exchange patches really hate multiple virtual directory entries...
1. Re:Big Problems by Anonymous Coward · 2014-07-25 07:34 · Score: 0
  
  Yeah, and?
  You knew that you were entering the 9th hell when you got tangled with Exchange. Own up and either deploy an internal CA, or do whatever penace Exchange requires to get it to behave properly.
  Although this entire thing is mostly useless security theater, the real problem is the unrestricted CA model.
2. Re:Big Problems by swb · 2014-07-25 07:41 · Score: 1
  
  You can change the names used by Exchange so that you completely avoid any ".local" addresses. About the only kludge (which is usually already in place) is a being able to resolve public domains to internal addresses.
3. Re:Big Problems by Anonymous Coward · 2014-07-25 11:40 · Score: 0
  
  Never had any problems with Exchange 2010/2013 using public certs with FQDNs. Granted we also have an internal PKI that we could have used and a good understanding of how it all works together. Proper planning and all that...
4. Re:Big Problems by TMYates · 2014-07-30 04:35 · Score: 1
  
  I generally haven't as well, but depending on your environment, automatically generated certificate requests may attempt to contain an internal domain. Hence why the default setup would no longer work once this rule takes effect. For instance, an environment that uses a domain.local that you cannot change because you have Exchange (Thanks Microsoft!). It is completely possible to have an internal interface and external and split the roles and certificates (this is what I do). Our internal interface has an internal CA cert and the external a public cert. The problem comes where all the service packs and cumulative updates I have applied required me to remove one of the virtual directories for things like OWA and ECP or the update would fail. The funny part is, they allow PowerShell to create those multiple directories, but the PowerShell scripts they put in the update expect only one directory. Fortunately its easy to export the config of one of the directories and recreate it later.
Time to get rid of CAs altogether by Anonymous Coward · 2014-07-25 07:46 · Score: 0

Isn't it time to get rid of CAs and come up with a better way for domain validation?
1. Re:Time to get rid of CAs altogether by Anonymous Coward · 2014-07-25 09:06 · Score: 0
  
  Isn't it time to get rid of oil and come up with a better energy source?
  You are fighting a whole industry, you know that?
So, split DNS then? by bill_mcgonigle · 2014-07-25 07:46 · Score: 1

What a junk article - no explanation of what's actually going on and no link to a standard.
It sounds like what they're inferring is that you need server.example.com, not server.local or server.somemadeupcrap.
I think most of us cleaned up that cruft when BIND 9 came out with views support.
This shouldn't impact anybody who hasn't been dragging their heels on fixing their infrastructure for more than a decade.

--
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
1. Re:So, split DNS then? by Anonymous Coward · 2014-07-25 08:07 · Score: 0
  
  This shouldn't impact anybody who hasn't been dragging their heels on fixing their infrastructure for more than a decade.
  Shouldn't but yet still does.
  Microsoft up until just six months ago still auto-generated a blah.local self-signed certificate for new Exchange installs, after which the certificate signing commandlets make it painfully easy to generate a CSR for that .local yet also painfully difficult to replace the cert entirely.
  Outlook 2007 (and I believe 2010 but not sure) will latch on to the first cert they get from Exchange and almost never let go. If the server name changes, it just refuses to connect. Pushing out an additional public cert via group policy won't fix it either, and even Microsoft states the only solution is to visit each desktop to uninstall Outlook, uninstall the old cert, and reinstall Outlook so it fetches the latest correct cert from Exchange.
  iPhone and Android Exchange support has similar problems, with the addition of requiring a GoDaddy signed certificate, thus ruling out self-signed or even internal CA signed certificates for MAPI or OWA access to mobiles.
  iPhone will allow you to install a root CA cert from your internal CA but only through the enterprise iPhone Configuration Utility.
  Android non-rooted simply refuses that setup. Honestly I can't say if rooted would even help, I just assume it might.
  Oh, wild-card certs don't work with Exchange either, so no paying 10x the cost to avoid the problem!
  Of course us Exchange admins bitch about having to use the thing as much as the Linux folk bitch at us (real fun for those like me who are in both camps), but sadly there really isn't an open source solution matching all that Exchange/Outlook provides.
  Thank deity my email edge transport encryption is done by sendmail sitting between Exchange and the Internet!
  Additionally Oracle SAP (bless the poor souls forced to use it) has a nasty habit of forcing browser redirection from the DNS name/alias typed into the browser over to the short name of the machine.
  This means not only does the certificates common name Need to be the short name, it has to be a v3-req cert with multiple names in it to handle both short and fqdn versions so the redirection won't throw up extra errors - something public CAs charge a damn lot extra for - and using the fqdn still won't work in the end.
  Really fun for merged companies where my search domain is auto-appended to short names, and using the head companies fqdn is what triggers split-dns lookup to go over the VPN and fetch internal IPs.
  This means to use the VPN and contact the server directly via RFC1918 addresses you Must put the fqdn. But SAP redirects all such requests to the short name, causing our PCs to append our own search domain and thus failing to look up the IP (one hopes! A matching short name would cause all sorts of fun additional confusion!)
  The only answer I've found is have two search domains pushed via DHCP with a priority - and leak all typoed and leaky DNS lookups up to corporate to log :/
2. Re:So, split DNS then? by Anonymous Coward · 2014-07-25 13:21 · Score: 0
  
  Microsoft up until just six months ago still auto-generated a blah.local self-signed certificate for new Exchange installs, after which the certificate signing commandlets make it painfully easy to generate a CSR for that .local yet also painfully difficult to replace the cert entirely.
  I didn't find it all that difficult to generate a CSR for a FQDN or to replace the .local cert the last time I setup an exchange server. Granted I can actually read documentation.
  
  Outlook 2007 (and I believe 2010 but not sure) will latch on to the first cert they get from Exchange and almost never let go. If the server name changes, it just refuses to connect. Pushing out an additional public cert via group policy won't fix it either, and even Microsoft states the only solution is to visit each desktop to uninstall Outlook, uninstall the old cert, and reinstall Outlook so it fetches the latest correct cert from Exchange.
  This is just not true, Outlook using RPC doesn't care about the SSL certificate of the server and using RPC-over-HTTPs you can just change the name in the setting. Auto-configure could even do this for you in 2010 if you set it up properly.
  
  iPhone and Android Exchange support has similar problems, with the addition of requiring a GoDaddy signed certificate, thus ruling out self-signed or even internal CA signed certificates for MAPI or OWA access to mobiles.
  Nothing special about GoDaddy's certs and android at least had an option to allow any certificate (insecure). In addition neither of those clients used MAPI or OWA (they both licensed ActiveSync from MS).
  
  iPhone will allow you to install a root CA cert from your internal CA but only through the enterprise iPhone Configuration Utility.
  Android non-rooted simply refuses that setup. Honestly I can't say if rooted would even help, I just assume it might.
  Android has had the ability to install 3rd party CAs since at least 2.2, you just drop the cert bundle on the SD card and import. Required a pin or pattern on the lock screen to use in some versions and a passphrase on the store in others. Some of the carrier provided email apps on Android were just front-ends to the carrier provided webmail interface and were terrible. Stock Android email client works OK and there were always plenty of alternatives in the market
3. Re:So, split DNS then? by ruir · 2014-07-25 20:38 · Score: 1
  
  Yep, split DNS fixes a lot of headaches, and "optimizes" a lot of internal traffic. No need for the traffic to go to firewall to talk to a NAT IP and come back to the internal network.
Keep a master list by Gothmolly · 2014-07-25 07:58 · Score: 1

Of hosts, we could even call the file 'hosts'. Then, periodically, you pull a copy from the master to have locally. Simply set up a governing body to arbitrate name clashes (like 'mailserver') and you're good to go!

--
I want to delete my account but Slashdot doesn't allow it.
1. Re:Keep a master list by Zero__Kelvin · 2014-07-25 08:11 · Score: 1
  
  So we finally know APKs real SlashID!
  
  --
  Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Where are the new rules? by Anonymous Coward · 2014-07-25 08:16 · Score: 0

Neither this, or the linked article actually tell us what the new rules are. What is the new naming convention that has to be followed?
Documentation by dskoll · 2014-07-25 08:40 · Score: 2

I'm curious as to what documentation the CA's required for you to prove that you own localdomain or 192.168.2.22.
1. Re:Documentation by blueg3 · 2014-07-25 08:57 · Score: 1
  
  None. Now you've identified and understand the problem.
Re:Why aren't they already unique? by Z00L00K · 2014-07-25 09:16 · Score: 3, Informative

For internal servers the companies often set up their own CA server and distribute the root cert to the clients, so only a few companies will be affected.

--
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Compartmentalization by tepples · 2014-07-25 10:28 · Score: 1

But if it is only accessible within the private network, do you really need it wrapped up in SSL at all?
Yes, for reasons of privacy from people in other departments who don't deserve access to particular pieces of information. For example, a hospital regulated under HIPAA wouldn't want a surgeon snooPING AS usual on the health information of patients who aren't hers.
Group Policy by tepples · 2014-07-25 10:35 · Score: 1

Cheaper and easier to convince the PHB to buy a certificate signed by a public CA, than install your own CA certificate on every browser in your company.
Then your organization's IT department needs to learn about Group Policy and its counterparts on other common personal computing platforms.
1. Re:Group Policy by dkf · 2014-07-25 23:40 · Score: 1
  
  Cheaper and easier to convince the PHB to buy a certificate signed by a public CA, than install your own CA certificate on every browser in your company.
  Then your organization's IT department needs to learn about Group Policy and its counterparts on other common personal computing platforms.
  Yeah, but getting all that to work when dealing with the reality of BYOD in many organisations (universities have a particular problem with this) is massively more complicated and expensive than ponying up for an externally-signed certificate. Heck, even getting an externally-signed local CA certificate is cheaper. Group policy (and equivalent) works relatively well for desktops and other wholly-owned devices, but ceases to be nearly so useful once you have to deal with anything external, and that's more and more common.
  Get with the programme.
  
  --
  "Little does he know, but there is no 'I' in 'Idiot'!"
One thing neither APK nor APK can do by tepples · 2014-07-25 10:38 · Score: 1

But how would you install a hosts file on Android? You can't do that with just an APK. The file is normally in a read-only system partition, and I imagine that most people who bring their own device aren't willing to wipe the device to install a rooted ROM.
Four letters: FQDN by tepples · 2014-07-25 10:40 · Score: 2

What is the new naming convention that has to be followed?
More than likely, a fully qualified domain name.
So what by Anonymous Coward · 2014-07-25 12:09 · Score: 0

These are the same SSL certificate warnings that have been counted as 100% false positives?
subdomain trust by Anonymous Coward · 2014-07-25 12:23 · Score: 0

I dont get why they dont at least have an option to enforce that the trust chain mirrors the dotted subject. So for instance comm ca's would sign you top level cert and then you could sign various subdomain certs for various sub orgs with the limitation that they could not sign certs that werent more specific. Or is this an option? Sort of like how dnssec (i think) works.
1. Re:subdomain trust by mysidia · 2014-07-25 14:41 · Score: 1
  
  Or is this an option?
  RFC 3280 #4.2.1.11
  
  The name constraints extension, which MUST be used only in a CA certificate, indicates a name space within which all subject names in subsequent certificates in a certification path MUST be located. Restrictions apply to the subject distinguished name and apply to subject alternative names.
  
  ...
  
  >
  It is an option that was not forced on the root CAs. Essentially none of the public CAs are signing from intermediary CAs with name restrictions applied to their certificates.
  Generally the restriction mechanism is only allowed to do something kind of "creepy"; where the root CA essentially "sells" this service to a smaller company for perhaps $50,000 or so and issues a restricted certificate --- that allows whoever bought this service to sign subcerts within certain constraints.
2. Re:subdomain trust by Anonymous Coward · 2014-07-25 19:29 · Score: 0
  
  I like this way better, esp for the root ca's; why wasn't this the default? Wouldn't this stop the compromise of, say, a Turkish CA from reaping a trusted www.google.com cert (in the absence of pinning or notaries)? Or hell, then it'd be not so bad to just trust individual organizations (rejecting the top level root signers) without worrying that one of _their_ certs was created wrong and used to sign god knows what other domains. I could decide at what level of granularity I could trust a given organization, and zoom in and out as required, only trusting the parts I'd want to (don't trust .gov, but .nasa.gov is OK). Certs almost seem sane with this option on by defaut (of course I'm probably missing something that nullifies the perceived security gains).
  Whoever decided to reverse hostnames (www.foo.com instead of com.foo.www) and stop people from thinking about this stuff as a tree really screwed things up.
Re:Why?- SAN cert by JS_RIDDLER · 2014-07-25 12:39 · Score: 1

SAN certs allowed you to use one cert for both internal and external services.
http://www.digicert.com/subjec...
one cert registered to the Public and verifiable FQDN, with Alternate names in the cert something.local.
Internal CA's are very hard to deploy with BYOD these days.
(Bring Your Own Device)

--
_JS
Nov. 1st 2014? CA/B doc mentions Nov.1st 2015 by mrkoot · 2014-07-25 17:05 · Score: 1
The Slashdot article hints that a change would be effective per November 1st 2014. Does anyone know where that date originates from? The new CA/B Baseline Requirements 1.1.8 (.pdf) states:
- 2015-11-01 Issuance of Certificates with Reserved IP Address or Internal Name prohibited.
- 2016-10-01 All Certificates with Reserved IP Address or Internal Name must be revoked.
And:

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Name.

Nothing is stated about November 1st 2014?
1. Re:Nov. 1st 2014? CA/B doc mentions Nov.1st 2015 by Gerv · 2014-07-26 06:13 · Score: 1
  
  CAs normally issue certs with 1-year validity. As they may not expire later than 2015-11-01, CAs will mostly stop issuing them on 2014-11-01. I guess you could ask them to cut a cert with a special, shorter lifetime but that would be hassle (and therefore extra cost).
Is this rule flawed? by Anonymous Coward · 2014-07-27 02:09 · Score: 0

What are they going to do about wildcard certs? This is a huge revenue generator.
Internal IP's are not supposed to be gloally unique that's why we have public and private addresses. The example given needs revision.
Insight from a CA by Anonymous Coward · 2014-08-01 05:39 · Score: 0

Better info here: http://www.digicert.com/internal-names.htm