|SSL Certs & Shared Hosting..|
Arrrrggghhh someone help...
| 12:13 am on Jan 7, 2004 (gmt 0)|
I'm trying for the life of me to buy a SSL cert, and it's just not a user friendly process. Nobody seems to be able to answer my questions properly, tried Verisign & thawte.
It's not that hard really, here's the question:
I want to get a 128 bit SSL cert for my server, but before I buy one I need to know if these things will work on a shared server. i have my own IP address, yes, and my own domain name... but do I need a dedicated server to install one?
It's possible that others on my shared server have SSL certs installed, I don't know. Will me buying one for my domain be ok, and can it be installed. Actually I know it can be installed because my hosting provider said they will installed it. But do I need a special one because it's a shared server? (Someone at Thwate mentioned wildcard certs - I have no idea what they are :().
So in essence, do these certs work on a per-domain basis, or a per server basis?
Also, whch is the best deal? I hear the GeoTrust certs do not work with some older, but still commonly used version of IE (v5.00 I think).
Plzzzz help :(
| 3:18 am on Jan 7, 2004 (gmt 0)|
Secure Certs will work on a shared server. You need to have your own IP address.
| 3:41 am on Jan 7, 2004 (gmt 0)|
Excellent thank you!
I've got my own IP so I should be set then.
Any ideas on which company is the most cost effective & compliant with multiple browsers & platforms? I'm thinking Thawte is good value for $199, in comparison to Verisign which seems to be like $900.. I'm not even sure if I'm looking at the right thing on their site though. Who know's what those guys are trying to sell you!
| 3:52 am on Jan 7, 2004 (gmt 0)|
Take look at here:
Once you get your Certificatre, the web host should install it.
| 9:01 am on Jan 8, 2004 (gmt 0)|
You do *not* need your own IP address. You *do* need your own domain name.
The way it works is that your domain name is embedded in the certificate, so the web browser will flag an error to the user if the domain name and the certificate are different or if the certificate is not 'certified' by one of the root nodes - Thawte, verisign, etc.
| 3:31 pm on Jan 8, 2004 (gmt 0)|
> You do *not* need your own IP address. You *do* need your own domain name.
That only holds true if you are the only person using SSL on that IP address. Since the server sends the certificate *before* the client makes a request, it has no idea which certificate to present if there are multiple SSL sites on one IP address.
| 3:32 pm on Jan 8, 2004 (gmt 0)|
Welcome to the new folks... gotta nip this one before it starts, though:
|You do *not* need your own IP address. |
This is a false statement. You absolutely need your own IP address. One IP address per SSL certificate. That's it.
It has to do with protocol/handshake restrictions. It's a chicken and egg problem that's off-topic for this forum.
To the original poster:
|but do I need a dedicated server to install one? |
|So in essence, do these certs work on a per-domain basis, or a per server basis? |
Per domain, per server. You only need one (regular, non-wildcard) certificate if you have one domain and one server serving that domain.
|Also, whch is the best deal? |
For your first SSL certificate, I'd seriously recommend going with VeriSign, just for the level of support provided. You can go out on your own with the others, but VeriSign has the most comprehensive support. VeriSign's normal 128-bit domestic SSL / 40-bit international is $395. If you're not doing international commerce, you can most likely stick with the normal domestic certificate.
Also, there is some weirdness when installing on IIS 5. Is that the platform you'll be installing on?
| 4:05 pm on Jan 8, 2004 (gmt 0)|
Baked Jake has it right. Having your own IP AND domain is a must. Also, it is important to register the certificate to your www.mydomain.com address rather than an IP address if you are not hosting your own site. The reason you should avoid registering it to a particular ip address is that ip addresses are not really portable. Meaning if you leave hostA, your can't have the exact same ip at HostB.
| 2:13 am on Jan 9, 2004 (gmt 0)|
Thanks to all that replied, particularly bakedjake.
I've decided to go for a Geotrust cert for 3 main reasons:
1. It is more economical and should the site fall through I'll feel better for not having spent so much on Verisign.
2. The server admin at my hosting provider is extremely technical and all of the work would be done on her bahalf, so therefore the additional support required by Verisign would not really be needed. (The admin also had experience with the GeoTrust certs.)
3. GeoTrust seemded to be a lot faster. I received the key in less than 1 hour.
Overall the GeoTrust cert seems to be working well, although I was correct that it does not work with IE version 5.00 (5.01 & up is fine).
BakedJake, you bring up an interesting point, which is that of international compatability. I didn't realize this would be an issue. If possible, might you elaborate on what the restrictions would be with the SSL certs for international visitors?
Is this because international browsers have a restriction or is it more technical than that?
Thanks in advance
| 2:54 pm on Jan 9, 2004 (gmt 0)|
|Is this because international browsers have a restriction or is it more technical than that? |
Good question! Back in the good ol' days, the US had export restrictions on browsers featuring 128 bit security. Basically, with a standard SSL certificate, you'd get 128 bit security from domestic browsers, and 40 bit security from international browsers.
IIRC, that restriction has been removed. So with most of the modern browsers, you'll get 128 bit security with a standard certificate, no matter where you might live.
Bottom line: You'll always have an encrypted channel, it's just a matter of the encryption level.
BTW: The GeoTrust cert will work with all browsers. It'll just throw a warning message up with older browsers that don't count the GeoTrust signing authority as a trusted source. But if the user hits the accept button, no matter which browser version he's using, he'll still have an encrypted connection. You may wish to put up a page explaining that fact.
| 3:02 pm on Jan 9, 2004 (gmt 0)|
if you want to DIY it just check out this site - they give the lowdown on all the providers - verisign et al :
| 8:45 pm on Jan 10, 2004 (gmt 0)|
thanks gazza - that's a useful resource.
BTW welcome to WebmasterWorld!
| 5:19 pm on Jan 11, 2004 (gmt 0)|
Certs are domain name based and *absolutely not* IP based.
Some guy above was close to being right, but still missed the boat.
Some webservers (apache being one of them) require you to own a port (443 generally) in order to use a cert. However, this is *easily* gotten around by using port redirection. It's like one line command with redir.
| 12:00 am on Jan 12, 2004 (gmt 0)|
Yes, this IP vs. Domain Name question is a bit off topic, but it is still quite core to the question.
My understanding, corroborated by several FAQs about SLL that I've located through Google:
1) transactiongeek is correct, in that an SSL certificate is formally bound to a domain name and not an IP address, and the domain is what is encrypted into the certificate request.
2) bakedjake is pointing to a practical issue in that web servers often link the certificate to the IP address, which can create less than happy results with shared IP addresses/virtual hosting.
There can be server work-arounds, as transactiongeek has mentioned, but when you're in a shared hosting environment, those work-arounds may not be easy to deploy.
| 3:03 am on Jan 12, 2004 (gmt 0)|
Certs are domain name based and *absolutely not* IP based.
Not to be pedantic, but an SSL certificate can contain anything, including an IP address or the lyrics to a song. All the web browser does is compare the common name (CN) in the certificate to what url is being displayed and flag a warning if they differ (including www.foo.com being different from foo.com)
Now, will a CA sign a certificate with an IP address as a CN? I'm not sure, since right now their primary method of authenticating a certificate is comparing a business registration with WHOIS records. However, strictly speaking, if you want to direct people to an IP address rather than a domain name, nothing prevents you from doing so.
And, as more food for thought, SSL allows both ends of the communication to present a certificate. There is nothing saying you can't, for instance, have a certificate with your real name as the CN, rather than giving a username and password.
Back to the original topic, there must be a 1:1 mapping of Certificate & SSL website & port pairing to IP address. You can't do virtual hosting of multiple SSL domains on the same IP:Port pair because the certificate is presented before the request for the website is made.
| 9:49 pm on Feb 9, 2004 (gmt 0)|
My SSL Certificates are from Comodo. For $49/year you can get a perfect SSL certificate and install it on your shared server.
It's at: www.InstantSSL.com
Wilcard certs cost more but you only need them if you need secure pages for your subdomains.
To get the cert you need to generate a signing request which your ISP will do for you. I am a hosting reseller so I have done this myself many times and it only takes a few seconds. Comodo will then send you your cert within 24 hours but you will need to send them some id when applying.
I've had no problems and their support is excellent.