The more expensive certificates are often signed by trusted roots already installed in the client operating system, browser, or SSL tool kit. This eliminates the requirement for an additional certificate installation or configuration. Installing the intermediate certificate is fairly simple in Windows/IIS, some *nix programs have different file format requirements — each cert in a different file, or combined in a single file in some particular order.

Certificates not signed by a trusted root can also be problematic for some mobile devices. Of course, even certs signed by trusted root may be problematic if the root is not part of the device’s root store and the device is locked by the carrier to prevent installation of new roots.

I use GoDaddy’s multiple host name certificates (can’t think of the designation, but they use X509v3 Subject Alternative Name extensions) with little problem, even with the intermediate certificate requirements. The only issue is the missing signing root (ValiCert Class 2 Policy Validation Authority) on some mobile devices, which I mitigate by installing the root manually — again, not available for all devices.

So there technically is a difference between them. While the differences may be transparent to the end-user, in certain cases they are certainly visible by the administrator.

It’s definitely my place and the businesses/user do care.

Here, I’ll try to bring this back to some sort of semblance of a subject. I would prefer that you stay on-topic and answer questions when they are directed towards you. I would prefer that you respond to the meat of my arguments instead of one-liners that are unrelated to the argument(s).

"You’re the one who brought up the entire ActiveX platform and made a blanket statement that it’s insecure when it’s developers making mistakes with ActiveX that are the problem just like it’s the developers that make coding mistakes in any language"

I don’t want to talk about ActiveX. I do want to discuss software security safe guards.

ActiveX is a good topic for software security, but it’s not unique. Maybe "insecure" is the wrong word (note to self: did I even use that terminology or are you putting words in my mouth again?).

The correct wording would be "increases the attack surface to an unmanageable level, thus increasing risk to the point where preventative measures and other controls create an unbalanced equation".

Developers only make mistakes when you give them enough rope to hang themselves. Rope can be a useful tool for going places (you can’t climb a mountain without it), however — 2008 is not the time to be climbing. If you look at the rate and severity of data breaches today compared to 1-2 and 2-5 years ago… things are in really bad shape. Crimeware is extremely prolific, and yes — some of it is ActiveX-based. ActiveX is not immune to the Internet disease that is spreading at unprecedented rates.

We need to pull back on the developer reins. This is mostly a process issue — something that a Secure Development Lifecycle would seek to solve. It is also a people issue. We need people doing the right things (process), and on the second iteration — we need to improve the tools (i.e. technology) that they use, both on the code itself, as well as with the process.

If you know anything about the software development lifecycle or have read Boehm’s proofs (and later Jaquith’s, Soo Hoo’s, and Geer’s work related to security bugs), you’ll note that over 80% of bugs are created during the requirements phase, and that the cost to fix these bugs is as much as 200 times more during the maintenance phase.

Developer mistakes is the same thing as saying "pilot error". We need a better process, and continuous improvement of process/people/technology to move on this issue.

What does this have to do with FTP and Web services? Well, FTP does not meet the baseline security requirements when considering it does not implement a modern AAA stack to help with your precious CIA model. Web services, when properly designed and implemented through a Secure SDLC, will rise to the occasion. It will also have problems, maybe even more in the short term. But as a scalable, long-term solution to reduce risk — it is worth the investment now. I do not believe in a complex Web services stack although this could easily happen. Web services should be about as complex as FTP when implemented for this purpose and not much more.

If you read what I said, you’d understand. I compared an ActiveX APPLICATION to QuickTime which is also an APPLICATION. The comparison is valid because there are no single ActiveX applications that are as habitually buggy as Apple QuickTime, Firefox, or Internet Explorer. You’re the one who brought up the entire ActiveX platform and made a blanket statement that it’s insecure when it’s developers making mistakes with ActiveX that are the problem just like it’s the developers that make coding mistakes in any language.

"The QoS thread is totally different. I also didn’t say those things"

Don’t be a liar Dre when your comments are in writing. Your most recent post in the other thread on Net Neutrality continues to recklessly call for class-action lawsuits against router manufacturers because routers add a millisecond of delay. You sound like one of those people pushing the theory that the US Governement brought down the towers and that’s not what this site is about and I’ve run out of patience trying to clean up your mess.