GoDaddy Gossip

Apparently GoDaddy let their SSL cert expire today.

Whoops!

Wholly - Use promo code WhollyMindless for discount.

Whoops!

Then again, they at least have their own cert. I for one think it would be great for Dreamhost to become a certificate authority. I think they'd be able to provide good value with better service than the daddy.

Does anybody have any idea about the cost to have SSL cert? I've seen some websites that are big but still let the cert expire.

Certs go for between $19.95 a year up to $995 a year and up. Dreamhost offers them for $99.95 a year. I thought these were Geotrust certs but this is cheaper than you can get them from Geotrust themselves ($250/year), so I don't know the full scoop.

Btw, what's the benefit of using this certificate thing ?

TTL

In reply to:

---

Btw, what's the benefit of using this certificate thing ?

---

You need to purchase an SSL certificate in order to have your website accessible using the https protocol, which will provide secure, encrypted communications between the browser and your web server. Users can be positive that they are reaching the real web server for your site and that any communication they have with that web server is encrypted. The latter is important because even if any sensitive data flowing between the browser and your web server is intercepted by an intermediate host, that data can't be used/understood. This keeps sensitive information like credit card information secure.

Here are some articles on the subject:
http://wiki.dreamhost.com/SSL
http://wiki.dreamhost.com/KB_/_Account_Control_Panel_/_Goodies_::_Secure_Server
http://en.wikipedia.org/wiki/Https

Good links, but

In reply to:

---

You need to *purchase* an SSL certificate in order to have your website accessible using the https protocol, which will provide secure, encrypted communications between the browser and your web server...

---

is not precisely correct. Emphasis on purchase is mine. If you're selling something or have some other commercial purpose, then almost certainly you want to purchase a cert from a well known(ie well supported in browsers) Authority.

But if you just want https for the extra security of encryption, then you can stick with self certification(aka $$ free). Yes, for those thinking "Free!", be forewarned that clients will get a pop-up warning that your cert is not recognized as a legitimate authority. Depending upon your use, this behavior may be just fine. (And you can accept the cert and not be bothered with future warnings.)

Despite the wide open nature of shared hosting, I like having the option of SSL with a couple of services I run(paying for the fixed IP is enough -- not worth a commercial cert for me). I mention all this only for others that may feel similarly and were unawares...

Good point. I had originally considered explaining the pros and cons of self-signed certs for debugging and partial security (you get encryption but don't necessarily have the assurance that you're actually talking to your server) for whatever personal purposes. I figured the question was addressed at non-personal use of SSL, which in practice does require the purchase of a certificate issued by a certificate authority.

I think this edge case is particularly rare given that you have to pay $47.40 a year for your unique IP but aren't willing to pay the $19.95/yr for the crappiest legitimate cert. I am personally interested in it so I'd be up for hearing about the use cases!

Well, forgive me for extending the thread into details many perhaps do not need BUT,

In reply to:

---

...self-signed certs for debugging and partial security (you get encryption but don't necessarily have the assurance that you're actually talking to your server) for whatever personal purposes.

---

*could* be a little misleading to some. Assurances that you're talking to your server? No different client behavior between a personal/private cert and a commercial cert here. At least after the first time you've accepted that personal cert. If the IP changes, you'll be warned.

As for further use cases -- beyond providing encryption for any data you might upload to a particular service(calendar, intranet, finance mgmt, etc...)?? Since I'm guessing you know better(as a regular contributor to DH forums and it seems to me a somewhat savvy IT user), forgive me if I sound pedantic as I get on a pedestal...

