SSL Certificates For Intranet Sites? 286
wiedzmin writes "Anybody who has worked around anything dubbed an 'appliance' in the past few years knows that they come with a management Web interface, which is usually 'secure.' However, no company in their right (accounting) mind will spend $400/year per appliance to buy Verisign SSL certificates to secure Web interfaces on networks that may not even be open to the public Internet. So network administrators, and sometimes end users, are stuck clicking away at an annoying 'Continue to this website (not recommended)' message every time they connect, setting an unhealthy precedent when it comes to the actual security of SSL and the much-hyped MITM attacks. So the question I have for the Slashdot crowd is: do you have valid SSL certificates on your intranet sites, and if so what do you use? Any cost-neutral, or at least cost-conscious solutions out there that don't involve manually distributing your certificates and CRL to every workstation in the company? Thanks."
Re:Private Certificate Authority (Score:5, Insightful)
Because your question implies that the asker is actually competent at their job. Anyone with half a brain would have already come up with that solution a long time ago.
Why are you clicking through that box every time? (Score:4, Insightful)
You could also set up your own local root authority (most larger companies do this) and make your own certs.
Re:Private Certificate Authority (Score:3, Insightful)
The available certificate servers which are Free Software tend to be rather user-unfriendly. Maintaining certificate revocation lists and handling certificates for different purposes (mail, web, code, client authentication, vpn...) are needlessly time-consuming chores. Obviously any competent system administrator can script their way out of it, but in this case it is a rather large effort.
I would be very happy to hear about an easier solution.
Re:Private Certificate Authority (Score:4, Insightful)
FTFP: "Any cost-neutral, or at least cost-conscious solutions out there that don't involve manually distributing your certificates and CRL to every workstation in the company? Thanks."
Before snarking on the FP author, perhaps you should actually read the FP's question?
Re:Private Certificate Authority (Score:3, Insightful)
Doesn't mean he's wrong. Seriously, this is SSL 101, and anyone tasked with setting up SSL-protected websites should've intuitively known the answer before the question was even asked.
Re:Private Certificate Authority (Score:5, Insightful)
Sorry, but every certificate authority is manually distributed at some point, the verizon's of this planet included, they just have the convenience that browser manufacturers do that for them.
The most automatic way to do what the main requester wants is to set up that certificate authority and roll out your browsers automatically after adding that certificate authority it's root to that browser.
I do not know any other way to do this automatically.
Are you seriously that dense? (Score:4, Insightful)
FTFP: "Any cost-neutral, or at least cost-conscious solutions out there that don't involve manually distributing your certificates and CRL to every workstation in the company? Thanks." Before snarking on the FP author, perhaps you should actually read the FP's question?
So a login script (or in a Microsoft environment, an AD group policy) that distributes the certificate automatically to each computer meets your definition of "manual distribution?"
Really? That's what you're saying? "Automatic" and "manual" are synonyms in your universe? wow.
Why does this always get marked troll? (Score:3, Insightful)
What we actually have here is a psychological issue - the cert vendors want you to believe that anyone who doesn't buy their certs is a potential criminal. The rule should simply be "no financial transactions or personal data on a site without an entrusted cert".
Other than common sense, there is nothing to stop me posting my credit card details on Slashdot. If I log into a public forum using HTTPS, I still have no protection against my own stupidity if I do that. Now, without simply modding this troll, can anybody give a coherent explanation as to why browsers shouldn't assess self-signed certs according to their origin - within the intranet, valid server name - rather than treating selfcert.ru the same as selfcert.10.0.0.1?
Re:Private Certificate Authority (Score:3, Insightful)
A variant would work if all browser user were technical enough to download and install a browser, that is a central in house downloadable copy with that root installed in the browser.
That only works if you're also fine with local users having the privileges to install software on their workstations. So you're only trading one security issue for another.
Re:Untrusted certs should not raise an alarm (Score:5, Insightful)
The only thing the "trusted authorites" confirm is that the person who has the cert paid for it.
Some trust.
The whole SSL certificate crap is a scam. The only interesting thing to know would be "is this site using the same certificate as the last time I connected to it". And the shitty browsers don't tell you that.
(The protocol should also have some reasonable way of doing rollover, like presenting a new certificate in the session "this is what we're going to be using starting...").
But they don't authenticate the remote site. They just check that the remote site has a certificate signed by one of those super trustworthy people like Verisign or the government of China.
Re:Seriously? Do your own job. (Score:4, Insightful)
That's the "I'm feeling lucky" google-fed generation.
If it's not on the first page in google results, go and ask in a forum.
Though, that's actually old-school, sort-of - people tend to ask in their twitter feed nowadays...
Troll Tuesday hits Ask Slashdot! (Score:4, Insightful)
Congratulations on getting your story accepted to the front page!
Dozens of man-hours will now be spent explaining basics of inhouse certificate authorities and self-signing, along with comments on your lack of basic research, intelligence, qualification for your position, and legitimate parentage.
Re:Seriously? Do your own job. (Score:1, Insightful)
I learned a long time ago never to submit a question to Ask Slashdot because even if it is something obscure and arcane, people will gang up on me and call me stupid for not knowing it.
Re:Share the wisdom of Slashdot. (Score:3, Insightful)
And to those of you here who claim "half a brain": please remember that you yourselves may someday need to do something (legal, financial, educational, even technical) for which you are less than half competent. Yes, you have achieved a "win" in humilating a sincere poster, but it's the cheap victory enjoyed only by the pusillanimous.
Here's the deal. Either this person is administering a smallish number of machines, in which case he/she can simply go 'round and install certificates on all of them, or they're administering an assload of them, in which case they do indeed deserve the scorn for not being willing to do a modicum of research and choose the standard approach.
Your defense only works if they're in charge of too many machines to administer manually, but yet have no experience doing so - a situation which is highly unlikely. It might be a temporary situation due to turnover, but in that case they shouldn't be implementing a "convenience" feature like this one themselves.
Re:Private Certificate Authority (Score:3, Insightful)
Yes! I've discovered lately when evaluating Chrome for workstation use that Chrome now has a (ever-growing) list of group policies available. Grab the adm/admx [chromium.org] templates and MSI installer and check them out.
Coincidentally, the latest Chromium/Chrome Canary/Chrome Dev builds also started ignoring IE's trusted zone lists and so windows integrated authentication (Kerberos Negotiate) stopped working. Boo. Supposedly there's a new policy that I can set to fix this. I reported the issue [google.com] but am waiting for clarification on whether this is intended behavior, a security issue, or what.