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 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.
Why? (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?
Re:Why? (Score:5, Funny)
Also, why were the CAs *ever* granting these certs? And is it too late to get one for "localhost"?
Re:Why? (Score:5, Insightful)
Because of money.
Re: (Score:2)
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.
Re: Why? (Score:5, Insightful)
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? (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: (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
Re: (Score:2)
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 co
Re: (Score:3)
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 trus
Re: Why? (Score:2)
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
Compartmentalization (Score:2)
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 [youtube.com] on the health information of patients who aren't hers.
Re: (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?
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.
Re: (Score:2)
Re: (Score:2)
They get enough to be able to provide a man in the middle attack.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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 certif
Re: (Score:2)
Re: (Score:3)
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 l
Re: (Score:1)
But certificates are given for names , not addresses, and you don't specify any address in the request.
Re: (Score:2)
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 [eff.org] 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 al
Re: (Score:3)
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 T
Re: (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... [godaddy.com]
Re: (Score:2)
Re: (Score:1)
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.
Re: (Score:2)
Re: (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...
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
So you use a VM, marginal cost is near zero for a 4GB VM in todays world.
Re: (Score:2)
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.
Re: (Score:3)
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: (Score:2)
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 Net
Re: (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.
Re:Why?- SAN cert (Score:1)
SAN certs allowed you to use one cert for both internal and external services.
http://www.digicert.com/subjec... [digicert.com]
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)
Re: (Score:2)
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.
Re: (Score:2)
Why use public CA an internal server? (Score:5, 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.
Re: (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.
Group Policy (Score:2)
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.
Re: (Score:2)
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
Re: (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
Re: (Score:2)
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.
finally (Score:1)
So the people responsible for enforcing the administrative details of enforcing the spec are finally realizing they have some work to do?
Big Problems (Score:1)
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 Exchan
Re: (Score:2)
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.
Re: (Score:1)
So, split DNS then? (Score:2)
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.
Re: (Score:2)
Keep a master list (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!
Re: (Score:2)
One thing neither APK nor APK can do (Score:2)
Four letters: FQDN (Score:3)
What is the new naming convention that has to be followed?
More than likely, a fully qualified domain name [wikipedia.org].
Documentation (Score:3)
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: (Score:2)
None. Now you've identified and understand the problem.
Re: (Score:2)
Or is this an option?
RFC 3280 #4.2.1.11 [ietf.org]
>
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 th
Nov. 1st 2014? CA/B doc mentions Nov.1st 2015 (Score:1)
And:
Re: (Score:2)
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).