Never trust your network. Sure if you're at home and you're confident your control over that network is "perfect" or you don't care if some sniffer/snooper can see your date plans for the weekend, that's one thing. But you might want to get into the habit of treating even those bits securely so you don't have to think about it when out on a network you don't control(like the coffeehouse, school, work, etc..). Especially if you've setup personal intranets or other services that may contain sensitive information. Though I've already alluded to the fact that in the end, you are putting your trust in the guys and gals of DH(even if you're paranoid enough to encrypt your data repositories).

Coming back to the issue of purchasing a personal vs commercial cert, it is again important to understand the real purpose behind a commercial cert. It[commercial] does not increase line/IP security per se but serves to vouch that you are who you say you are. Even at a cheap $19.95/yr, I have no need for such a service for myself or those who personally know me. The same goes for internal small biz services. Not necessary. Remember, you can accept the personal cert and not be bothered by pop-ups unless something on the line changes(web server, IP).

I don't doubt this has been an incomplete discussion of the issues around HTTPS certs here, so for those interested in more info, I encourage you seek out additional info.

No need to apologize, I just originally wanted to structure the explanation to provide the first-order approximation first and then later allow us to go into further explanations of how what we were saying isn't always 100% accurate. I feel we're doing that part now, which is great! (BTW, this is all based on feedback I got at some 360 degree review at work about ten years ago, so please do feel free to comment on whether you think it's effective or not!)

In reply to:

---

*could* be a little misleading to some. Assurances that you're talking to your server? No different client behavior between a personal/private cert and a commercial cert here. At least after the first time you've accepted that personal cert. If the IP changes, you'll be warned.

---

It's my understanding that commercial certificates validate their issuer back to some set of root certificate authorities that are initially set by "the browser". So when Firefox installs, it installs with some set of root authorities that are used to validate each site's certificate chain. It was my understanding that when your site presents a valid commercial certificate, the browser checks to make sure that the site that's presenting the cert matches the site of the certificate and that the issuing authority is either a root authority or an authorized issuer through some levels of indirection (signing). This process ensures that you are in fact communicating with the "real" site and that communication to that site is "end-to-end" secure, where we define end-to-end as browser process to web server process.

When your site presents a self-signed certificate, most browsers will alert you that the certificate is fishy because it was not issued by a recognized authority. This is because anyone can set up a site and issue a self-signed certificate with that site name. This is why I said that such certificates are really only useful in "personal" situations where you're not really worried about the authenticity of the server but just concerned about data encryption.

Short of someone stealing a commercial certificate or otherwise compromising the chain of trust, or by compromising your browser in some dastardly way, I'll go ahead and assert that you can, in fact, be assured of end-to-end security through the use of commercial certificates.

Actually, rereading your post I find it confusing that on the one hand you say: "Assurances that you're talking to your server? No different client behavior between a personal/private cert and a commercial cert here." and on the other hand you say: "It[commercial] does not increase line/IP security per se but serves to vouch that you are who you say you are." I meant to convey that a properly installed commercial certificate assures users of your site that they are in fact connecting with the actual site and not some imposter site.

In reply to:

---

I meant to convey that a properly installed commercial certificate assures users of your site that they are in fact connecting with the actual site and not some imposter site.

---

Yep, I understood what you were saying. It seems I was less than clear in my reply. I'm saying that your personally signed cert will work much the same way for line security. Those man-in-the-middle attacks? I will *still* get a browser warning if say, someone tries to impersonate my domain. Does not matter that I didn't use a third party certificate.

Is that any clearer?

To oversimplify, I'll go out on a limb again and just repeat: Unless it's for commercial purposes and the clients/browsers connecting don't know/trust you personally, I don't bother with a commercial cert though I might use HTTPS. All should keep that option in mind.

What I'm saying is that:
1. When you use a commercial cert, your visitors will not get a browser warning about the cert.
2. When you use a self-signed cert, your visitors will get a browser warning about the cert.
3. Using a commercial cert, visitors are assured that they are connecting to the real site.
4. Using a self-signed cert, you have to otherwise be able to securely transmit and install the presented certificate to browser clients in order to be assured that the site is what it says it is.

I'm pretty sure that we both understand exactly what is going on, I think we're just disagreeing on exactly the words we use to describe that situation. About two posts back I said that self-signed certs were only really useful for personal use. You just said "Unless it's for commercial purposes and the clients/browsers connecting don't know/trust you personally, I don't bother with a commercial cert though I might use HTTPS.".

Yep! It's all in "how you say it".

There are "commercial purposes" for which I find a self-signed cert to be acceptable - for instance, data exchange with known vendor who actually knows more about your company than the "certifying" authority is likely to know.

To me, the security provided by the TLS/SSL process is often at least as important as having a "certificate authority" vouch for the "identity" of the entity offering the cert, but that can vary greatly depending upon the use - and I think that is at least part of what seniorjt is trying to say.

--rlparker

I agree completely that self-signed certs have their purposes and are very convenient and usually sufficient for most non-commercial purposes (and as you say, rlparker, some commercial purposes as well).

I think the whole thing went awry with the pendantic argument about the exact differences between the assurances that a commercial cert vs. a self-signed cert will be able to provide.

I do agree 100% that people should consider self-signed certs for non-commercial and many non-critical uses. The $50 annual charge for a unique IP address is a bit of a downer. Do we really have to pay that for every domain?

In reply to:

---

The $50 annual charge for a unique IP address is a bit of a downer. Do we really have to pay that for every domain?

---

DreamHost has repeatedly insisted that a unique IP address *is* required, and the question has been asked quite often (and a few "workarounds" attempted).

As for the charge, I suspect that it could, at some point, be subject to market forces and all but, being that "unique IP addresses" are a "limited resource", I'd bet that prices for providing them are more likely to stay the same, or even escalate, than they are likely to go don.

Not to wander too far "off topic", but to just share a thought: I've considered using a "single" Unique IP address" for a "third party" type site (another domain I own that could be used for this purpose) to share TLS/SSL processing for multiple sites ... but then those whole issue of the users' "same site" perception of who they are dealing with comes into play. I'm concerned it will "worry" consumers, so I have not actually implemented such a plan.

I guess, at the end of the day, for anyone doing e-commerce who needs TLS/SSL, $50.00 a year for the IP address shouldn't really be a "deal breaker" (any more than the cost of a certificate should be). The cost of the cert and the unique IP address might be "irritating", but the economics of the scenario should cover the expense of using them.

--rlparker

I think the things we've seen as far as third-party payment mechanisms and third-party authentication mechanisms do point to something of an alternative.

And what about IPv6? Maybe unique IP prices will start going down 10 or 20 years from now. :)

In reply to:

---

And what about IPv6? Maybe unique IP prices will start going down 10 or 20 years from now. :)

