Looking for static IP host.

January 30, 2010 9:33 PM

Looking for web hosting that offers a dedicated IP for, in this case, SSL.

I already have a site, but I want to add a "members only" section, and I want it to be over https. I'm currently using a webhost that only offers dynamic IP addresses and now find myself in need of a static IP for the secure section. I don't want to host this myself; I just want to FTP into a host's server.

I'd much prefer to simply redirect something like members.mysite.com to this new IP rather than moving entirely to a new host. I love my current service.

(Bonus: How do SSL certificates work? What do they cost? Any recs?)

As always, thanks, MeFi!

posted by reductiondesign to computers & internet (4 answers total)

dreamhost.com - they also have referral based promotions, you can me-mail me.

I've used them since 2004, they offer static IPs, SSL, and more. They can also handle all of the certificate whackydoodles.
posted by tilde at 9:41 PM on January 30, 2010

Blue Host. Dedicated IP and SSL. Around $75 pa for both.
posted by Kerasia at 10:51 PM on January 30, 2010

I strongly recommend that you SFTP instead of plain FTP.

(And I use Linode, but they're probably overkill for what you want, but if you go with them, MeMail me and I'll send you a referral link that will get me $10.)
posted by Brian Puccio at 6:41 AM on January 31, 2010

SSL certificates are based on public key encryption and chain of trust.

So first, Public Key Crypto. Some smart mathematicians figured out a system that lets you encrypt something with one key and decrypt it with a different, but related key. This is called a "key pair." The algorithm doesn't care which way yo use them, but in practice one is kept private (the "private key") and the other (the "public key") is made public somehow, via email, the web, key distribution parties or some trusted third party. When you want to send something to a specific person, you encrypt it with their public key and then only the holder of the private key can decrypt it. There's more encryption details under the hood to minimize risk, but this general system of encrypting with a public key and decrypting with a related private key establishes private communications.

The trouble though, is that you have no way of knowing someone's public key. SSL lets websites distribute their public key themselves. But new visitors have no way of knowing whether that public key is related to the official private key or a new one a hacker is using for fraud. It's a bit like going to a conference and handing out business cards with your name, website and public key on it, with one major difference. Anyone can fake a business card, so we use trusted third parties to place their stamp of approval on public keys.

This is called a "signature", and uses the inverse of the first encryption scheme. By encrypting something with a private key, anyone who holds the public key can verify it was encrypted by someone who knows the private key (it comes out as garbage otherwise). So now we just need to know a few public keys rather than the whole internet; all browsers come with a set of "root" certificates for companies like Verisign. This system authenticates your public key to the browser.

A good SSL certificate carries an identity for which it is valid (a domain and related info like location and name), a range of dates during which it is valid, a public key, the identity of who vouches for it, and their verifiable signature of all the other data. You can use firefox to take a look at your bank's certificate and all these details should be visible in the XML details view.

So now that I've thoroughly confused you, let me present the sequence of events in SSL:
1. Visitor attempts to start an SSL transaction, and downloads your SSL certificate.
2. Visitor's browser inspects for flaws like expired certs or certs for a different domain.
3. Visitor's browser determines who signed your SSL certificate (ie Verisign).
4. Visitor checks that the signature Verisign created checks out by decrypting it with it's copy of verisign's public key.
5. Visitor now trusts your public key, and sends sensitive data (passwords, credit card numbers) to your website encrypted with the public key it downloaded from you.
5a. In particular, it sends an encryption key your webserver can use to encrypt data sent to the visitor.
posted by pwnguin at 3:21 PM on January 31, 2010