New SSL Server Rules Go Into Effect Nov. 1

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.

Comments

Why?

[Ark42]

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?

Re:Why?

[Anonymous Coward]

Also, why were the CAs *ever* granting these certs? And is it too late to get one for "localhost"?

Re: Why?

[tysonedwards]

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.

Re:Why?

[gregsmac]

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.

Re: Why?

[QuietLagoon]

...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.

Re:Why?

[MightyMartian]

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.

Re: Why?

[blueg3]

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.

Re: Why?

[Albanach]

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.

Re: Why?

[unrtst]

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.

Re:Why?

[El_Muerte_TDS]

Because of money.

Re: Why?

[Z00L00K]

Assuming the CA can be trusted.

I'm not trusting the CAs that exist to not reveal key data to NSA or other organization.

Why use public CA an internal server?

[Sloppy]

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.

Re:Why use public CA an internal server?

[Anonymous Coward]

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.

Documentation

[dskoll]

I'm curious as to what documentation the CA's required for you to prove that you own localdomain or 192.168.2.22.

Re:Why aren't they already unique?

[Z00L00K]

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.

Four letters: FQDN

[tepples]

What is the new naming convention that has to be followed?

More than likely, a fully qualified domain name.