Cheap SSL Certificates for Small Websites? 445
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?"
It is a scam (Score:5, Interesting)
"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.
ssl webhost won't work? (Score:2, Interesting)
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.
Re:Self-sign (Score:1, Interesting)
SSL worthwhile? (Score:1, Interesting)
If people accept any certificate because don't know what one is, and just want their effing content? If the sites using SSL are not keeping current versions, that is, are vulnerable to exploits anyways?
Re:It's not as much of a scam as you think. (Score:3, Interesting)
That would be a fine argument if they actually do any significant verification. My impression is that they don't.
I think it's foolish to rely on VeriSign or anybody else to guarantee that the company on the other end is who they claim they are. And you don't need that anyway--you don't get that protection for mail order either, and, besides, lots of people can get your credit card number without all the hassle of setting up a web site.
What matters ultimately is the money trail: not VeriSign, but MasterCard, needs to know where your money went and get it back for you. That's their responsibility as credit card companies.
Re:It is a scam (Score:3, Interesting)
I think everyone is realizing it, but doing nothing about it. It is one of those sticky technologies that can be used for good and evil. There is and always will be good uses for this technology like the way it is being used today, but on the other hand, forcing certificates on those that just want secure internet connections seems rather arguable to me, but since it is in spec there isn't much for us to do until I take a flame thrower to all the anal-monopolistic companies.
Just to clearify the DRM == cert part, I think the nature of DRM forces anyone who implements that security mechanism to use certs.
The real problem when internet connected devices become more pleantiful, and central authorities like Microsoft and Verisign start signing everything under the sun. Running a program on Windows 2004:
#bash
- Error 31337 -
Problem: This program has not been signed by an
application trusted provider.
Solution: Bend over and take it like the
mule that you are
-
#Format C:
- Error 31337 -
Problem: This program has not been signed by an
application trusted provider.
Solution: You can never escape us! MWAHAHAHAHA!
-
Re:Free root cert project (Score:4, Interesting)
Nice idea. Unfortunately, the MD5 fingerprint on the root certificate doesn't match what the webpage claims it should be. This leads to doubts...
I suspect what happened is that they issued a new certificate on September 15th, and forgot to update the webpage. But that kind of sloppiness is not reassuring, and the fact that nobody has fixed it in 17 days indicates that it's probably not very widely used. (And yes, I e-mailed the webmaster about the problem.)
Re:Is it any good if most browsers reject it? (Score:1, Interesting)
Certs prevent Man-in-the-middle attacks (Score:3, Interesting)
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
Re:InstantSSL (Score:2, Interesting)
I started an online store on my site in September 2001. At the time I couldn't find anything cheaper than Thawte. I went through all the paperwork hassles, process, etc. and eventually got one--though it was issued to me personally because they had weird requirements to prove my business existed (even though it was listed in DUNS, has been in business since 1993, etc.).
Last month it was time to renew. I wasn't looking forward to it but I figured I'd just be able to pay the bucks and be done. But NO, Thawte presented me with a whole new set of documentation that I had to provide. Never mind it was just to prove that I exist personally since the certificate was issued to me as a person, not the company. Never mind we had already gone through this the year before and nothing in the certificate was changing.
I got supremely pissed off and did some searching. Found InstantSSL by Comodo. The standard cert is $49/year with discounts available if you purchase more than 1 year at a time.
A little skeptically I signed up with them. I had my certificate the same day with no need to provide paperwork because their system was able to establish the existence of my company. And it was registered to my company (as it should be), not to me personally. Pleased with their service I purchased another certificate for another site I'd been meaning to get secured--since they already had certified my company that cert took about 2 hours to reecive.
I gave Thawte the 1-finger salute. I asked for a refund for the renewal I had initiated and purchased 2 years with InstantSSL for less than I was going to pay Thawte for 1 year. This is even better since Thawte is owned by Verisign, so by going to InstantSSL I effectively am free of Verisign. Always good.
I highly recommend InstantSSL. It's the Godaddy of SSL certs. :)
Why not to trust a CA (Score:3, Interesting)
Having established my experience with these entities, I can tell you that CA trust is worthless. Why? Because there are many CA's, and each one of them dilutes the trust pool instead of strengthening it. They each claim to be an "authority", and the browser trusts that they are. Let me ask you this rhetorical question: If you're dealing with 6 bosses, instead of 1, does that make your bosses individually stronger or weaker as authority figures? I would say it makes them weaker, because you don't know which one to really trust.
The same goes for CA's. Each of them has a different method for establishing trust, but the trust from any one of them produces the same result: specifically, the browser stops warning the user about your website. As soon as that warning message goes away, your users have stopped thinking about your certificate entirely. If they know anything about certificates at all, they probably think you've gone through a rigorous identification process to get a certificate trusted by their browser. Most likely, you have.
But it only takes one bad CA to ruin it all. One CA that checks only the email address; one CA that doesn't do a follow-up phone call on every single customer, and ALL CA's trust is broken, because now the bad certificates are out there hiding with the good ones, hidden behind the absence of that nasty warning message simply because that bad CA was trusted by your browser. It comes down to: do you trust your browser's choice of Root Certificates? Do you even know how to answer that question?
You shouldn't, because there are already lazy/cheap CA's giving out easy certificates and their Root Certificates are in your browser, just like everyone else's.
Paying for a cert signed by a "real" CA is a fool's game. Don't play it. Let their broken business model die.
Be your _own_ CA. Why pay anyone? (Score:5, Interesting)
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).
Becoming your own CA is a bad idea (Score:3, Interesting)
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."
Be your own CA (Score:2, Interesting)
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.
Make the CA key much bigger (Score:3, Interesting)
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.
Re:It is a scam (Score:3, Interesting)
Right. That's a point I forgot to make in a previous post. Most of what I know about certificates comes from research I did in an attempt to offer users of my services a secure connection. Turns out the only way to enable https connections is by using certificates. Of course, I didn't want to fork out all this money just for test-driving the system, so I went for self-signed certs. This popped up a security warning whenever the secure connection was requested (unless disabled after the first time), in effect reducing people's sense of security instead of increasing it.
I see the point in using certificates. It's an excellent way to ensure the entity you're communicating with is in fact the entity you think you're communicating with (although, of course, CAs are run by people, and people are flawed). I see why certificates are expensive; there is a lot of work in deciding whether the requester is thrustworthy or not. Certificates are not my problem. My problem is: Why do we need them if all we want is encrypting communications?
US? (Score:1, Interesting)
Rock Solid SSL ;o) (Score:1, Interesting)
www.rocksolidssl.com [rocksolidssl.com] will launch in about 2 weeks!
There will be a 10% discount for the first week to get things rolling, but just for slashdot readers, I will offer 15% if you put the word "slashdot" in the discount field on the payment form, in the first week.
Can't say fairer than that
Have fun,
Jamie Burns.
just an idea (Score:2, Interesting)
So you'd access URLs like:
http://mysecurehost/mytoaster
http://mysecurehost/mymicrowave
http://mysecurehost/mypenguinnightlight