New SSL Server Rules Go Into Effect Nov. 1 92
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.
Re: Why? (Score:5, 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.
Re:Why use public CA an internal server? (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.
Re:Why aren't they already unique? (Score:4, 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.
Re: Why? (Score:4, 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.