---

Well that's certainly possible .. "10 or 20 years from" now who knows what the "Internet" will even look like?

--rlparker

In reply to:

---

"unique IP addresses" are a "limited resource", I'd bet that prices for providing them are more likely to stay the same, or even escalate, than they are likely to go don.

---

All it takes are another period and a few more digits, and the supply is virtually unlimited. They should be cheaper than domain names.

In reply to:

---

I've considered using a "single" Unique IP address" for a "third party" type site (another domain I own that could be used for this purpose) to share TLS/SSL processing for multiple sites ...

---

Somebody around here does that already...

Oh yeah webmail....

Could not verify this certificate because the issuer is not trusted.

Issued To
Common Name: webmail.dreamhost.com
Organization: New Dream Network, LLC
Organizational Unit: Webmail.DreamHost.com
Serial Number: 00

Issued By
Common Name: webmail.dreamhost.com
Organization: New Dream Network, LLC
Organizational Unit: Webmail.DreamHost.com

Validity
Issued On: 3/7/2002
Expires On: 3/2/2022

Fingerprints
...

In reply to:

---

All it takes are another period and a few more digits, and the supply is virtually unlimited.

---

True enough.

In reply to:

---

They should be cheaper than domain names.

---

You'd think so,wouldn't you? I think it's more the allocation system that is the limiting factor now... and I don't know how easily that is likely to be changed.

In reply to:

---

Somebody around here does that already... Oh yeah webmail....

---

Of course they do!

--rlparker

Wow, that thread took off.

Wholly - Use promo code WhollyMindless for discount.

Yeah, it took an unexpected turn into techno-securityland! :)

I don't know if the point has been made clear but here is a less technical explanation of how certs work:

Getting a cert is like having a friend set you up for a blind date. If you trust your friend then you have more faith that the person you're meeting is to your liking. It's not a perfect system but it works for most people.

Some people visiting your site don't know or trust you - it's a blind date.
These people run browsers that identify trusted certificate issuing companies.
Most people don't know who these "trusted" companies are, only that the companies are well recognized, "official", and if the browser trusts them, generally we can trust them too. The browser certs are updated once in a while with a new list of issuing companies like Verisign, Thawte, etc.
So - they trust the cert company, but why would they trust you?
To get a cert, you have to prove to the cert company that you are who you say. You fill out forms and go through a rigorous process to prove your identity and that your website is legitimate. When you have proven yourself worthy the company issues you a cert.
So now you have something to show that you've been through this extensive process to prove you are trustworthy. You've already been through the same sort of process that a visitor would want to put you through to make them happy.
The visitor trust that the cert company has done their job, so if the cert company says you're OK, then (all things being perfect) it's pretty safe to say they can trust you too.

If you have a cert and it comes from a recognized cert issuer, the user doesn't even get a warning- there's no need to warn them that you are safe. Some users don't update their PCs and may not recognize the "buck-99" cert issuer that approved your application. So they get warned that their browser doesn't recognize the cert issuer. (Why should your blind date trust that you're OK when they don't even know your friend?) The solution is either for them to get some new friends (update their browser list of cert issuers) or for you to find yourself some trustworthy friends - you may want to get a cert issuer that costs a bit more, but every browser knows them.

