Certify me. Or at least the site.
October 20, 2007 2:12 PM Subscribe
I need a cheap, trustworthy, reliable certificate for a web application for a non-profit, and a walkthrough on how SSL is set up and used.
I'm in process of wrapping up a web app (read: much further away than I think) to prepare it for transfer off my local machine to the webhost, and it's only just now occurred to me that I need a certificate to have encrypted connections.
Currently none of the pages are accessible without logging in, and the passwords are both hashed and salted, but all that's for naught if the username/password pair is sent in plaintext. And, after thinking about it a bit, I decided I wanted all traffic to and from the site to be encrypted. (It's a database of local volunteers: real names, mailing addresses, email addresses, phone numbers, etc.)
I've looked through these posts and found this thread, this thread, and this comment useful for finding cheap certificate sellers. From those discussions I'm leaning towards GoDaddy for the certificate, though I'm wondering if there's anything more than the controversies listed at Wikipedia that I need to take into account in dealing with them.
Also I'd need a for-dummies level explanation of how certificates are actually set up and used: are there any particularly good books, sites, threads, other resources that will walk me through the installation process and help me set up the pages so that they're encrypted? I've never done this before, so the simpler/more painfully clear the explanation, the better.
Finally, am I right in thinking that if I buy the certificate for the site, then there's no way to test it on my local server? (And so it would be best to put up the database with fake data in some test location, at least until I've got the SSL working properly? I imagine that, as with most of the rest of this project, it isn't going to be a quick and easy task.)
I'm in process of wrapping up a web app (read: much further away than I think) to prepare it for transfer off my local machine to the webhost, and it's only just now occurred to me that I need a certificate to have encrypted connections.
Currently none of the pages are accessible without logging in, and the passwords are both hashed and salted, but all that's for naught if the username/password pair is sent in plaintext. And, after thinking about it a bit, I decided I wanted all traffic to and from the site to be encrypted. (It's a database of local volunteers: real names, mailing addresses, email addresses, phone numbers, etc.)
I've looked through these posts and found this thread, this thread, and this comment useful for finding cheap certificate sellers. From those discussions I'm leaning towards GoDaddy for the certificate, though I'm wondering if there's anything more than the controversies listed at Wikipedia that I need to take into account in dealing with them.
Also I'd need a for-dummies level explanation of how certificates are actually set up and used: are there any particularly good books, sites, threads, other resources that will walk me through the installation process and help me set up the pages so that they're encrypted? I've never done this before, so the simpler/more painfully clear the explanation, the better.
Finally, am I right in thinking that if I buy the certificate for the site, then there's no way to test it on my local server? (And so it would be best to put up the database with fake data in some test location, at least until I've got the SSL working properly? I imagine that, as with most of the rest of this project, it isn't going to be a quick and easy task.)
Finally, am I right in thinking that if I buy the certificate for the site, then there's no way to test it on my local server?
I haven't bought a cert, but I have set up SSL with a self-signed one. My understanding is that if you install your certificate on your local server, you'll get a domain mismatch warning when you view the site, but you'll still be able to view the cert in your browser and confirm that the information is correct, and if you choose to accept it despite the mismatch, you can confirm that the SSL is working and not causing any problems with your app, etc.
As to the how-to part of your question, it would probably help to know what kind of setup you are using. Apache? IIS?
posted by enn at 3:47 PM on October 20, 2007
I haven't bought a cert, but I have set up SSL with a self-signed one. My understanding is that if you install your certificate on your local server, you'll get a domain mismatch warning when you view the site, but you'll still be able to view the cert in your browser and confirm that the information is correct, and if you choose to accept it despite the mismatch, you can confirm that the SSL is working and not causing any problems with your app, etc.
As to the how-to part of your question, it would probably help to know what kind of setup you are using. Apache? IIS?
posted by enn at 3:47 PM on October 20, 2007
Response by poster: Thanks for the suggestion, Roger Dodger. I didn't know about that program.
Sorry, enn. I'm using Apache, PHP, and MySQL.
posted by Tuwa at 4:06 PM on October 20, 2007
Sorry, enn. I'm using Apache, PHP, and MySQL.
posted by Tuwa at 4:06 PM on October 20, 2007
I use CAcert for SSL certificates that are both free _and_ whose root certificates are included in most major browsers. Their certs are easy to get, and they have good documentation about how to set them up under various web server environments. Once you have Apache configured with your certificate, encrypting traffic is as simple as using https:// instead of http:// to access your site. Make sure your HTML uses https:// in all its links, and maybe write some javascript for each page to make sure users are always loading the encrypted URL, and you'll be set. This is probably your simplest option.
posted by autojack at 5:03 PM on October 20, 2007
posted by autojack at 5:03 PM on October 20, 2007
I use CAcert for my personal sites. If I was creating an online store or something where strangers are giving me info like credit cards, I'd shell the cash for a certificate signed by one of the large CA's. Nothing gets a grandma more scared about giving up her Discover card number than a big IE security warning about unsigned certificates.
CAcert's root certificates are not included in most major browsers. This Mozilla bug shows they did not meet the audit criteria for inclusion in Mozilla/Firefox. Some free/open source operating systems have included it as part of their distribution of web browsers (FreeBSD), others offer it as an optional package (Gentoo). Fedora, for example, deferred to the Mozilla organisation on when it would be included, saying it belongs in the browser upstream. You will have to manually install the CA root certificate to match the behaviour you see, for example, if you open Firefox on a Mac and go to check out at Amazon.
posted by jeversol at 6:11 PM on October 20, 2007
CAcert's root certificates are not included in most major browsers. This Mozilla bug shows they did not meet the audit criteria for inclusion in Mozilla/Firefox. Some free/open source operating systems have included it as part of their distribution of web browsers (FreeBSD), others offer it as an optional package (Gentoo). Fedora, for example, deferred to the Mozilla organisation on when it would be included, saying it belongs in the browser upstream. You will have to manually install the CA root certificate to match the behaviour you see, for example, if you open Firefox on a Mac and go to check out at Amazon.
posted by jeversol at 6:11 PM on October 20, 2007
Best answer: The basic way this works is this: you generate a pair of keys, a public and private key. They correspond with one another, so that anything encrypted with the private key can be decrypted (only) by the public key, and vice versa.
All the certificate providers do the same thing; they have public and private keys just like you do. What they offer, in exchange for money, is to 'sign' your public key with their private key... that is, to generate a hash that says 'this public key belongs to someone that this CA has audited and is who he/she/it claims to be.'
Basically, you send them your public key (only!), they sign it after proving who you are, without ever seeing your private key, and then you re-download your key with the extra signature attached. You then provide clients with the signed public key.
All the clients have the public keys for all the major CAs, so they check that the signature the CA provided was really generated by the CA's private key. Then they know that you're legit, and they encrypt all traffic to you with your public key, which you decrypt with your private key. You encrypt all traffic to them with your private key, which they decrypt with your public key.
There's nothing magic about being a CA (well, other than the excessively painful syntax to manually do key signing in Unix), except that the organizations have convinced the browser makers to include their public key as a trust source. This means that ANY cert signed by that private key will be accepted by the browser as legitimate. This can be a signifcant security risk, so everyone is really paranoid about whose certificates they include.
You can, however, function as your own CA if you wish, or just use a self-signed certificate. Being your own CA is pretty painful; I've been using UNIX a long time and I STILL have to get out my notes every time I need to make or sign a key. (you just would not believe the sheer complexity of the commands involved.) A person has to trust you a lot to accept your CA key into their computer, because you could use your newfound powers for evil. But if you have a bunch of people who trust you, this is a way you could do it for free. (just BE CAREFUL with the key! if it gets out, hackers can do Bad Things to anyone who trusted you.)
If you just use a self-signed key, clients will get an error message saying (correctly) that you're not proven to be who you say you are. If they're willing to accept the key, it just covers that one site; they can usually store it for later, so they don't have to click Accept every single time, but they have to do it at least once. This is less secure, as you're vulnerable to man-in-the-middle attacks, but it will indeed encrypt all the traffic between the two of you, entirely for free. The CA approach lets you install a certificate once on their machines, and then use as many different machine certificates as you want, without any prompting at all.
If you decide you want to pay for a key, to get the higher security along with convenience, you basically generate a public/private key pair, and you make sure they work locally for encrypted traffic. (the self-signed approach). Once you're happy with the key (for testing, be sure not to tell it to remember the key forever, so you can see when the error message stops coming up), you submit the public key to a CA. They prove who you are, sign your key, and you redownload it. You replace the original public key with the new, shiny, signed key, and everything just starts working.
As far as your personal risk level goes, GoDaddy is no more risky to you than any other key signer, because they don't have access to your private key. Even if you hate and distrust them and think they're totally in the government's pocket (which they probably are), it doesn't matter to you, because they have access only to the data that everyone else does, plus, probably your name, address, and whatever other proof of identity they require. As long as you don't consider the required identity papers to be sensitive, any registrar that's included in the major browsers is as good as any other.
posted by Malor at 7:30 PM on October 20, 2007
All the certificate providers do the same thing; they have public and private keys just like you do. What they offer, in exchange for money, is to 'sign' your public key with their private key... that is, to generate a hash that says 'this public key belongs to someone that this CA has audited and is who he/she/it claims to be.'
Basically, you send them your public key (only!), they sign it after proving who you are, without ever seeing your private key, and then you re-download your key with the extra signature attached. You then provide clients with the signed public key.
All the clients have the public keys for all the major CAs, so they check that the signature the CA provided was really generated by the CA's private key. Then they know that you're legit, and they encrypt all traffic to you with your public key, which you decrypt with your private key. You encrypt all traffic to them with your private key, which they decrypt with your public key.
There's nothing magic about being a CA (well, other than the excessively painful syntax to manually do key signing in Unix), except that the organizations have convinced the browser makers to include their public key as a trust source. This means that ANY cert signed by that private key will be accepted by the browser as legitimate. This can be a signifcant security risk, so everyone is really paranoid about whose certificates they include.
You can, however, function as your own CA if you wish, or just use a self-signed certificate. Being your own CA is pretty painful; I've been using UNIX a long time and I STILL have to get out my notes every time I need to make or sign a key. (you just would not believe the sheer complexity of the commands involved.) A person has to trust you a lot to accept your CA key into their computer, because you could use your newfound powers for evil. But if you have a bunch of people who trust you, this is a way you could do it for free. (just BE CAREFUL with the key! if it gets out, hackers can do Bad Things to anyone who trusted you.)
If you just use a self-signed key, clients will get an error message saying (correctly) that you're not proven to be who you say you are. If they're willing to accept the key, it just covers that one site; they can usually store it for later, so they don't have to click Accept every single time, but they have to do it at least once. This is less secure, as you're vulnerable to man-in-the-middle attacks, but it will indeed encrypt all the traffic between the two of you, entirely for free. The CA approach lets you install a certificate once on their machines, and then use as many different machine certificates as you want, without any prompting at all.
If you decide you want to pay for a key, to get the higher security along with convenience, you basically generate a public/private key pair, and you make sure they work locally for encrypted traffic. (the self-signed approach). Once you're happy with the key (for testing, be sure not to tell it to remember the key forever, so you can see when the error message stops coming up), you submit the public key to a CA. They prove who you are, sign your key, and you redownload it. You replace the original public key with the new, shiny, signed key, and everything just starts working.
As far as your personal risk level goes, GoDaddy is no more risky to you than any other key signer, because they don't have access to your private key. Even if you hate and distrust them and think they're totally in the government's pocket (which they probably are), it doesn't matter to you, because they have access only to the data that everyone else does, plus, probably your name, address, and whatever other proof of identity they require. As long as you don't consider the required identity papers to be sensitive, any registrar that's included in the major browsers is as good as any other.
posted by Malor at 7:30 PM on October 20, 2007
Best answer: I think it all depends on what you're doing. If you're producing a site that's intended for a fixed audience (only members of your organization, etc.) then you can probably use a certificate that's either self-signed, or from CACert.
A self-signed certificate will produce an error, and you'll have to inform users not to worry about it, and to approve the certificate for that particular site. (In Firefox I think this is persistent; you can say "trust this certificate to identify this site forever"; in IE you may need to do it every time). I know of a lot of corporate intranet and government intranet sites that use self-signed or internal-CA certificates.
If you use a CACert certificate, then your users will need to go to the CACert.org site and click on the link to download the root certificate and install it, OR do the process above to allow the untrusted certificate to identify your particular site.
If you don't want to do either of those paths (if your site will be accessible to a wide audience and you can't force them to jump through a bunch of hoops), then you'll need to get a real cert from Verisign or possibly Thawte. I think Thawte is cheaper than VS, but it's been a while since I've been through the process.
Actually installing the certificates will vary depending on your web hosting provider. They should provide instructions on how to set up SSL. Unless you have root shell access to the server (meaning you have a virtual host or a full colo'ed box), most of the HOWTOs around the 'net won't help you. They all assume that you have complete access to your server's Apache configuration files and can mess with it and OpenSSL. If you do shared hosting, like 99% of the smalltime-web-site-world, this will not be the case. So give your host a call and ask them what's involved, and get a free test cert from whatever company you plan on using so you can do a dry run with the host and make sure to work the kinks out.
posted by Kadin2048 at 10:37 PM on October 20, 2007
A self-signed certificate will produce an error, and you'll have to inform users not to worry about it, and to approve the certificate for that particular site. (In Firefox I think this is persistent; you can say "trust this certificate to identify this site forever"; in IE you may need to do it every time). I know of a lot of corporate intranet and government intranet sites that use self-signed or internal-CA certificates.
If you use a CACert certificate, then your users will need to go to the CACert.org site and click on the link to download the root certificate and install it, OR do the process above to allow the untrusted certificate to identify your particular site.
If you don't want to do either of those paths (if your site will be accessible to a wide audience and you can't force them to jump through a bunch of hoops), then you'll need to get a real cert from Verisign or possibly Thawte. I think Thawte is cheaper than VS, but it's been a while since I've been through the process.
Actually installing the certificates will vary depending on your web hosting provider. They should provide instructions on how to set up SSL. Unless you have root shell access to the server (meaning you have a virtual host or a full colo'ed box), most of the HOWTOs around the 'net won't help you. They all assume that you have complete access to your server's Apache configuration files and can mess with it and OpenSSL. If you do shared hosting, like 99% of the smalltime-web-site-world, this will not be the case. So give your host a call and ask them what's involved, and get a free test cert from whatever company you plan on using so you can do a dry run with the host and make sure to work the kinks out.
posted by Kadin2048 at 10:37 PM on October 20, 2007
Best answer: I just did this with ipsca. Despite the ghettoness of their site, all went well and my site is encrypted and doesn't throw up any warnings on any browser. RapidSSL is also a decent choice, and they'll save you a step because their certs are not chained. You don't need to drop 6 benjamins on a Thawte certificate, that's for damn sure.
Here's a rough ordering of the steps I had to take, these are probably relatively common across certificate providers:
- Set up the WHOIS information for my domain accurately, with a current email address for me. I had register.com's r.protect so I had to call them to temporarily unprotect the domain.
- Created a Certificate Signing Request (csr) with the *exact same* information as I put in the WHOIS. Both the Common Name and Organization fields were set to the domain name. This process also created a private key which I saved for later.
- Went through ipsca's signup process, entering the exact same information a third time
- Ipsca looked up my email in the WHOIS and sent me some confirmation emails that I had to click through
- Then I paid for the cert. Hella reasonable at $38.
- Then I got an email with my signed certificate in it
- Ipsca has an chained certificate, so I downloaded their cert bundle from this page and added my cert to the end of the file (certs are represented as snippets of text, so you can arrange them like paragraphs in some sort of bizarre short story)
- Installed this file (which now contained three certs, including my own) in my web server along with the private key that I saved from step 2. There are instructions for whatever web server you're rolling.
That's it in a nutshell. Sorry I don't have any links to more detailed explanations, I just figured it out as I was going along. The certificate is inextricably associated with the final domain name, so if you want to do testing for a while you're probably better off going the self-signed route until it's time to go legit.
Don't give money to GoDaddy. They're inexpensive because they have heck of shady business practices. For example, I have a friend who wanted a domain and used GoDaddy to look up whether it was taken or not. Turns out that when you do that, they start squatting on the domain. As far as any other registrar is concerned, that domain has been bought already, so you're then *forced* to buy it from GoDaddy if you want it at all. Kind of a shell game there. I don't know how they could fuck up certificates but I'm sure they could find a way.
posted by breath at 4:07 AM on October 21, 2007
Here's a rough ordering of the steps I had to take, these are probably relatively common across certificate providers:
- Set up the WHOIS information for my domain accurately, with a current email address for me. I had register.com's r.protect so I had to call them to temporarily unprotect the domain.
- Created a Certificate Signing Request (csr) with the *exact same* information as I put in the WHOIS. Both the Common Name and Organization fields were set to the domain name. This process also created a private key which I saved for later.
- Went through ipsca's signup process, entering the exact same information a third time
- Ipsca looked up my email in the WHOIS and sent me some confirmation emails that I had to click through
- Then I paid for the cert. Hella reasonable at $38.
- Then I got an email with my signed certificate in it
- Ipsca has an chained certificate, so I downloaded their cert bundle from this page and added my cert to the end of the file (certs are represented as snippets of text, so you can arrange them like paragraphs in some sort of bizarre short story)
- Installed this file (which now contained three certs, including my own) in my web server along with the private key that I saved from step 2. There are instructions for whatever web server you're rolling.
That's it in a nutshell. Sorry I don't have any links to more detailed explanations, I just figured it out as I was going along. The certificate is inextricably associated with the final domain name, so if you want to do testing for a while you're probably better off going the self-signed route until it's time to go legit.
Don't give money to GoDaddy. They're inexpensive because they have heck of shady business practices. For example, I have a friend who wanted a domain and used GoDaddy to look up whether it was taken or not. Turns out that when you do that, they start squatting on the domain. As far as any other registrar is concerned, that domain has been bought already, so you're then *forced* to buy it from GoDaddy if you want it at all. Kind of a shell game there. I don't know how they could fuck up certificates but I'm sure they could find a way.
posted by breath at 4:07 AM on October 21, 2007
Response by poster: autojack, thanks for the tip on using https:// in all links; I think what I'll do once this is up is try to add a rule to .htaccess to redirect any http:// request against the database to the same https:// address, then the app can handle it from there (honoring it or ignoring it and redirecting the user as appropriate).
jeversol, that's an interesting debate that's sprung up in the Moz forums, and to be honest I'd never thought much about the principles at play: sure, my browser automatically works with certificates from all sorts of sites and I never told it to. It's convenient but I can see how it could be used for evil.
Malor, that's a very useful explanation, thanks. I'd wondered why more people didn't roll their own certs and thought that it must not be as easy as installing a PGP key.
Kadin2048, I'm leaning away from self-signing now just for convenience' sake. It's a small project for a very limited audience, but I may go with a paid certificate just to avoid throwing error messages. But I'll give it a trial run with a test cert first.
breath, thanks for the step-by-step and for the warnings about GoDaddy.com. It's cheering to know that random visitors can make them purchase domain names like queirowqeuriwoqeuroeqwiru.com .
posted by Tuwa at 6:10 AM on October 21, 2007
jeversol, that's an interesting debate that's sprung up in the Moz forums, and to be honest I'd never thought much about the principles at play: sure, my browser automatically works with certificates from all sorts of sites and I never told it to. It's convenient but I can see how it could be used for evil.
Malor, that's a very useful explanation, thanks. I'd wondered why more people didn't roll their own certs and thought that it must not be as easy as installing a PGP key.
Kadin2048, I'm leaning away from self-signing now just for convenience' sake. It's a small project for a very limited audience, but I may go with a paid certificate just to avoid throwing error messages. But I'll give it a trial run with a test cert first.
breath, thanks for the step-by-step and for the warnings about GoDaddy.com. It's cheering to know that random visitors can make them purchase domain names like queirowqeuriwoqeuroeqwiru.com .
posted by Tuwa at 6:10 AM on October 21, 2007
This thread is closed to new comments.
posted by Roger Dodger at 2:38 PM on October 20, 2007