Slashdot Mirror
SSL Certificates For Intranet Sites?
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."
Why not set up a private certificate authority? Then you can manufacture as many SSL certificates as you need for private use and all you need to do is distribute the certificate authority's certificate to each browser once for the entire enterprise. Every browser out there has a way to add additional trusted certificate authorities. Indeed, if you have a "centrally controlled" provisioning system, you can even add the certificate to your default system build. Then the scary warnings go away completely.
If it works in theory, try something else in practice.
*.internal.example.com
https://www.startssl.com/
An Israeli company with inexpensive SSL (and other certs). I would also point out the prices they have for Extended Validation SSL certs.
Every browser has a way to store the security exceptions so that you don't get that warning every time. Just set the box up on a private network the first time to avoid a MitM attack and store the cert. If you ever get another warning about an untrusted cert from the box, then you might have a MitM attack going on, but otherwise if the cert matches you're fine.
You could also set up your own local root authority (most larger companies do this) and make your own certs.
I read the internet for the articles.
http://startssl.com/
Do daemons dream of electric sleep()?
Browsers should treat untrusted certs the same as unencrypted pages - they're at least as secure, possibly more secure than "trusted" certs.
"When information is power, privacy is freedom" - Jah-Wren Ryel
If the machines are windows based and reside on a domain then Group Policies can push out these certs rather nicely.
Even non-windows machines - you can script the certificate update via logon script. I do this in my own domain I have setup for issue reproduction purposes.
It is rather simple.
http://lmgtfy.com/?q=how+to+set+up+a+certificate+authority Then distribute the *organization's* cert to all the servers and clients. If you have a few clients or don't get many that fast, just do it by hand. If you have hundreds of computers or lots of turnover, you should be running central config management anyway. MIT for example distributes an MIT cert. Presto, everything on campus is protected. It's partially a question of tradeoffs: sign a cert by a CA already trusted for $$, or make your own CA and spend labor (your or users) dealing with adding the certs by hand. It's also a question of security of the CA. Perhaps some Slashdotters could share links to best practices for an internal CA.
Please help metamoderate.
At home, I simply am my own CA, which really isn't all that hard. You just need to deploy the CA public certificate to the clients and you'll never get the warning. Now, depending on the "applicances" you might be able to replace the certificate with one you signed with your own CA, but I've never tried it.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Create a new root for your company, and then install it on all of your workstations by default. Then you can create as many valid SSL certificates as you want.
I wish anything was cost neutral, but nothing is free
He who knows best knows how little he knows. - Thomas Jefferson
On window the list of CA on the machine can be centraly maneged...
I would download the spreadsheet of my schedule every couple weeks or so. They didn't have their certificate up to date (i can't remember if it was self signed or just out of date, actually). For some strange reason, it appeared that the campus network I used in my dorm wouldn't allow me to download things from an https site that had a bad cert, though I could still browse around and such.
The cert issue never got fixed. I sent an email to IT, they said "Well, we ordered the cert, we just haven't gotten it yet.." My supervisor even brought it up during a meeting.. nothing happened.
Not quite so surprisingly, several months after I no longer worked there, my email account was still active. I waited around for a while to see if they'd get rid of it, and ended up sending a "thought you should know.. I gotz email" email to my supervisor, and they got rid of my account a week or so after.
Thats the best solution. It's not that complicated, either. Godaddy has cheaper serts as well, if that's not an option.
While I am sure some vendors will take $400/year, there are many which charge far less (and have their root in all the usual browsers). Paying more does not get you more. And if you have a lot of internal appliances, a wildcard cert for the appliances/organization may be the most cost effective (a cert for *.appliance.example.com which can be applied to all the devices)
If you want to avoid managing your own CA an alternative is to spend a few more bucks on your "real world" certificate and get a "wildcard certificate" valid for all hosts on your domain and use that internally (including proper dns if you don't already have that on your internal network). //fatal
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.
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?
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
We just use the same wildcard certificate that we use for our external sites. *.domain.com, works wonders.
You might find my "PKI in a web page" useful. It doesn't require sending all certs to all browsers, just the one internal CA cert and includes step-by-step screenshots on how to do that. See https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/entry/a_pki_in_a_web_page10?lang=en
http://www.ejbca.org
Open source, full featured
Find a cheaper service. We payed something like 500 euros for a 5 year SSL certificate.
PKI is useless for any purpose other than protecting transmitted data from the eyes of technologically ignorant and unmotivated bystanders. It all rests on the trust of a third party, and there's no way to know if the third party is competent (usually not), or if the "trusted" host on the other end is a ruse. The host from which the user is initiating the connection is likely to be even *less* trustworthy, as is the user him/herself, since this person ultimately approves the trust of a certificate on the basis of zero knowledge of what is being approved or the consequences.
> do you have valid SSL certificates on your intranet sites
Yes.
> if so what do you use?
OpenSSL
> don't involve manually distributing your certificates
> and CRL to every workstation in the company?
WDS, PXE, ZCM, etc. Your automated workstation deployment process should have been worked out before you began the intranet SSL certificate project. Go back and finish that part first. Everything after will be so much simpler.
ssh -L 8888:localhost:80 frooboz@appliance.onmylan.net
firefox http://localhost:8888/
You *are* buying only *nix based appliances, right?
boycott slashdot February 10th - 17th check out: altSlashdot.org
Go for a cheapie wildcard cert. That will cover all your intranet needs.
For a private (e.g., not ecommerce, banking, etc.) web site, just create a certificate authority and use self-signed certificates, and send an email to the users covering the installation of private certs in MSIE, Firefox, Chrome and Safari. Don't waste your money on a versign cert because all it does is eliminate the warning for a price, whereas your users can eliminate it for free. Why add the tracking of additional "licensing" fees to your workload?
If it's public-facing then by all means buy the cert to ease support costs, but for employee use this is a deployment and documentation issue.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
We actually use an internal CA, and push our trusted certificates out via Active Directory group policies, but for the web interfaces we wanted to use an "official" certificate so that it would work for thinks like mobile phones, etc, without warnings, so we purchased a wildcard SSL certificate and use that same certificate for almost all of our "internal" SSL sites. We purchased a 10yr certificate from GoDaddy for right at $1000, so we figured 100/yr was pretty "price conscious". When we first purchase (about 3 years ago) the GoDaddy certificate had a few issues with some older browsers (wasn't trusted) but is a non-issue with all current browsers. You can always buy a wildcard from one of the more established issuers, but they're a lot more expensive (I think even GoDaddy is more expensive now, something like $800 for a 5 yr wildcard, but still pretty good).
Judging by plenty of the comments in threads similar to this, I think most of us are tired of seeing Ask Slashdot posts on how to do his or her job. Had this been really cutting edge, or new grounds, I could understand. However.. Enterprise PKI? Seriously? If this is to be the continuing trend of Ask Slashdot, I need to adjust my filters.. because that is just sad.
I'm finding more and more IT folks are standing around waiting to be spoon-fed solutions, instead of trying to research and educate themselves on what is already out there. It worries me that this is not just the trend in IT, but across all occupations. Am I just getting old and crotchety, or is this a new trend?
Check the name on the cert. if it is self signed, then you just have to deal with it. But if it is root signed, look at the site name. If you can find a way to use that site address to access the device then you will not get prompted.
My home router has a valid cert, but I would use the ip address and get prompted every time. I ended up making an entry in my host file for "linksys" at that address. Now when I go to https://linksys/ everything is ok.
At the end of the day, remember the whole reason these devices use SSL is not so you can verify the connection. They use it to encrypt the connection. It is so much better to use SSL instead of plain text, even though the cert is not root signed.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
HP lights out boards don't retain the self generated cert between power failures. So when power returns you get a different cert, and the exception now needs to be removed and readded.
http://pki.fedoraproject.org/wiki/PKI_Main_Page
I do deploy them but I do avoid getting robbed by Verisign for these and other certs by shopping around.
Currently I pay around $10 a year for individual host certs, and $126 a year for wildcards.
http://www.namecheap.com/learn/other-services/ssl-certificates.asp
If you have a large number of street facing certs the wildcard is the most cost effective solution anyway but for lower volumes I use individual certs as well.
It has some cost but the reduction in uninformed user headaches is well worth it.
http://ejbca.sf.net/
In it's easiest form (everything on one host), it should be easy enough to implement.
Windows 2000 - from the guys who brought us edlin
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.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
"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." - by apparently (756613) on Tuesday November 23, @10:57AM (#34318338)
Per my subject-line, to you? "CORRECTAMUNDO", I agree - those are the EASIEST/SIMPLEST ways to make sure updates/modifications to workstations/servers (nodes on a LAN/WAN) get the changes "automagically"...
LOL! I also took a look @ your post history, and you made me laugh (but, sometimes, not in a good way) - you've got to chill with the "ribbing" & name-tossing etc./et al - you don't NEED to be doing it (well, unless you're attacked that way first I figure).
You've also got to realize that a good # of folks here are NOT experienced network engineers, & many are QUITE "*NIX-centric" also, & don't realize all the "tricks"...
(Yes, I know: /. has a "rep" for having some of the "best & brightest" hanging around on it etc., but, personally? Well of the attendees here, I only give that distinction to a RARE few here (like John Carmack for example, he does post here on occasion) & yes, they've driven me to "ribbing" here before too, but, I try to only do so when someone does that to me, first. LOL, justifying it? Sure!).
APK
P.S.=> All in all, good post on your end though - & remember: You don't have to toss names or "rib" on those who make posts that may come off as "dumb" to you... it only makes you look bad (unless THEY did so to YOU, first - the exception in my book @ least), because the person you posted to may just not be aware of certain things is all! Other than that? Great post/great point... someone mod apparently up... apk
Here's where you went wrong. If you insist on keeping this constraint at any cost, then you have lost. Pay that cost (you don't get to have intranet sites) instead of getting what you want, and accept that you got the lesser of two "evils" (from a very perverted point of view).
The main problem with looking at it that way, is that you (or someone) already did what you claim you want to avoid. Those workstations don't just magically trust Verisign utterly and completely as an introducer while not trusting you a bit. They trust Verisign and not you, because web browsers got installed on them, with preferences configured to to that (and Verisign's business model is to count on people being lazy and keeping those settings). Go ahead and set up your company CA, then bite the bullet and tell all your workstations to believe it (instead of seeking to avoid this step) and get it over with.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Get a certificate for *.yourcompany.com and put each appliance under a subdomain of yourcompany.com, ie: firewall.yourcompany.com.
http://www.instantssl.com/ssl-certificate-products/ssl/ssl-certificate-intranetssl.html
We have a pretty small employee base, about 35 people and several rotate in and out all the time in the sales dept. I choose to use an self signed cert for our site. Mainly to help if that odd ball virus got on a computer. I require everyone to use Firefox and with that you have the option to accept the cert and not deal with anymore annoying popups.
The biggest problem is in off-the-shelf appliances (like wifi routers) for the whole spectrum (from personal to enterprise); they don't have domain names, so you can't have an internal CA root blessing them (at least, not out of the box), and a non-enterprise location can't easily do that.
One solution could be to bundle a CA root into the router. Initial setup would involve picking an internal TLD (with a randomly generated suggestion so we don't have everybody using "home" or "linksys"), then the CA root certificate is generated for that TLD. New appliances would have to somehow register with that CA, and for proper security, this would have to be approved by the human setting it up, but this could conceivably be streamlined.
I'm actually surprised this problem isn't solved via workaround; properly-encrypted wifi doesn't really need SSL (though a MitM attack is possible for the first connection since the AP MAC isn't yet known), and everything seems to be moving to wifi.
I'd also like to see an extension to USB Mass Storage devices that puts a tiny CGI-enabled web browser in the "filesystem" that enables configuration. Since you're plugged in, security is easier.
Use my userscript to add story images to Slashdot. There's no going back.
$400 is the price of name recognition. I use GoDaddy certs and they are 1/10 the cost. All you need for any purpose.
For some of my stuff I use the shared cert that my host provides. Still secure but throws that bloody warning. At least firefox let's me permantely store the certificate exception.
First, $400 is a stupid price to pay for an SSL cert, many providers are much cheaper...
Some cert providers (Eg startcom) will provide unlimited certs under a particular domain, so assuming you use the same domain internally its quite easy to generate more certs for the same price you paid for your external certs.
On the other hand, if its internal to your network why don't you create an internal certificate authority and just ensure its root cert is trusted by all your devices.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Surfing without encryption opens you up to eavesdropping and spoofing.
Surfing with encryption protects you from eavesdropping and spoofing.
Surfing with a self-signed encryption protects you from eavesdropping, but not spoofing, since you don't know who the signer is.
Yet, Firefox treats self-signed certificates as if they were worse than no encryption at all. The default behavior should be to treat self-signed certificates as if there was no encryption at all (from a user perspective). To give users these dire warnings, when in fact they are better protected, is just silly.
Personally, I find using the Windows Server Certificate Authority to be great for internal sites. The reason is that it automatically pushes the root cert trust to all domain members. It is also very easy to do a CSR to the internal cert server from IIS. Since you have to still do a CSR no matter how you do your "trusted" cert, going this route can be fairly painless. The other benefit is you can then use your internal cert server for other purposes such as company email signing, encryption, etc... You can also use OpenSSL, but it may take a little more to configure, but it is free. If you have a domain controller, you can just tag on the cert authority too if you are limited on Windows Licensing or hardware.
we held out for a very long time, as a non-profit academic institute that didn't want to pay for certs...
The final straw was iPhones and the like, not only NOT talking to our self-signed IMAP-SSL server, but not even complaining why... (in fact, they say everything is fine, but never retrieve the mail...) The mail app doesn't even give you opportunity to accept the cert.
yeah, you can post your cert as a file on a webserver, and point safari to it, and explicitly add it as a profile... but that didn't seem to be a long term viable solution.
so, we finally purchased a wildcard cert. I hate paying the money, but it did fix our "problems".
http://cybertrust.omniroot.com
Setup your own CA & have them trust your CA to issue certificates. GTE CyberTrust is trusted by default in most OSs
What would you recommend when the large "company" (over 100,000 employees) says that they don't want to run a CA as its too much of a liability and instead signs a deal getting SSL certificates for $100 a pop. Its always seemed rather ridiculous, but that's we have take it or leave it, Since the $100 a pop comes from a local budget, we typically leave it as we can't justify $100 per device.
Thank you, LostOne, for your generosity of spirit and helpfulness. And thank you, wiedzmin, for having the guts to ask this bunch for help. If you accept this relatively easy advice, your users will thank you too.
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.
Do as the military does. Build an installer to install all of the necessary certs needed. Deploy to your workstations from there. It's not hard and you don't force your users into bad practices. Or write a script to renew/revoke certs during the login or startup procedures. You could even build a cross platform solution fairly quick. The entire process shouldnt take more than a couple hours to build and implement. I'd do it for you, but you can't afford it.
If it's an enterprise using domains, set up your own CA and create your own CA signing certificate. Push that certificate out into the root certificate bundle or database for your browsers etc., and use it to sign all your server certificates. Since browsers can validate your server certificates, they won't complain. Have the certificate available for importing into browsers that don't accept automatic pushes. That should solve the problem, at least internally.
I don't know about your corporate policies, but if the main IT department doesn't want to deal with it, you could set up your own root cert for your department and just use that. Presumably you have a bit of internal server space somewhere that you could host it on. They're not really that hard to set up, there are a lot of tutorial online that will help you.
I read the internet for the articles.
At our site we had about 300 Apache named virtual hosts, 50 hardware appliances, and various other bits lying around. We bought a wildcard SSL certificate (since they were all in the same domain) and as it was for intranet use negotiated the license for additional uses down to a few dollars per separate machine. The vhosts were shared over a half-dozen machines, so in total we ended up paying something well below $1 per hostname that we wanted to handle, even after the initial whack for the wildcard SSL certificate.
Agreed, quit using IE. Firefox is a few initial clicks and the cert is saved. You should be connecting from the same workstation every time anyway.
Most of my company intranet is plain http. There are two parts that we encrypt with SSL. First is the optional login widget on the intranet front page. Employees can customize their front page if they choose to login, but it's not required. But since we use a single sign-in type of situation, where many services are authenticating against the same LDAP service, we feel like we should keep that password encrypted, even on pages not available to the outside world.
The second page that is https is a web form that allows you to change said LDAP password, by entering in the current password, and then the new password twice. Once again, same reasoning. This password gives you access to everything internal. We use a separate RADIUS server to authenticate for external services like VPN, etc.
So yes, we did buy SSL certs for these pages, but they are not from VeriSign, and sure as hell are not $400 per year. Look around, there are a lot of cheaper SSL certs that are in the root chain for nearly all browsers and devices. The only thing we had trouble with--where users had to import the root CA and the cert themselves--was Android 1.x devices. Since we're an iPhone shop and don't officially support Android, I let them figure that one out. :-) But apparently Android 2.x devices worked without any extra hassle. But back to the main point, I think we paid $200 for three years' worth of SSL for these sites.
Now, for our VPN and Zimbra webmail, which are both public facing, yeah we buy some fancy-schmancy VeriSign certs that make the address bar turn green and other features that allow the big CAs to gouge you for their certs. We do this for widest compatibility, as we allow people to check their webmail via https from any internet-connected computer in the world.
:q!
In a previous life we used an internal CA. We just had to install the CA's PEM file on each workstation. This is made easier if you have an automated build system for workstations (which is good IT practice in general).
If you become verified by StartCom at the level 2 rate you can issue *unlimited* SSL certificates for any verified domain (verification is free). The second level is $50 per year for unlimited certs... highly recommended! I use this on all my internal "appliances" and websites.
If you have a Windows environment with a Active directory you could deploy with GPO (Group Policy) to all the desktops on the domain. http://www.tcpdump.com/kb/os/windows/certificate-deployment-using-gpo/all-pages.html If you have Linux desktops may be you colud deploy a package with the certificate. If you set up your own CA, then you must have to deploy the CA certificate once too.
Damia
If you're spending $400/year on a cert for an intranet, you're wasting money. You don't need EV, and certainly don't need the insurance policy against someone breaking the crypto. Certs recognized by all modern browsers can be had about about 1/40 of that.
Once per browser, that is.
My company's web-managed product just uses self-signed, with the option to add a third-party signed if the customer is willing to pay for and install it themselves.
Another non-functioning site was "uncertainty.microsoft.com."
The purpose of that site was not known.
Startssl.com will give you a free Signed SSL certificate for use with a webserver. Good for your base host domain & 1 additional host. I've been using them for a couple years. I run my own server for fun at home and wanted to try SSL to add it to my resume, and also to secure communications, and just because I could. It wasn't too hard, and well worth it IMO. Give it a try, worst case you are out the cost - NOTHING!
In case you do run your own CA, what tools do you use to manage it?
Over the years I have written my own wrapper scripts around openssl, and I never bothered looking for something else, but as I read this thread I came across EASY-RSA and started to wonder what else is out there.
And how about end-user instructions that exaplains how to install root and user cert? I manage one root plus around 40 user certs, and it is sometimes a hassle to provide solid instructions for all these browsers, as they tend to change.
How to you handle this on a larger scale?
1- get tinyca2...
2- install, start the tinyca2 GUI (yes, not command line!!) and generate *your own* CA
3- create the certs you need, sign then with your CA
4- import the your CA to the browsers, put it on a webpage, so people can easily install by just clicking on a link
5- profit!!!
tinyca2 is just one, there are more PKI packages out there, both more simple (easy-rsa) to more complex (openCA), to different license (bsd based - XCA)
Higuita
It goes like this: You give them a heap of money and a CSR. They send an email to the account listed as the administrative contact in the DNS registration. You click the link in the email, the cert is signed, and you then log back in through their website to download the final result.
SO— if you can change the DNS details (e.g. if you can fake some letterhead and send a fax) _or_ if you can get access to that email account, _or_ if you can just convince the account holder to follow a link ("This is bob from verisign, we're going to have to shut off your website in 15 minutes if you don't click the link in the email we sent you.") then you can mint certs for an arbitrary site.
Worse— there is no real way to tell how many certs are floating around out there with your name on them, so often the attack will be undetectable by the site operator.
You could buy a wildcard certificate. *.yourdomain.com or *.intranet.yourdomain.com and have it cover all of your devices with a single legitimate certificate. You can also buy certificates from godaddy for $10-15 for a single domain, or $129 for a wildcard
Why the hell would they agree to $100 per cert? I've never ever seen such a high price on a non-EV cert.
If it's a damn internal cert, you can spend $15 and get the cheapest one that works on the stuff you support.
Hell, you can probably find a wildcard for $150 if you look around.
Of course, all this is stupid, you shouldn't have to sign stuff to get encryption, but we've all beaten that dead horse.
If corporations are people, aren't stockholders guilty of slavery?
SSL certificates have two goals, identity/trust and encryption. Self-signed certs establish encryption by default. If you save the self-signed certificate in your browser, then trust/identity is established manually, which is the only selling point of of a cert signed by a CA. Once you have the cert saved an error message is no longer displayed unless the certificate changes.
Firefox has this option selected by default upon bypassing the initial error message. In IE, view the certificate and "Install certificate..." Done.
You indeed can use RPM packages to deploy certs. When I was at a DOE lab working on LHC stuff, we had hundreds of CAs from all sorts of EDUs that needed to be installed on grid computing systems. All done with RPM package management (with yum of course).
A wildcard certificate has the server name *.yourcompany.com in it and you can install it on as many servers as you wish.
echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
...to ask honest questions (even if top-level, not "do my job for me" detailed).
It is the place, however, to get pilloried by experts who exclaim if you had only used the right search terms in Google, written a small kernel patch, rolled your own Linux distribution with it, and installed it on every server and PC in the company over the holiday weekend, your problem would have been easily & trivially solved in time to come up from the basement and join mom and dad for Thanksgiving dinner.
I understand the impetus for not owning a certificate authority. I'll note the PCs are easy, it is the non-pc https enabled devices that are becoming the hard part. Anyhow, we just bought a multi-domain UCC certificatefrom godaddy for $99 a year that lets us give "legit" SSL to 100 or so devices without taking on the role of being a CA.
I have used startssl.com; I was amazed to find that there exists an SSL certificate provider whose root certificate is present in most mainstream products and who provide all automatable services (including the issuing of certificates) free of charge.
Highly recommended.
This is not for the OP but for the German Slashdot crowd.
I have been using PSW Group at http://www.psw.net/ and I am very happy with them.
Their website looked like a scam site to me but I researched them before I purchased and they are legit. I am now paying 29/year for not having to explain the private cert deal anymore.
Everyone who buys Wild Hunt will receive 16 specially prepared DLCs absolutely for free, regardless of platform.
A lot of responses that I have seen to this question are basically the following.
"Create your own CA (certificate authority) certificate and distribute them to the client workstations." Then they accuse the original poster of having asked an overly simple and uninteresting question.
I am going to say something nobody else seems to have said. SSL sucks big time for large workgroups inside a private intranet. It is an inappropriate solution that is being used for the lack of anything better. IE will give AD based authentication for browsers, but did not extend that to securing the communication channel itself.
This issue is much nastier and more complex then anybody has allowed for. SSL does a very good job of solving the problem of creating secure communications over untrusted anonymous networks. However, they are a real pain when the only thing you want to do is create a secure communication between two machines in the same room. In those cases, SSL comes with a lot of overhead that is really not needed. In the case of two machines in the same room (or workgroup), the machines are already on internal corporate IP addresses, so a lot of the issues that SSL was designed to solve (validating that the IP address really points to the expected entity) just are not applicable. Usually the only reason why you want to encrypt the data is so that somewhat private data won't be sniffed by other users. You are not trying to prove that you are a legitimate seller of any goods or services.
What really astounded me were the claims that it would be easy to get users to accept company controlled installs of browsers and tools. I have worked in such an environment and it was actively resisted and foiled because the choices were so limiting. For those who say "it would work it was done right", probably have not done cross browser development where you had to test on Linux, Mac, and variants of Windows machines. Nor have they done Java development where the Java has to communicate to the server (over https) as well (Java has its own client CA chain distribution).
Every place I have ever worked (big or small) has had http web sites when they really should have been https because of the pain of trying to use SSL. To say that this is because of bad IT management I think gets it wrong. SSL is a bad fit for this problem space and browsers (and Java) need to support other security solutions. It would be nice to recommend Kerberos, but Kerberos has really only gotten full implementation with AD and is even more painful for client adoption in most (with non Microsoft machines in the mix) real world scenarios I have seen. The state of intranet security is broken at its foundations and the proposed solutions that have been suggested here would not work (in practical, reliable, real world usage) for many workgroups working inside a much larger corporate entity.
Find the cheapest single-root wildcard that will let you do at least 2K. Then install it everywhere in the intranet, being careful with the permissions so nobody can easily steal it.
Either get it on a single-year basis or be prepared to do a revocation if it gets stolen before it expires. If you are conscientious with your file and folder structures and permissions, though, and you hire trustworthy techs, it probably won't get stolen. Unless you depend heavily on an OS with lots of zero-days and your site is a high-value target, of course; banks that use IIS are just asking for trouble.
If you never patch your server OSes or firewalls you shouldn't buy certs at all. They'll just get stolen.
This is the most sane way to handle this, if its truly an admin only control interface. It's also a great way to allow access to appliances from outside of the private network as well.
It has been said about 300 times here already: install an internal certificate authority and push the CA certificate out to all of your browsers....
The cheap option is to use an open-source SSL CA; a client of mine (one of the planet's most profitable law firms) was using Verisign to sign internal certs, partly out of laziness, for internally protected (https/SSL) apps. I recommended an internal cert auth and their security gurus deployed an open source CA. They pushed the CA cert out to the worldwide desktops via Windows Group Policy so that the browsers would recognize the signing authority. worked a charm: all internal certs signed for free. Lots of money saved...
For another client (big company that manages railway infrastructure on a big island in the Atlantic), we deployed the Oracle "Certificate Authority" (Part of Oracle Identity Management) - don't laugh - and it worked as well. Needed to push the CA certificate out to the desktops via Windows Group Policy. Also worked a charm.
Only fools use public cert auths such as Verisign to sign internal-facing certificates.
Both clients had it on their "to do" lists to deploy the MS Certificate Authority, but is was deemed low priority, so another solution was needed...
We don't purchase any of our SSL certs from over-priced Verisign. We buy them from other companies that provide browser trusted certificates for $10/ year.
For our internal sites we bought one wild-card certificate which we use for all our servers. It costs more but we use it for hundreds of things so we save in the long run.
www.cacert.org do FREE certs and are in a number of Linux Distros (Debian, Gentoo, Mandriva). However they don't do organization validation, so the cert has the domain name but not the "claimed" organization name.
They even have a howto, http://wiki.cacert.org/SimpleApacheCert. Plenty for most SSL requirements.
Seeing as how certificates don't actually do anything at all except eliminate browser warnings, why on earth are you spending $400 for an internal appliance when you can cet one for $15/year? or $35/year, or $75/year all in a matter of minutes.
.... that knows everything there is to know about technology.
No false modesty there, thanks goodness....
IANAL but write like a drunk one.
Man on the middle attack: It can happen on an Intranet. This is why you need things like SSL.
IANAL but write like a drunk one.
one could also get a class 2 cert (valid for *.company.com). It would be also valid for internal.company.com domain.
We typically just reuse our wildcard cert from DigiCert. They allow as many resigns as you want.
http://www.digicert.com/
A large company could distribute their new CA information via a login script. It sounds like this guy lacks that luxury.
Namecheap will sell you a Comodo cert for $10 a year. That'll do what you want.
SSL is a PITA. It's much easier to configure Apache to only serve admin pages to the local machine. SSH tunnels are more secure and easier to maintain too.
Expected time to finish is 1 hour and 60 minutes.
This is a great post; it was very informative. I look forward in reading more of your work. Also, I made sure to bookmark your website so I can come back later. I enjoyed every moment of reading it. http://www.optionpoppers.com/
I recently came across your article and have been reading along. I want to express my admiration of your writing skill and ability to make readers read from the beginning to the end. I would like to read newer posts and to share my thoughts with you http://www.optionpoppers.com/
I buy my certificates through OmegaSphere. The service has been fine, and the price is low enough that it isn't worth the hassle to try and do it myself.
Note that they actually charge less for an intranet certificate than they would for an internet-facing certificate.