(BTW, this really doesn't have anything to do with browsers either. The trust database can be used by any program that needs to do authentication.)

Self-certing is like walking up to a stranger that you'd like to date, introducing yourself, and saying "hey babe, you can trust me." The visitor can choose to believe you or not. If they're already your friend they'll accept your personal certificate of trust, and their browser will allow you to visit their site in the future without further warning.

You can tell your browser about conditions where it should warn you. In the case of GoDaddy, someone had their browser set to warn if a cert is expired. An expired cert usually means someone was lazy and didn't go through the expense or paperwork again to re-prove themselves to a cert company. But sometimes it means the site is now no longer trustworthy, that perhaps the certificate expired and the site owners can't get a new one. It's like not having your friend vouch for you when you're trying to look good on a date - it doesn't look good.

Certificates can also be revoked if the cert holder has later proven themselves unworthy. You can tell your browser to warn you about certificate revocations. This is particularly important because it means your friend the cert issuer has reason to say a site is no longer trustworthy. Whether they're right or wrong you need to consider for yourself what that means and decide if you still want to trust the site even though something serious like this has occurred. Hey, maybe the site's check just bounced, who knows?

The whole thing about encryption is completely separate from this trust situation. In general if you have a need to establish a trust relationship then in almost all cases it's because you're exchanging confidential information - and that's why HTTPS/SSL is so closely related to the concept of a cert.

The sad thing is that most people get cert warnings like expirations and revocations, and they just click OK on new sites anyway - or they just turn all of the warnings off. For this reason I really believe people should be required to get a driver's license for the information superhighway - they they don't know the rules of the road I'm more inclined to charge them for getting themselves into an accident.

So anyway, that's my blurb and except where it's intentionally vague I'll stick to it.
Don't forget to wear protection when your surfing. (huh?)

HTH

I like the "blind date" analogy. If only they had a better reputation. :)

In reply to:

---

And what about IPv6? Maybe unique IP prices will start going down 10 or 20 years from now. :)

---

I don't think you should have to wait that long. The World is running out of IPv4 addresses. The last report I heard was that we are running out of IPV4 addresses in 2010. http://news.bbc.co.uk/2/hi/technology/7068140.stm

I heard the 2010 date as well, but also read that if they reclaim old/unused ranges, they think we can go until 2017.

-

In reply to:

---

I heard the 2010 date as well, but also read that if they reclaim old/unused ranges, they think we can go until 2017.

---

Is all the major server apps support IPV6 already? Apache/PHP/MySQL? Linux... as I know already support it.



Dino

In reply to:

---

Is all the major server apps support IPV6 already? Apache/PHP/MySQL? Linux... as I know already support it.

---

Since IPv6 is an implementation of the network layer in the protocol stack, most applications should be insulated by the transport layer and by the DNS system.

That said, I'm sure there are lots of applications out there that somehow don't work with IPv6 - probably in their handling of literal addresses or possibly some DNS resolution issues.

-

In reply to:

---

That said, I'm sure there are lots of applications out there that somehow don't work with IPv6 - probably in their handling of literal addresses or possibly some DNS resolution issues.

---

I'm pretty sure of it, and whether they are very aware of it. MySQL, for example can determine which IP/host should be given permission to access it. And AFAIK, Apache with its .htaccess . Don't have time to explore whether the apps already support the IPV6 yet. But I think I'm gonna study the apps from now on.

Dino

In reply to:

---

I heard the 2010 date as well, but also read that if they reclaim old/unused ranges, they think we can go until 2017.

---

And what would happen then? I bet that in 2016 they will say something like "well if we use NAT on just about everything we will be able to use the old IPv4 system for another X years" and so on. It's ridiculous. I say that it's better to start acting now and roll out the switch-to-IPv6-plan. If there are hardware and software that can't use IPv6 use something else. If they want people to keep on using their stuff they will add support for IPv6.

I think everyone is rolling out the support for IPv6, it's just a matter of replacing all network equipment in the world that's incompatible as well as upgrading all incompatible hardware and software - and let's admit it, there's a lot of incompatible software and hardware.

This is an upgrade that makes Y2K look like a walk in the park. The worldwide cost would be measured in the trillions of USD.

In reply to:

---

This is an upgrade that makes Y2K look like a walk in the park. The worldwide cost would be measured in the trillions of USD.

---

That will be a huge business, anyone ready to participate ?

Dino

In reply to:

---

That will be a huge business, anyone ready to participate?

---

I actually hope that it doesn't become a big business and that instead, we got the slow upgrade route.

I think the whole Y2K episode had a huge negative impact on real investment and growth. I think it sucked massive amounts of R&D and IT dollars away from worthwhile R&D and IT projects and into the boondoggle of "testing applications for Y2K compatibility." It also fueled the already overheated market for replacement hardware and software at a time when the market was overheated anyway due to the dot com boom.

Creating this kind of cyclical business is inefficient. I suspect it made the subsequent crash even deeper.

DreamHost still lost more domains TO GoDaddy (840) than they gained FROM GoDaddy (639) last week, although the ~200 difference is less than 10% of DreamHost weekly net gain (3045).

In reply to:

---

Creating this kind of cyclical business is inefficient. I suspect it made the subsequent crash even deeper.

---

OTOH, efficient people survive and thrive in these cycles and less efficient people get driven out. This may be more efficient overall, and is the way things are. As a consumer of IPs I say let's get on with it, and I hope some companies will thrive, even in spurts.