Slashdot Mirror
Cheap SSL Certificates for Small Websites?
zaqattack911 asks: "In the workplace today it is becoming more and more common for everyday applications to be accessible over the web. Just about all the booking and tracking systems at my job are handled via web-apps these days. Along with this trend, is the increased need for secure transactions over the web. Just about all of the apps on my webserver are going to be SSL only. Some of them are for internal use only, some for the outside internet to use. Is there a cheap alternative to getting your certificates signed? Self signing my certificates works of course, but just about all browsers make a big fuss about it. Verisign asks for about 400$ initially, and 300$ to renew a certificate every year. This seems like a scam to me, and I'd love to know if anyone knows of alternatives out there? Is there a way to get around the certificate signing business? I looked at a company called RSA Security which allows a company to 'self sign' and use their accepted signature. The website doesn't mention the price, and I'm sure it's not very affordable. What else is there?"
a bunch of excellent geeks I know use entrust.
four-oh-four
They charge $199 for certificate, and have a pretty good service. I've been using them for years.
we use them for all of our commercial sites.
A year spent in artificial intelligence is enough to make one believe in God.
The stories /. has already had on the topic....
0 1/03/18/18 55230&mode=thread&tid=93
0 1/09/06/04 51218&mode=thread&tid=148
Why Are SSL Certificates So Expensive? by Cliff with 192 comments on Sunday March 18, @04:48PM
http://ask.slashdot.org/article.pl?sid=
Are FreeSSL Certs Worthwhile? by Cliff with 8 comments on Friday September 07, @11:50AM
http://ask.slashdot.org/article.pl?sid=
You can use it to create certs, and you can even add your organization to the browsers trusted organizations so the users don't get an error message.
Rackshack.net has a link to a $49 QuickSSL certificate. I haven't used them, but it sounds like a good deal.
Title says it all
There aren't really many options, because the browser has to recognize the signer, and the major browsers only recognize Verisign (and Thawte, which is also Verisign).
RSA is the company that started Verisign, so you can guarantee they'll not be of help.
If this is a situation with a limited client base, like a company, you can self-sign and send everyone your CA certificate and have them all import it into their browsers (all browsers support this, I believe). But what a pain.
I wish the news was better, but you're right -- it's a scam. The problem isn't technical; it's political.
I, for one, welcome our new Antichrist overlord.
Thawte may be worth looking into. They used to be a competitor to Verisign, although now I believe they are owned by them (what isn't?).
They have certs available for $199. Still not cheap, but better.
-Pete
Soccer Goal Plans
I say the same thing about signing my Java applets. Sun only puts Verisign or Thawte root certificates. So if you want to avoid your customers seeing some redicuouls
"Jesus!! this software is unsigned!!!"
message, then you gotta buy the certz. I am self signing right now. I would love if OSDN could have their own root certificate and let us public folks buy from them. Any malicious signers will be found out quickly so whats the big deal???
I think this signing thing is DRM in action. Nobody is realizing it yet.
I would just go for one of the thousands of web hosts that give you some sort of SSL package. Unless you need your very own certificate, they are definately the way to go for the small business because the host purchases the stuff and just charges you a small fee.
If this is not acceptable for your situation, then I am afraid you have to bite the bullet and front the money.
But don't get lost in the middle - remember the whole reason you are using SSL is for security. Whether the certificate comes directly from you or your webhost doesn't really matter as long as it is secure. That's why I would recommend that you let them pay for it and disperse the cost among their users.
If you had nuts on your chin, would they be chin nuts?
You can even get a free 30-day trial cert.
I would agree, but I can't get IE to install the certificates permanently. I click through the install dialogue every session, but it never sticks. Mozilla is fine after the first run.
Don't blame me, I get all my opinions from my Ouija board.
You can purchase a ridiculously cheap ($50) 128bit SSL cert, trusted by browsers from http://www.geotrust.com
All you need a valid credit card to get a
cert. The CA key is loaded in almost all of the browsers, the notable exception being Opera.
They do send a 'auth check' by emailing the domain admin contact you can select.
The entire ordering process (including filling out forms) takes less than about 5 or ten minutes.
This should SCARE you if you're relying on the security provided by Veri$ign and the root that ship with browsers. - pablos.
You may find what you're after over at http://www.cacert.com The creator of this website believes that trusting someone should be free, and is doing his best to make this happen.
There is a nice page, http://www.whichssl.com. Through the comparison tables there I found comodo's http://www.instantssl.com. I generated a demo certificate first and after I had no problems with it, I bought it. For $49 a 128 bit, not 40. Recommended.
At $49 a piece for standard certificates they're the cheapest my company could find when we went looking last month. So far I have no problems recommending them.
sig sig sputnik
comes with openssl. It even has a nice perl script to make it easy.
What Verisign and co have that you don't is their root certificates installed with the browsers by default. For internal use you should have no problem using your own certificates. For external use, where an existing business relationship exists (ie you aren't selling to the public, but to people who can trust your cert because they know who you are) it should take little more than a quick explanation.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Sure we all hate VeriSign for all kinds of reasons.
However when you get an SSL Certificate from VeriSign and some of the other Cert signers out there, you are getting two things.
The most commonly understood thing you are getting is the encryption thats automatically accepted by just about any modern browser. However, the reason it's automatically accepted is because VeriSign is suppose to verify the identity of the business. This is why they require a Duns and Bradstreet # (It's a business credit identifier). This way you know when you're going to https://secure.yourdomain.com to enter your credit card information, that you are indeed still on yourdomain.com and that your information is encrypted, and verified to be sent to the company you intend to send it to.
So if all you are concerned about is encryption, just generate your own. It will however throw a warning in just about any browser that the identity of the site can't be verified. Other than that, cost of this service isn't going to drop very dramatically without losing its verification services.
I understand though, that browser warning annoys me too.
..There's a-dooin's a-transpirin'
Never heard of 'em. Must be some fly-by-night operation. :-)
Try out FreeSSL.com - they used to give fully signed SSL certificates away that lasted for three months.. I read that they were planning to offer free 'year' certificates.
They also currently offer a ChainedSSL certificate at a cost of $25 per year...
"Hey! Unless this is a nude love-in, get the hell off my property!!"
There is a way to do this with ASP scripting. A good base to start with can be found at this Microsoft Knowledge base article.
It is a starting point I used to make the root certificate stick. It will present the user with a large-ish alert box asking them if they want to install the certificate. It will only do this once as long as they click 'yes'. Subsequent visits to your site will be automatic from then on out.
This is course is great for internal sites, you can educate your users to click on the box the first time, then they never have to worry again. And they know it's trusted since it came from you. One small caveat, this probably only works on IIS servers and only works in IE web browsers.
- "A non-productive mind is with absolutely zero balance."
- AC
The established certification companies are already on this list. You are not. If you self-sign, you are basically counting on your potential customers to trust you as a certification authority. They can add you to that list individually. The question is, will they?
Since you are an unknown, small company, basically your customer has to trust that you have done everything right in order to protect their security. That's a lot to ask someone. Having a big player certify you tells your potential customer that even though you are a small unknown, you have done everything right.
It's just my personal opinion, but its one based on running an e-commerce site for the last four years. Go with an established certifier. If you are doing any sort of business at all online that requires SSL you will more than make up the annual fee in the sales you don't turn away because you were too cheap to get a real certificate.
No, Thursday's out. How about never - is never good for you?
Has anybody used InstantSSL? They claim to work with IE 5+, NS 4+, AOL 5+ and Opera 5+, which they say is 99% of the browsers in use out there. Sounds like a good deal to me.
I'm looking at using the cert to do some credit card auth for a webhosting company, and I don't really think I'd have a problem turning away that 1% of people who can't upgrade to a browser that came several years ago. That whole 80/20 rule kicks in there. I'm sure somebody who can't be bothered to upgrade to a modern browser is going to be a tech support nightmare.
And put text in saying to click through the security warning. Most people will, anyway.
An excellent example of why "computer security" is an oxymoron.
Seriously though, this is of why many viruses spread -- people are gullible and lax on security. While I really understand that getting a proper certificate can be expensive, I'm not sure if I want to encourage this type of behavior.
Who said Freedom was Fair?
You're going at the problem wrong. Don't worry about getting your clients to accept a self-signed cert, worry about getting them to add your own root certificate to those they trust.
This is actually straightforward - you point them to a URL that returns the root cert, with MIME type application/x-x509-ca-cert, and tell them to accept it for all uses when the broswer pops up a dialog box.
You should then use this root cert to sign your web server certs (and certs for mail servers, databases, whatever). All should be trusted immediately, assuming you have your other ducks in a row. (E.g., you need to have your web server cert's common name resolve to the IP address of the web server.)
It's a bit more work to maintain a mini-CA than to just use self-signed certs, but overall the benefits outweigh the hassles. Many of us are working on JSP tools to operate mid-range CAs, but I don't know how far most are. (The problem is Microsoft's eternally changing standards on how clients generate the cert request on their side - I can handle Netscape/Mozilla with ease, but it seems like every version of MSIE is just slightly different.)
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
I think a lot of people out there use some other browser than Mozilla, though, so you might want to see what certs that other browser supports.
314-15-9265
Have your company buy a key, then create signed keys for your domain private domain with it as the issuing key. Nobody will know, as most people still use IE, and it still has that fun bug.
The Right Reverend K. Reid Wightman,
.sig: file not found
CA links
CA links
314-15-9265
Its easy to click-through with internet explorer. But what if you've got Netscape 6 or Mozilla?
Sure, its easy to use https mode, but what if you want to sign applets?
Its a REAL pain. You have to download a public key, open up a console, find your certificate store, and manually add it.
I made something that I wanted to do that with. What a pain!
Mod me down and I will become more powerful than you can possibly imagine!
I couldn't find rackshack listed in any of the "approved" signing sources for mozzila or netscape.
"Eve of Destruction", it's not just for old hippies anymore...
I just went to their Web site and if you click through you will find that they do actually sell Thawte certificates, you are sent to the Thawte site.
This is probably just an innocent thing where people were going to Thwate and trying to get certificates and someone decided to take advantage of the channel.
I will get onto legal tommorrow however just to make sure that nothing unfriendly gets said by mistake. There used to be a company in the UK with a vacum cleaner called VAX. They got a nastygram from a random DEC legal outfit every week.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
... and can manage an installation of certificates on all clients, you can create your own certificate authority all by your self.
Here are some *SIMPLE* instructions for building a self-signed CA cert, and then signing SSL certs for servers. Any real implentation should probably be assessed for security (like ca-generation on an isolated machine, etc ...)
That's pretty much it. mix into your IT operations as nessecary
Why aren't you encrypting your e-mail?
A better way to prove your point is to advocate the use of openSSL and other non mainstream solutions. You have a valid point, but busting open everyone's secure data using a distributed crack is irresponsible, lame and dangerous. Get some ethics.
Certs prove you are who you say you are, not that you are a reputable company. Otherwise, someone can spoof your IP address and or domain name, collect your clients secure information, and the whole process is encrypted using the attackers keys, not yours.
It is a boot strap problem. Since your clients connect to your over the web, there is no way to prove that you are really you. Instead, you say, my CA (e.g. Verisign) says I am me, and hand them something they can use to verify that info. The browser checks the cert that your site offers, and using the Verisign public key, can ensure that you are actully signed by verisign. The fact that Verisign's public key was shipped with the browser means that the trust chain goes like this:
Install disk (or Download from Mozilla site)->Verisign->You
You can become your own CA, but that borken link is still there.
Another option is to use something like PGP or hand delivered Certs, which would work for an internal website or a limited audience.
Adam
Open Source Identity Management: FreeIPA.org
I have a question regarding this sort of setup. Namely, what do the existing established (i.e. shipped with IE, mozilla, and netscape) CA's do in order to verify the identity of the requestor? I presume at least some of the cost an organization must pay is to cover administrative costs of verifying identities. And if the companies do nothing substantial to verify the identity of the purchaser, why the hell are browsers shipping with their certificates? If they provide decent identity verification, then I wonder if a free CA would work well. Even if it did get distributed, if it cannot provide decent verification of requestors due to budget constraints, it would be an exploitable weakness in the trust system...
XML is like violence. If it doesn't solve the problem, use more.
Because the service they provide to you - the person with the $400 - is that end-users will do business with you securely because they trust the certificate.
And for goodness' sake, get off your high horse about end-users' understanding of cryptography. The business reality is that the $CURRENCY_UNITs of the people who understand cryptography are no more valid than those of everyone else.
Unless you have a niche market amongst cryptographic experts, not having security warnings popping up in browsers is the most important thing that customers (yes, those people who pay your rent for you) want to see.
Don't know about you, but $400 is small beer to any business I can think of that needs SSL for the general public. If $400 per annum kills your business plan, then maybe you don't need universally accepted certificates for SSL after all.
The only thing you can accurately describe as "Scotch" is a sticky tape made by 3M. And it's
Why Are SSL Certificates So Expensive? by Cliff with 192 comments on Sunday March 18, @04:48PM http://ask.slashdot.org/article.pl?sid=01/03/18/18 55230&mode=thread&tid=93
4 51218&mode=thread&tid=148
Are FreeSSL Certs Worthwhile? by Cliff with 8 comments on Friday September 07, @11:50AM http://ask.slashdot.org/article.pl?sid=01/09/06/0
Poor Cliff. Perhaps he will get an answer this time around.
"I'm not impatient. I just hate waiting." - My Dad
Kurt Seified has some good information on installing certs in I.E. Whats really cool is it lets you easily install certs for other apps like imaps/Outlook etc.
3 ,s id1_gci833806,00.html
http://searchwin2000.techtarget.com/tip/1,28948
They're a Thwate affiliate taking advantage of misspellings... scummy, I'm surprised Thwate hasn't taken them down.
Seriously, why SHOULDN'T you do this? The only thing Verisign does is take exorbitant amounts of money to "prove" you are who you say you are. But if you don't trust someone at their word, you probably don't want to do business with them in the first place!
I'd suggest that doing this even for sites used by the general public is OK. Just put a quick explanation on the site. The exception might be if you're running a large operation collecting credit card numbers, in which case you can afford Veri$ign's price and don't want to lose a bit of business.
I use InstantSSL (Comodo) [flash alert]. Works great. A little Apache tweak, nothing on the client side, and haven't found an unsupported browser.
Best part: $49.
S
We just need the a trusted authority (for certain definitions of 'trusted' and for the definition of 'authority' that is ubiquitously recognized instead of decided by the highest bidders in the browser wars) to make digital assertions.
You'd start with certifying identities: my state might sign a certificate certifying my name, maybe driver's license number, perhaps address and even a photograph. I should now be able to sign e-mails with this now independently of my e-mail address. The resulting signed message could carry whatever signed assertions I wanted to put on it. (Probably my name and maybe my photograph.) I can't forge these, because these components are signed by the state in connection with my identity. A posting to a self-help group might just assert my identity in the form of a photograph and an unsigned nickname.
Taking this a step further, I should be able to use this ID to sign other things, even web sites. This will require changes to the way users perceive an "authenticated" web site. If I go to a bank at www.example.com today, they have a certificate that basically states "www.example.com is Example Bank, and their identity is certified". What my own signed web site might assert is "www.example.com is Joe User". User agents need to give more weight to the name here and less weight to the fact that the domain name matches what's in the certificate.
Extend this now to corporations. When a corporate charter is created, a digital ID for that corporation is created along with it and signed by the state of incorporation. That corporation can now sign assertions like "Joe User is the CEO of Example Corporation".
So now, when Joe User sends an e-mail, he can include this information:
- Joe User (signed by the state of residence)
- (Joe's picture, signed by the state)
- Job Title: CEO (signed by Example Corporation)
At this point, we really have a framework to allow the signing of most any type of assertion. If someone feels that we still need a signed DNS-based model, we'd do this within the DNS framework. I.e. registrars, when creating a domain, would also create a certificate for the domain name created and pass that on to the new owner, who can now sign for sub-domains as needed. When presented with www.sub.example.com, we have "www" signed by "sub" signed by "example" signed by one of the registrars for ".com".Some of these concepts will require a re-thinking of the way we approach authenticated online identities. We need to stop placing so much importance on online identifiers (like domain names and e-mail addresses) and start paying attention to who is making those assertions. I can sign an assertion stating that my e-mail address is 'joe@example.com', but unless that's really my e-mail address, it's not going to do anyone a whole lot of good. If I go around forging e-mails from joe@example.com and including that signed assertion, everyone should be able to take one look at that and say, "Who the hell is this guy claiming to be joe@example.com?". Only the guy with the certificate stating the assertion that he is "joe", signed by "example", signed by a valid registrar for ".com" would be able to say that with any authority.
A lot of this can be done today with signed/encrypted XML, provided we have a common framework to start sharing the assertions.
-Frums
How is a pop-up a big fuss? Also most browsers allow you to permentantly accept the certificate as valid, don't they?
-Bill
SlashSig Karma: Excellent (mostly affected by moderatio
What about governments providing a non-profit cert service? Sure, there is the typical caveat of having to "trust" the government...but how much do you really "trust" Verisign anyway? Governments already certify physical documents...why not electronic ones? You could just get a cert from the government covering the region you operate in (ok, I know on the net this can be worldwide)...from city, to state, to regional, to national, or maybe even international. This might also have the effect of localizing the trust - perhaps as a consumer you don't trust a cert generated by some middle of nowhere town or province...
It's 10 PM. Do you know if you're un-American?
Interesting about mozilla determining the trustworthiness of a CA by financial stability, one would hope that would be irrelevant and they would instead be mindful of the verification behind the CA more than the financial status of what it stands behind. What kind of contract is it they want? If they require money to distribute a key, it is an interesting avenue of funding, though I wouldn't think it to be very useful... All said and done, if this works I hope the validation scheme proves to be quite reliable and opens up trusted certificates to a whole new class. I personally administrate two CAs and am glad that clients are typically a few businesses rather than end-consumers, else we would have to run to a CA with an unfair chunk of change...
XML is like violence. If it doesn't solve the problem, use more.
The average user becoming used to ignoring security warning is a bad thing.
Part of the trust involved isn't just that I trust the name I see on the site, it's that I really am talking to to who I think I am. Remember, I can create a self signed certificate for www.abcd.com just as easy as the real owner of www.abcd.com. All I need to do then is hijack his DNS (or get my IP address with his name in your hosts file) and you're talking to me and think you're talking to him. And because we're both using self signed certificates we'd both look as real.
That's why the third party is important.
If you have an existing relationship with the people accessing the site (ie you have a channel whereby they can verify the cert once and don't become used to ignoring warnings) this isn't a problem.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
I can see the usefulness of the expiration and the CA signer field quite easily. Say you were in charge of authenticating these certificates and you were expected to be reliable and not have clients easily be faked. The lowest common denominator becomes the customer. If the customer has that certificate private key leaked, it becomes useless. This can happen without the company knowing, so having the certificate expire is useful in protecting the signee from themselves. Not something they should have to pay for, but the practicality is there. I personally don't see how the CA signer field in any way relates to profit. Ok, so there is the issue of branding, a certificate by Thawte *looks* more reputable than one signed by a small party, but it is a field rarely consulted if it ships with the browsers. The CA Signer field is somewhat critical with independent CAs, where the name does show up. Perhaps only a token, but still..
XML is like violence. If it doesn't solve the problem, use more.
Its soooo quick (10 minutes) and soooo easy, and it only costs $120 (last I checked). Doesent even need a DUNS number!!! I love it! No more Verisign for me...
(no i dont work for them -- haha)
1) Almost every known root CA targets businesses as their primary customers. The prevailing mentality seems to be that if you want to secure your HTTP server's connections to members of the general public, you must be running some sort of business. Their cost per certificate is nothing; you are paying them not for the certificate itself, but for a certification of your trustworthiness as a business.
But what if I'm offering a free service, which nonetheless requires that my users have absolute trust in their browsing security? What if I'm running a nonprofit organization? If the CAs were truly interested in security, they would offer a low-cost alternative for people who are offering free services, and perhaps a free certificate for non-profit organizations.
You may point out that I can now get a cheap certificate for $50. While this is true, the low price of certificates these days is the result of market pressure. These guys aren't lowering their prices out of the goodness of their hearts, or to help Joe Q. Webmaster who wants a secure website. They're doing it only in response to competition.
2) 'Wildcard' certificates cost an absurd amount of money, usually $500 or more.
Excuse me? The entire premise of the certification, is that Thawte (or VeriSign, or whoever) is certifying my trustworthiness as an organization. As such, it shouldn't matter whether I have one, ten or a hundred DNS names associated with my website and with my organization. By forcing you to buy separate certificates for your web server's DNS name, your mail server's DNS name, your LDAP server's DNS name and others, they are extracting even more money from your wallet. Even if all my services are hosted on the same machine, I must pay hundreds of dollars extra for the privilege of giving them separate aliases. The only other alternative is to host all of my services on one machine, under one DNS name. Thank you so much, VeriSign, for sticking your nose into my system administration.
And, finally,
3) VeriSign, the biggest fish in the pond, has demonstrated on more than one occasion that it is in fact not trustworthy.
Remember the incident involving a falsely-issued code signing certificate for Microsoft? That's right! This supposed paragon of trustworthiness gave some unknown cracker free reign to masquerade as the largest software company in the world. If they're that damned vulnerable to simple social engineering...then why did I pay them $200 or more, again? What exactly were they certifying?
From the start, the entire digital certificate business has been about politics and moneymaking, nothing more. It's a pity that we're forced to live with it.
Maybe it is as much of a scam as we think - otherwise, why did Verisign issue "two certificates to an individual fraudulently claiming to be an employee of Microsoft Corporation"? (CERT Advisory CA-2001-04)
Entrust tried and failed to sell PKI to any one. Until 2000 PKI was Entrust's primary (only) focus. Unfortunately PKI is a solution looking for a problem. There are other problems as well. (Link curtosey of the July 15 2002 Cryptogram)
It is too bad really. Where PKI works, it works well. MS's Passport and Sun's thing are really PKIs waiting to happen.
simply code up an activeX control that appends the following to the client's c:/windows/system32/drivers/etc/hosts file:
ca.verisign.com <your.openssl.server>
There aint no pancake so thin it doesn't have two sides.
Er, um, you can. It's trivial to be a certificate authority. You simply need to read a couple of HOWTOs and understand how X.509 certificates work. At MIT for example, we are our own CA. The MIT CA signs all other certifiates, such as certificates for machines that offer secure services, or client certificates for users to authenticate themselves for confidential services. Sure, your browser will claim that it won't recognize the certificate authority. But go ahead and download the root certificate, and tell Netscape you want to accept that certificate authority to certify "Internet sites", and you're all set. You only have to do that _once_. Ever. Just make sure that all your server certificates are signed by the certificate authority.
At MIT we get around the "accepting the certificate authority" problem by re-distributing Netscape with our CA alrady in the database. If your organization isn't big enough for this, then just hand the customers printed instructions on how to do it. Tell them by doing this, you're saving them money, with less costs to pass on.
Commercial Certificate Authorities mean jack shit. All they "certify" is "Joe Schmoe paid me $400, so I will now say that he is who he claims to be." Big fscking deal. Who exactly are they to claim that, anyway? Do they have access to Joe's birth certificate? His passport? His social security record? I had to provide more documentation to get a Massachusetts Drivers License than I did to get a certificate from Verisign. Once the general public realizes this, Verisign will need to find a new source of revenue. I envision a future when certificate authorities can be obtained for a nominal processing free ($30) provided the requestor provides proof of identity (or corporate identity).
There is no sig, there is only Zuul.
Our users are easily alarmed, so we need to use a certificate from CA that is fully trusted by all of the common browsers. This pretty much limits you to Verisign/Thawte. If you expect that most users will have mostly upgraded to more modern browsers, then your available choices increase dramatically.
I am currently considering InstantSSL... so far it's taken two days, and no signed certificate, but the price (free trial, $49/year) is right.
I do not deploy Linux. Ever.
Yes, and this is just a preview of the next economic layer that is going to be laid on top of the Internet with the arrival of Palladium. What do you suppose you will have to do to get your content enabled so everybody's PC will be allowed to open it? It's not just a scam, it's maybe the ultimate scam. Inflict the publishing industry's business model on the Internet by taking control of all the hardware connected to it.
These bastards are pure evil.
They've also done some innovative technology, but their basic raison d'etre was to sell certs for a low price, since the cost was also low.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
For internal use only, there is no reason you can't be your own CA, as long as you prepare a standard client load for all of your internal users. SSL is no less secure, all the cert is used for is negotiating a session key anyway.
If you're going to enroll for more than 30 or so SSL certificates a year, you have a couple of alternatives to keep costs down. You can run a RA, which means you register the certs and a trusted CA signs them (VeriSign operates under this model), or you can get a subordinate CA that is signed by a trusted CA (RSA bought Xcert so they could offer this service).
The first company to offer a tool to let you manage your own CA was Netscape, which became iPlanet, and was bought by Sun. Their documentation is great, read this explanation of the benefits of a Self-Signed Root Versus Subordinate CA.
RSA writes very good docs too, but they're new to the CA business, and I believe the way their KCA product is positioned and pricing model will change. They are mostly interested in customers who use a lot of certs, for now.
This whole thread begs the question, how does one become a Certificate Authority. Someone started it and others are available if you look at the CA's in your browser prefs. Couldn't a company be their own CA then?
-- DuckWing
I recently had the same question you do, namely I've got a small site doing a limited amount of business but I still need to accept credit cards and use SSL. Verisign? No way in hell. It'd take me two months to make their fee back in profits. No thank you.
After searching around a bit I found a site called InstantSSL run by an outfit called Comodo. They offer a 1 year 128-bit cert for $49, and you can even try it out for 30 days free of charge. I did, and it works well enough that I haven't had any complaints.
In the end they will lay their freedom at our feet and say to us, Make us your slaves, but feed us. - Fyodor Dostoyevsky
There is another drawback to becoming your own CA that is much more serious, though. I, as a web user, have no real problem accepting a self-signed certificate for an individual website or two. I'm very very hesitant, though, to accept Joe Schmoe as a CA, as this means I have given him the ability to, for instance, authorize whatever certificate he wants as a valid certificate for my bank's website. This is not cool with me. When I'm sending sensitive data over SSL to my bank (and others), I need to know (as much as possible) that the party on the other end of the transaction is who they say they are. My browser (Mozilla) doesn't offer any way to limit the scope of a CA's power at finer granularity beyond "this certificate can identify web sites."
Almost instant (like 10 minute) issuance.
Trusted by 99% or so of in-use browsers (IE>=5.0, Netscape>=4.x, AOL>=5, Opera>=5).
Works great. Highly recommended.
It's also nice to be able to set up multiple hosts or hostnames with certificates. It's truly a one-stop shop.
Of course, the security of the situation is similar to SSH - the first time you connect to an SSH server (or in this case, when the users click on the link to load the CA certificate), they don't have any guarantee that they're not being misled by a monkey-in-the-middle. That, for the most part, is the only thing the $x00 / year and/or the scary browser warnings really buy you.
My site doesn't do any e-commerce, but I do have some users who use Squirrelmail over HTTPS with such a setup. I've gotten no complaints from them about having to add the CA cert. And when I go visit someone else's house, it's sort of second nature for me to add the CA cert to their browser so that when I visit in the future I won't have to do it again.
You might need a certificate signed by a well known CA for your connections from the internet, but for all your backend server you can create your own CA. This will enable you to use a full strenght 1024/128 bit sll for nothing. There is a project called tinyca which enables you to create and signed certificates with your inhouse CA. So you create a CA for your company and add the CA to all your backend server. Once this is done, any certificate signed by your CA will be valid and fully secured.
I have tested it for Apache and Weblogic and Websphere and they work very well.
The idea is that this is the thing the users are going to have to all import into their browsers. You don't want to make them do it more than once. But the whole reason keys expire is that with concerted effort over time they can be factored. So you need to make the key length proportional to the expiration period in at least an attempt to insure that the key will remain secure over its lifespan.
The server cert should have a much smaller key, say a kilobit, because it's used a lot more than the CA cert (validating a server cert will be "hard" because its signed by a 16 kilobit key, but once it's done, the certificate is known-good as long as it remains valid), but because of that it should expire anually. But since you have a long-lived CA cert key, the users won't have to do anything when you do replace the server cert.
Of course, all of this is tempered by how paranoid you need (or want) to be.
Remember, I can create a self signed certificate for www.abcd.com just as easy as the real owner of www.abcd.com.
Right. And you can get a real CA signed certificate from many CAs for abcd.com, too, with about (or as little) deception as hijacking DNS if you're willing to do a little Jim Rockford-style deception.
I think the point is that it's trust -- just because a third party is *appearing* to vouch for the authenticity of abcd.com doesn't mean something creepy hasn't happened -- but you have to *trust* that everything's OK. It's like seeing the BBB sticker in a window. Doesn't mean they're not going to rip you off...
Rackshack was selling Geotrust certs for $29. Had this story been posted a day or two earlier you could have gotten in on it :). They seem to be selling them now for $49, which is still *much* better than you'll find from say Thawte/Verisign. They've worked in every browser I tried, though I believe I just saw someone say they don't work in Opera. Oh well, small price to pay to save $120+ on a cert.
Game... blouses.
I do now notice that Thawte seems to have become a Verisign company. Also GTE Cybertrusts page http://www.cybertrust.gte.com/ seems too barebones for a commercial entity. Seems like verisign is the only choice remaining when it comes to full compatiblity?
Of those to whom much is given, much is required.
Of course, you can feel jealous about someone who can get paid $100 for 2 minutes work (although by the time the keysmith gets to you and gets back after, it probably translates into a better hourly rate), but if that's the going rate, then it's fair. And if it's less than replacing the broken window, then it's worthwhile, as you already said.
The fact that it takes little work to create a key does not matter to anything except your level of envy. It adds a crapload of value, and costs pocket change compared to all the other costs of running a business.
You can have a lot of fun speculating about the price you'd like to pay. But that's not the economic reality, just like I'd like my car not to cost me £20k+ because I live in the UK, not in Europe (where it would be 16k or so).
As long as it adds greater value than it costs, many people will keep paying $400, and Verisign will keep charging it, especially if they've got another brand by which they can access the market of people who won't pay it.
(And yes, the $401 income I mentioned was a silly sum. Call it $440, 10% RoI (pretty good in most cases) and move on.)
The only thing you can accurately describe as "Scotch" is a sticky tape made by 3M. And it's
[Ranting, flame if you want... Corrections and thoughts would be most appreciated ;)]
:p
I know you're paying to prove you say who you are, but what's the big deal here anyways? To me, certs are more about encryption than a form of digital ID.
The 'Certificate Authority' is just another scam to monopolize, to a certain extent, encrypted digital transfer of data. If my cert is OpenSSL with myself as the signing authority, the cert is no less or more secure than an 'official' certificate. And even if the site/program is signed by authority, that does not mean you are not being cheated in some way by the issuer.
Blablah, I call for a grass-roots movement demanding the power to self-sign code and sites etc... Who's with me??!?
-- iie1195
I would be very hesitant to add you, someone I do not know or have a particular reason to trust, as a CA. I wouldn't mind accepting your self-signed certificate to do an SSL transaction with your site, but adding you as a CA is a much bigger security risk. If I do that, you can then sign certificates for any site, including sensitive sites like my bank's. Then you, as a potentially malicious CA, can trick me into accepting false certificates identifying my bank's site.
Thus if you don't want to use a certificate signed by the major CAs, then please just self-sign. I have no problem accepting self-signed certificates, but adding random sites you don't know as CAs is a huge security risk that no one should do (so it'd be nice if you didn't require people to do it in order to visit your site).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
People who run businesses are entitled to target any subset of potential customers they choose. Usually this means the people most willing to spend money will get the most attention.
Correct. But when the businesses are trying to establish themselves as providers of an essential service, it is their responsibility to make the service available in some form to all parties, and not just to those willing to pay through the nose.
There're always self-signed certs, true. But some browsers will not accept self-signed certs. VeriSign paint hemselves as providers of critical infrastructure, and people believe them. At my workplace our browsers are configured not to accept certificates without a root CA signature, and we're not allowed to change the list of trusted root CAs. As a result, I can't check my email, visit the secure areas of my website, or easily get at the files on my PC. That's really what pisses me off. Perhaps I went overboard, blaming everybody and his mother for my personal security woes. But I think we agree that a privatized certification system is a terrible idea.
An end-entity certificate certifies that you are who you say you are, not that you are trustworthy.
Sorry, I misspoke. That's what I meant to say, but it was the end of a long workday. If you look at the remark in the context of the paragraph that follows it, you'll see my point: I am who I say I am, regardless of my hostname. "mail", "www", "ldap", "ftp" and "games" are all part of the xeger.net organization, and I see no good reason to pay VeriSign $200 for each of them. I should be able to partition my namespace however I choose.
Politics and moneymaking are a legitimate part of society.
That they are. But the browser vendors are treating this rash of moneymaking politickers as some sort of authority, in which we're supposed to place our absolute trust. They're not. IANA is an authority; VeriSign is a glorified notary public. Want to form an impartial, not-for-profit CA? Fine. But let's see you persuade Microsoft to distribute your public key with MSIE. Without the support of an extant governing body, or a whole lot of cash, you won't get very far.
Accept them and get busy making things better.
To that I can only say...after you, good sir. =)
OpenSSL has everything you need to run your own CA. If you need some more docs than those that come with OpenSSL, there are loads out there, including these written by me. I run a CA using OpenSSL, and it's great. Does everything I need. All the internal machines trust the CA, and those external people who need to have also set up their browsers to trust it, so all is fine.
This post will enter the public domain 70 years after my death, unless Disney buys another extension.
My company has a web presence such we feel that it is in our best interest to use a big gun, such as Verisign, to issue certs even though we know we are getting the shaft. Regardless of whether or not Verisign is doing their job or not asside, Microsoft and Netscape browsers trust them blindly and most of the Internet community doesn't know any better.
... it's in there.)
Besides, the biggest issue I have is not the $800/year we spend for the 128-bit certificate, but the fact I have to buy one for each server, even if they use the same name (read the license agreement
Since customers are required to sign up for our service, why can't we buy one Verisign certificate just for the sign-up server, then require customers to install a new root cert for our company to use our service. In fact, we could make that part of the install process with a 'click here and select OK' message. Most users would blindly click it an go on. Then we could create as many of our own certs for the rest of our servers as we wanted with no cost, and maybe evern 5 or 10 year expirations so we don't have to replace the blasted things every year.
Any thoughts?? I'm sure our marketing department could put together a wonderful page explaining how Verisign trusts us, blah blah blah.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
You could run a proxy that only accepts connections to trusted hosts (your internet appliances). That proxy could itself access the trusted host through SSL, but ignore the warning. The proxy itself would have a valid ssl certificate.
So you'd access URLs like:
http://mysecurehost/mytoaster
http://mysecurehost/mymicrowave
http://mysecurehost/mypenguinnightlight
---
I support spreading santorum
it doesn't look like they're offering an RA or subordinate CA, unfortunately.
You didn't look hard enough. The RA comes bundled with the CA (Oops I mean Security Manager). The CA can be configured to be a subordinate with little trouble during installation.
Stop Continental Drift! Reunite Gondwanaland!
Is it now? Gosh, let's see. We support Mozilla 1.x. We support Netscape 4.x. We support Netscape 6.2.x. We support IE 5.5 and above. It evens supports a version of Lynx. What more do you want? The AOL browser?
There is no sig, there is only Zuul.
Has anyone noticed that all of these stocks trade below $5 a share? In the past, a lack of financial wherewithal has caused many companies to engage in *ahem* less than ethical manners */ahem*. Given that what these guys are selling is trust and given that currently thay have much less to lose by being untrustworthy than they had a few short months ago, why should I trust them any more than Joe Bob's Muffler and Certs Shop?
That is all.
Now, the next step. (a little off-topic but it will be taken someday, mayber sooner that later.) Are you really the guy who owns the device or account that is being used? Devices such as fingerprint and/or retinal scanning or just a card-swiper can (supposedly) add another layer of security. How does one "certify" locally or remotely that someone else is who that someone says he/she is? Remote retension of data by the gov't? Maybe, maybe not. Voice recognition? Then, there is the little problem of securing the stuff that secures the stuff that... (umm...gotta go)
(whatever)
See my reply to someone else's reply, for a clarification of my point #1. I misspoke, but if you look at the remark in the context of the paragraph, you'll see that I'm talking about identity, and not trustworthiness.
Of course, there is an indirect cost associated with issuing a certificate. There's recurring overhead, the cost of the hardware on which the certificate servers reside, legal costs, etc. But the certificate itself is just a handy mathematical abstraction, and I'm damned sure that the cost to VeriSign per certificate they issue is a damned sight less than $400. If it isn't, that's their problem and they need to seriously reconsider their business practices.
This is one of the weak points of public-key encryption; for it to be effective, you need some way to verify that the person whose public key you're using to encrypt data is really the person who you want to send the data to. With SSH this is typically done by keeping a list of fingerprints of the public keys of known hosts; the first time you connect to a host you're prompted with a warning that it's an unknown host, and asked if you want to add it to your known hosts list. This is a point of failure -- if the first time it turns out to actually be an imposter, you'll have added the imposter's fingerprint.
The SSL key-signing mechanism is intended to avoid this problem by having a company like Verisign that is supposed to be trustworthy. Thus you only need to get Verisign's key in a trusted manner (usually by being distributed with a browser), and then you can verify that all the other keys you get aren't fakes by checking to see if they've been properly signed by Verisign. The only points of failure here are: 1) the possibility of getting a fake Verisign key; and 2) the possibility of Verisign messing up and certifying a fake key. Generally 1) is not a significant problem; 2) may be. Since browsers generally treat all CAs the same, the strength against weakness 2) is only as good as the reliability of the least-reliable of the CAs. This is another reason why adding an unknown CA is a bad idea -- it basically makes the signing system completely useless. If you're going to do that, you might as well just tweak your browser's options to stop warning about unsigned keys altogether, since keys being signed by untrusted random parties isn't any better than them not being signed at all.
It's a fairly difficult problem to solve successfully. With PGP email one method being explored is a "web of trust," where you sign the keys of people you can vouch for (i.e. you known them personally so you can verify that they are who they say they are). This is difficult to scale though, since it only takes a handful of otherwise-trustworthy people to irresponsibly sign keys without properly verifying their authenticity to make the whole system useless (similar to the way it only takes one bad CA to make the system useless, only here the number of points of failure is much higher).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Verisign only attempts to do one of them -- verify that the site is who they say they are. Thus when you see "certificate from Amazon.com, signed by Verisign," if Verisign has done their job properly you can indeed be sure that this is Amazon.com's genuine certificate and not a forged one created by a malicious third party intercepting your communications (perhaps at the router level).
Now you're entirely correct that even if that's done, there's the additional question of "okay, so this really is Amazon.com; but is Amazon.com trustworthy?" I don't think the CA system is intended to answer that question; it's merely intended to let you know for certain that your communications aren't being intercepted. Furthermore, I don't think it would need to. The encryption system only needs to verify the authenticity of the other party; to determine the trusthworthiness of the other party, things liek resellerratings.com (expanded perhaps to other issues such as privacy and security) can suffice, since the ratings/review system doesn't need to be built into the encryption infrastructure.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Well, that e-mail appears to have worked :-D
Now there's a direct link (not an affiliate one) and no page. Hee hee hee...
Sorry, I didn't mean to point anyone in the wrong direction, I forgot the exact name and mistyped it in my browser, and it looked correct. I should have checked better. My apoligies to all.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.