How can I change all links in the store to be https if the site accessed via https?

[Website Rob]

I did not want to switch the entire site to SSL.
All I was looking for was for the http://domain/ to have all http:// links, but if arrived at the site via https://domain/ for all links to follow the same and be https:// links. Is that possible? If they were relative links, they would inherit the protocol, would they not?

Is that possible? Yes

Is it worth the effort? No

Bite the bullet and go SSL for all pages. I will disagree that SSL everywhere is a Google thing, although it may look like it at the moment. Once servers make the upgrade to using HTTP 2 (which is much better than what is used now), SSL for all pages becomes mandatory anyway regardless of whether the site is eCommerce or not.

[RodG]

I will disagree that SSL everywhere is a Google thing, although it may look like it at the moment.

Believe what you will. I prefer sticking to facts myself. <shrug>

For those the seek the truth, it can be found. Example:
===================================

Google has a phase it likes to use: “HTTPS Everywhere.” In fact, that’s what they named this year’s I/O Conference. The idea is that if every site implemented HTTPS, the web would be that much more secure; but, it’s a red herring. Here’s why:
HTTPS only protects against a very limited number of site vulnerabilities, specifically wiretapping and man-in-the-middle type attacks — in other words, spying. It makes the NSA’s job of tracking and spying on internet users more difficult, but it doesn’t protect against hackers, denial-of-service attacks and scripting, server or database exploits.
Essentially, HTTPS is useful for sites that collect and transmit personal information. Banks, e-commerce sites, even social networks need to have HTTPS in place to make sure consumers’ sensitive information is protected.
For all the blogs, news sites, brand brochure-type sites or any information site that doesn’t require a member login, HTTPS is useless. It’s like the post office telling you to that all your mail needs to be written in secret code. That’s fine for the military, but do your Christmas greeting cards really need to be written in unbreakable secret code? Probably not. It’s just as pointless to require HTTPS on sites that do not transfer sensitive information.
That’s why it doesn’t make sense for Google to consider using HTTPS as a ranking signal for the majority of sites and queries. If used at all, it will always be a very lightweight signal used on a very narrow set of queries, acting only as a tie breaker between two identically ranked pages.
No, this announcement is not about search quality. It’s about Google trying to get back at the NSA for making it look bad during the PRISM scandal, and it is doing this under the guise of a social cause — internet privacy under the “HTTPS Everywhere” banner.
It’s a classic “greater good” story. Google says HTTPS will be a ranking signal so that everyone runs out and switches to HTTPS. What they’re not saying is that this change will only affect a minuscule number of sites. For everyone else, they’ve wasted time and energy switching to HTTPS for no reason — but that’s okay, because it serves the greater good of improving privacy for the internet as a whole.

Ref: http://searchengineland.com/google-s...-really-201058

This is one of 1000's of references that can be found. Alas, I was unable to re-locate the one I was really looking for (It was something written by Google themselves in one of their own blogs, and I suspect that it has since been removed because it gave the *real* reason for their push for SSL everywhere - but to paraphrase what was written it was something along the lines of
"The increase of mobile applications that have the capacity to access all data on the device has changed the landscape for advertising potential that is giving our competitors valuable insights that is currently not available to us. In order to keep up and compete we need access to the same kind of data on a desktop computer that our competition has on mobile devices. Due to the sensitive information of some of this data we feel it our duty to ensure this data is kept 'secure', therefore we will be taking steps to ensure that all data transmitted be SSL encrypted"

So, reading between the lines here - They are, or have, made changes to their web browser (Chrome) that enables it to 'spy' on you and view any file on your system - even though there is no technical reason for it.

Needless to say, if they just came out and told people that they plan to spy on us in this way, there would be an uproar, so what they've done, is in addition to 'securing' the data they have no right to access in the 1st place, they've taken the route of pushing the 'SSL everywhere' to distract us from the fact that they only really need it to protect *themselves*. It is easier to hide a tree in a forest than an open field. Their plan has worked, people have fallen for the 'we are doing this your your security' , hook line and sinker - To the extent that almost everyone on the planet now equates 'SSL as being the end all and be all of 'security' - and that is *FAR* from the truth. As this article (and I) have been saying for many years "HTTPS only protects against a very limited number of site vulnerabilities".

What is more important to to me, and should be to others, is that *authentication* provides far more in the way of security than any amount of encryption. Give me an authenticated site *without* encryption over an encrypted site *without* authentication any day of the week. Hackers and scammers have zero problem setting up a fake site with encryption these days - and that alone make SSL *useless* - but we aren't being told that are we?

Prior to Googles' push for 'SSL everywhere' and their *massive* funding to provide free SSL certificates (Lets encrypt being the largest recipient of this funding) to make this possible, SSL certificates had to be purchased, and a part of the cost for this is because to obtain the certificate, the purchasers had to *prove* they were who they claimed to be (authentication) , so when folk visited a site with SSL they could be assured that they were on a *legitimate* site and not a 'copy' of the site that had been set up to steal your confidential data. The encryption aspect is/was or far less importance due to it only being 'protection of a limited number of vulnerabilities)

We no longer have this authentication. We no longer have the protection that SSL was designed to provide us. What we have instead, is encryption where it isn't needed, and the false belief that encryption protects us against things that it doesn't.

The internet (and our data) is less secure today with its SSL nearly everywhere than it was before Google decided that we need their 'protection'.

I really miss those days when SSL actually had *meaning*. I miss the fact that with the current Chrome releases I can't even click the 'secure' icon to even see who the certificate was even issued to. I no longer have an easy means to determine that a site I'm on is the site I *think* I'm on. I can no longer trust SSL to protect me from anything other than a rogue employee in a data center (or ISP), because that is the only possible place that my data can be 'sniffed' anyway. (assuming I'm not using WifI, which opens the possibility of MITM attacks).

I'm disappointed that many people that *should* know better (that authentication is more important than encryption) have either forgotten this, or never knew it in the 1st place. I get very frustrated that no matter how much I try to teach these things, I get tend to shot down because it is easier to believe the Google spiel than the many *experts* that have been fighting this trend for many years.

Sadly. The experts have lost the war - They (Google) have, with their injection of millions of dollars to provide SSL certificates to all and sundry, free of charge, with no authentication checks whatsoever, have made the internet less secure now than it ever has been, while at the same time, convincing most that it is more secure. It's a freaking joke, and we are all the worse of for it.

The war may be lost, but some of us continue the battle - Authentication will never return, but the battle to convince people that SSL != Security continues.

Cheers
RodG

[Website Rob]

Rod, I agree with you about Chrome which is why I refuse to install it on any of my devices. You might want to study up on HTTP/2 though, to see what's coming down in the near future. Although HTTP/2 itself "does not require" SSL, it is the Browsers that are forcing it to be used.

HTTP/2 is defined for both HTTP URIs (i.e. without encryption) and for HTTPS URIs (over TLS, where TLS 1.2 or newer is required).

Although the standard itself does not require usage of encryption, most client implementations (Firefox, Chrome, Safari, Opera, IE, Edge) have stated that they will only support HTTP/2 over TLS, which makes encryption de facto mandatory.

May 14, 2015 Publish HTTP/2 as RFC 7540


Note also that later this year, PCI Compliance will require TLS 1.2 or better. The higher powers that be (ie. Credit Card Companies) are demanding more 'n more tighter security.

Overall, I'm sure you'll agree that faster loading websites is a good thing. With HTTP/2 they will be and noticeably so. It won't be long before HTTP/2 is the norm and that means using SSL.

[RodG]

Rob, i fear that this is getting to the stage where the mods are going to close the discussion, but before they do, you speak as though Ive never heard of http2 ???? dont know why you would think that. Secondly, you speak about its improved performance. I dont what this has to do with SSL or this discussion.
Where you did make a relevant comment (the bit about PCI) you appear to have ignored the fact that SSL is just one of many requirements, and TBH, I dont know of any website owner that complies with many of the other requirements, most of which are more important than SSL, but due to their nature wont be picked up by any PCI scans or any other software. This lack of compliance can only be determined by an onsite audit. .... but most importantly, how many times in my post did I stress the importance of *Authentication* ... in fact I stressed several times that this is/was a key issue in regards to security, and it this lack of Authentication that has negated the effectiveness of SSL and has made the WWW less secure now that it has ever been. How many times did *you* mention Authentication? ZERO. That both saddens and sickens me, because, running a hosting business you should know better. Encryption without Authentication if fcking useless. Heck, I even stated *why* (bad guys can and do encrypt Authentic looking websites). The original design of SSL was to *prevent* this. That is why we had CA's. Now that anyone can get an SSL cert without Authentication has made the CA's about as useful as an ashtray on a motorcycle. Basically, you appear to have ignored everything I wrote and all the important points I was making. You are still trying to push the SSL == Security line, When that couldnt be much further from the truth. SSL *used* to equal security, but all it offers today is encryption. It is not the same thing and those that promote it as such are promoting and propagating Google's lie.

Encryption is now a way of life, even where there has never been a need for it. No avoiding that, Authentication ... gone. Never to return. Google has ensured that.

Security is as important (or more imortant) today as ever, but as long as people are being constantly deluded into thinking that SSL today provides the same security as it did when it was created then we have a serious problem on our hands.

To re-iterate/stress a point from my previous post. *I* feel far less secure shopping online these days than at any time in the past (and I've been shopping online for nearly 30years). I have an advanced diploma in network security (nationally recognised). I undergo further training each year (Aust govt department of defence. Intelligence and security, or ASD as it is now known) ... but hey, lets ignore all that.... You're the real expert here, after all you run a hosting business, and that clearly makes you more qualified than I am on the topic. If you say SSL equals (or is essential) for security then it must be true. I dissagree.

[RodG]

PS. Since you broached the subject of http2 and urging me to read up on it, It may interest you to know that all of the sites we host have been (nominally)supporting this for quite some time by virtue of the CDN provider we use. All the the sites we host are also SSL enabled, by virtue of the same CDN (no ssl cert required). I'm not under any delusions that the sites are "secure" as a result of this. We use them for the significant speed improvements it provides, and a *huge* reduction in bandwidth used by our servers. I dont know how many sites you host, but if it is more than half a dozen you will be doing youself and you clients a huge favour by considering doing the same. The perfomance benefits and bandwidth reduction (also less server load) alone could make this worthwhile for you, but as a fan of SSL just think of the headaches it could save ... the ability to provide your customers free SSL without you needing to do a single thing on your servers to make it happen. How cool is that?

Whats even cooler, as that fact that it even brings a degree of Authentication back into the picture, 'Cos unlike a shared SSL (still the most common implementation), the CDN provided SSL actually matches the domain names on which they are used. Can it really get any better?

I know I've mentioned the CDN we use several times over the last few years, but for those interested (including website owners, not just hosting providers) the CDN provider is "cloudflare" - costs nothing and can be setup and working in just a few minutes

.... From the same wiki that you probably read about http2.....

CloudFlare supports HTTP/2 using nginx with SPDY as a fallback for browsers without support, whilst maintaining all security and performance services.[73] CloudFlare are the first major CDN to support HTTP/2 Server Push.

Highly recommended. I have no other association with them other than being a very happy user.

[mc12345678]

Very good questions. I can't wait to see the answers :)



This did also cross my mind, especially since it is about the only way that I can think of that would make the OP's request possible,

I wouldn't try it in a million years though - The security implications are *huge*. Just consider the case when (not if) a hacker tries to access the site using "ftp://domain.name:80"

The response will be from the server (port 80), but the FTP client won't render the html/php like a web client - it will show the 'raw' data , and since all URI's will now also be 'ftp' it wouldn't be difficult to have the ftp client load and display the config files complete with DB login details - all in plain text. (normal apache directives and .htaccess rules will no longer apply) ,

Game over.

Admittedly, I've almost certainly oversimplified things here - but the point I'd like to make is that *without* the http/https protocol specifier the opportunity for abuse by other protocols is both huge and unpredictable, so even though what the OP is seeking is possible (using this method) they really *shouldn't*.

Cheers
RodG

I'm staying on this topic for the moment.

I did in writing my previous response attempt to consider such "alternate" attempts to reach the site. But am/would be somewhat perplexed at how such abuse would function... I think at the moment that my head cold is limiting my ability to see it, but at any time one could attempt to load the site using such a protocol and be presented with whatever result is to be afforded, just like if both HTTP_SERVER and HTTPS_SERVER were set to https, if someone visits the site using http then there is no consistent built-in redirect to either of the two constants. Therefore it seems at least on first load such a ftp:// style attempt will provide the same result as any and all subsequent attempts...

Further, and somewhat unfortunately for security but fortunately for development, browsers are offering more onscreen page modification and therefore at any point in a page's presentation such an "insertion" or modification could be made.

Okay, so now that I've written that out, I guess I could maybe see where information from a protocol could be "incorporated" within a request and maybe used/abused because of the way some of the code might be written.

[Website Rob]

@rod

'Cos unlike a shared SSL (still the most common implementation)

I sure hope that is not true. Shared SSL Certs should never have been allowed IMHO and we have never provided them for obvious Authentication insecurity. Is that the pea in your mattress; Shared SSLs?


@mc1-8

Notwithstanding the server has built-in and default redirect methods for handling Protocols and next the .htaccess file has its methods, are you advocating a "script" should also have a built-in default method for handling first load Protocol response and any redirection? I can see where that would cause problems for site owners.

[RodG]

@rod
I sure hope that is not true.
.

Still true - as far as I can determine - but this is changing *rapidly*

Shared SSL Certs should never have been allowed IMHO

Agreed.

and we have never provided them for obvious Authentication insecurity. Is that the pea in your mattress; Shared SSLs?

Yes the lack of Authentication is the 'pea in my mattress' - But you are still *completely* missing what *AUTHENTICATION* actually means, why it existed, and why it has gone the way of the Dodo.

I'm going to try this one last time. OK?

Back when SSL was 1st created, if I wanted SSL on my site (which I did) - I had to *buy* a certificate from a CA , such as Thawte, etc, etc. (there weren't to many of them back then). The cost was ~$1000 - And the reason it/they were so expensive is because before they would issue the certificate they had to verify that:

1) I ran a legitimate business (I had to provide them with details of business registration or similar)
2) A personal ID, such as a drivers licence
3) A copy of the business bank statements to demonstrate that the business hadn't just been created - possibly for nefarious purposes.
4) A phone number that matched the business details.
5) The domain name for the requested certificate needed to be directly related to the business.
... and possibly a few other things.

In addition to a hard copy of these (had to be faxed) they phoned and gave me a 100 questions (ok, perhaps not that many) - but they did phone to ensure the phone was for the business, and so forth. Only when *they* were convinced that I was who I claimed to be they would issue the certificate.

This ensured that people vising our site could *also* be 100% sure that we were legit, and the website rightly belonged to us, and our business. We had been *authenticated*.

Now skip forward to today.

I can register a domain name ($10). Lets say this is called "paypal.com.au' - No one checks if I'm entitled to use this domain name - $10, and its mine. I can also go to any number of sites/business and get a *free* SSL certificate for my domain name (paypal.com.au). No one checks if I'm entitled to use this domain name - No one checks anything. Automatically issued, on the spot.
I next find a hosting company to host the site - less than $4.00pm (I only want it for a month). Hosting company really doesn't give a damn about the domain name I want them to host.

In short, in less than 24hrs I can have a fully functional website 'paypal.com'au' complete with an SSL certificate that not only matches my domain name, but also passes all browser checks) - total cost $14.

I make a near exact copy of the *real* paypal website, complete with login boxes.

I now start sending out emails to all and sundry from my 'paypal.com.au' domain telling people that their PayPal account has been blocked (or has some other problem) and they need to login to verify something.

Unwitting recipients follow the link (taking them to my spoof site). None the wiser that 'paypal.com.au' has nothing to do with 'paypal.com' The email looks legit (coming from what look like a legit PayPal address, the page they end up on looks just like the'real' paypal. They get the 'green SSL icon', and can even view the certificate - paypal.com.au, which completes the illusion, so they proceed to log in ON MY SITE. I now have their PayPal login details. Just to complete the illusion I pop up a 'password failed' error message and redirect them to the *real* paypal site - They sign in there, can't see anything amiss and right off the 'email' as being some kind of mistake, I now have full access to their PayPal account, and no one is any the wiser.

So, even though the site (my phishing site) is fully SSL 'secured' - there really isn't *ANY* security here at all.

So, now lets go back to the days *before* the 'free' SSL certs were readily available (shared or otherwise) , and *authentication* was *required*. Would I risk paying ~$1000 to one of the CA's? knowing that there would be no way to 'prove' that I am, or even work on behalf of PayPal. They would reject the application, and I'd be $1000 out of pocket. Basically, with all the authentication checks needed there is really no way I could get an SSL cert for a fake site, or even one for a new site/business that *may* be set up for nefarious purposes.

IOW, whenever I (or anyone else) came across a site with an SSL cert you/we could be 100% certain that I'm not being phished or scammed, and the site itself is/was indeed owned by the business it claimed to be, and even that the business itself is legit and not just some 'fly by night' .

This authentication and the *security* it provided was so good, that most CA's even offered a financial guarantee that if you were 'scammed or phished' from a site using one of their SSL certs they would compensate for any losses.

- and THAT my friend is what SSL *authentication* was all about, and that is why *I* no longer feel 'safe' just because a site has a 'valid' SSL.

You may fool yourself and the world that 'SSL == security' but it really isn't. It's just encryption <shrugs>

Cheers
Rod

[Website Rob]

You may fool yourself and the world that 'SSL == security' but it really isn't. It's just encryption

And what's wrong with "just encryption"? Let us agree that SSL is "a layer" of security, not an end all be all.

If we look at the levels of SSL Certificates available we see the onus is really on the site owner for the level of authentication they choose.

Shared SSL
- requires a hosting account

Domain Name SSL
- requires a hosting account
- requires CSR
- requires dedicated IP address

EV SSL (Extended Validation Certification)
- requires a hosting account
- requires CSR
- requires dedicated IP address
- requires Phone Call verification, copy of Business License and, if applicable, Date of Incorporation

And we wont' get into the problems caused by an incorrect CA bundle even if the SSL Cert is valid.

Sounds like you are saying everyone should use an EV SSL?

[RodG]

And what's wrong with "just encryption"?

Did you not read, or simply not understand that the 'bad guys' take advantage of the average persons *ignorance* of what SSL does, and doesn't provide? As long as people 'push' the idea that 'SSL == 'secure' then those same 'average' people will be/are happy and willing to enter confidential data (login details) into phishing websites under this *mistaken impression* that all is good and 'secure' . *THAT* is what is wrong with "just encryption". It gives people a *false* impression of security.
My example phishing site will fool almost *everyone* these days that it is a secure site, and in some ways it is - It prevents yet another 'bad guy' from encroaching on their own scam. The original bad guy is laughing all the way to the bank.

Let us agree that SSL is "a layer" of security, not an end all be all.

If you don't mind (and for the sake of this discussion) I'd rather not, on account of the fact that this 'layer' is so thin that it can be equated to blocking a single hole in a colander. (I may come back to this shortly with a real life, real time packet capture of a login page both with and without encryption)

If we look at the levels of SSL Certificates available we see the onus is really on the site owner for the level of authentication they choose

If we go back at the original design of SSL we see that the onus of authentication was in the hands of the CA's providing the certificate. The site owners (both the good guys and the bad guys) didn't get a *choice*. If the site was SSL enabled it was *fully* authenticated. - None of this "If I want a lesser authentication then it is my choice" crap, because it goes without saying, the bad guys will always opt for the least amount of authentication possible so that they than can carry out their phishing scam without question, and without be challenged?
Ignoring any cost issue, what possible reason would a legitimate site owner have of watering down their own level of trust? It simply doesn't make sense.

There was never even a thing of 'levels' of SSL - until the last few years, and if it weren't were for the ease and plethora of *unauthenticated* SSL certificates these days there wouldn't be need for these 'levels'

We have gone from SSL == 100% trustworthy.
to
Free SSL = No trust whatsoever,
to
EV SSL = Lets try to bring back some level of trust because we really fcked up by giving away SSL certs without any form of authentication.

Meanwhile, the poor old end users (customers) have been, and still are, totally oblivious to any of this - I doubt that you could find a single person on the planet (other than those of us that know really knows whats going on behind the curtain) that can tell whether any given website has 100% trust, zero trust, or something in between.

All they know is the little green 'secure' icon - which is applicable and nearly indistinguishable between any of them. Heck, this is the problem even *I* have these days. What chance does the typical internet user have when even someone like myself (who has spent a decade or two with a vested interest in network security) has a hard time knowing which sites can be trusted, and which can't?

Shared SSL
- requires a hosting account

phishing site - requires a hosting account

Domain Name SSL
- requires a hosting account
- requires CSR
- requires dedicated IP address

phishing site - requires a hosting account, requires a CSR, requires a dedicated IP.

If you don't understand why a CSR is required you don't know the components that make up an SSL certificate. In fact this is a *crucial* component of Authentication .

CSR = Certificate signing request. Anyone can create an SSL certificate, for any domain - but it won't function in any way until it has been 'signed' - it is this signatory that is responsible for 'signing' the certificate.

Example: I create a certificate for the domain 'paypal.com'au' - I do this by installing the openssl software (or similar) and running the command
openssl genrsa -des3 -out server.key 1024
I'm prompted for the domain name, location, email addy, and a few other things.

This creates a certificate for my chosen domain. It is currently *useless* and does nothing. It needs to be 'signed' before it can be used.

I now have two choices - I can 'sign' this certificate myself (using the openssl software). This will create a fully functional certificate that basically says 'This certificate is authentic for the domain name I gave - I signed it myself - you can trust me can't you ?

The web browsers, when coming across this certificate will do a check to ensure the domain on the certificate matches the domain of the website, and the encryption is enabled (this prevents 'hijacking' of a certificate/domain) - They *then* check to see who, or which CA *signed* the certificate. If they don't recognize the CA (which they wont with a self signed cert) - They give the alert that states 'Even though the certificate is valid for this domain and encryption has been enabled, I can't assure you that the site is owned by the company they claim to be) - I can't authenticate - Do you wish to proceed - if so, accept this certificate. If it is a bogus site its your problem not mine.

Or, I can submit this same certificate to a CA and ask them to sign it for me. Needless to say, the CA's aren't going to sign it just because I ask - so they do the *authentication* checks (as previously discussed) and if/when they are convinced I am who i say I am, and the domain is really mine they will sign this certificate as per my request (CSR).
When the web browsers now come across this *exact same certificate*they will check that the cert itself is valid (as before) - IOW, the domain name in the certificate matches the domain name of the website, and if so, encryption is enabled - but this time, when they check to see who or which CA signed it - if they recognize the CA it say "Cool. not only does the certificate match the domain name, It has also been authenticated by a 3rd party that I can trust - You are safe to proceed.

The dedicated IP requirement is (or should I was was) ... no, is, a technical requirement because it is used to 'salt' the encryption algorithms to prevent the MITM attacks - it is actually somewhat more detailed than that, but I fear that I'm already *way* beyond anything you need to know (unless you want me to give you a course on cryptography) - If I wanted to really simplify (and scare) lets just say that the current implementation of SSL where many domains can share the same IP address means that MITM attacks can't be fully mitigated with SSL, (in spite of whatever you have read). Basically, the fact that we *can* have SSL without a dedicated IP is another nail in the coffin in regards to encryption being 'secure' against this form of exploitation.

EV SSL (Extended Validation Certification)
- requires a hosting account
- requires CSR
- requires dedicated IP address
- requires Phone Call verification, copy of Business License and, if applicable, Date of Incorporation

This is a relatively 'new' implementation because some smart person finally realized that 'free SSL' with no authentication was a bad idea because it negated the single most important aspect of SSL - *authentication* , which by now has long gone the way of the dodo. It is a 'token' effort (best attempt) to bring back what had been lost with the plethora of unauthenticated SSL certs that are now commonplace. The end user (regular folk customers) still can't tell the difference between an authenticated cert, an unauthenticated cert, or an EV (token authentication - single phone call but no actual proof that the site hasn't been created specifically for nefarious purposes).

What is really 'clever' about this one is that even though the typical user can't tell one type of cert from another (bearing in mind that there was at one time only one type - and that one was 100% secure/authenticated) - it actually plays on the 'warm fuzzies' that it gives to the site owner. It's a bit like saying 'hey, I have paid some money here, and even had a phone call, so *my* certificate is 'better' (more secure?) than my opposition that is using a free certificate. What these site owners don't realize, is the customers really don't care, or more precisely, they don't know the difference - Putting it in less polite terms - Site owners that pay for these 'EV' certificates are suckers.

And we wont' get into the problems caused by an incorrect CA bundle even if the SSL Cert is valid.

Hmm, no, lets take this further - firstly we need to define what constitutes a 'valid' SSL certificate. First and foremost - *any* certificate that has been created for a given *host* that matches the host on which it is found is *valid* *please note - I said host, not domain* Until now, I've been using the term 'domain' rather than host. My mistake. Anywhere I've said 'domain' above - please ignore - I *really mean 'host' - in many cases, the domain *is* also the 'host'. (This is pretty important to understand, because it has a direct relationship to both authentication and encryption - eg: 'mydomain.com' could be authenticated but 'paypal.mydomain.com' could be a phishing site on a totally different server that has no association whatsoever with 'mydomain.com' (DNS hijacking) - This is why certs were once, and generally still are, only issued for a given host, and why a cert issues for 'mydomain.com' would produce and error if/when someone goes to 'www.mydomain.com' (or vice verci)

A self signed certificate is just as 'valid' as a $1000 Thawte Authenticated certificate, which is just as valid as an 'EV' certificate, which is just as valid as a free certificate from any source you care to mention. They all provide the exact same level of encryption. All are equally 'valid' (as long as the hostname in the cert matches the host (site) on which they are found.

So, now lets consider the 'CA bundle'. Firstly, there is no such thing as an 'invalid CA bundle ' - There are just two options here - A current 'CA bundle' or an obsolete 'CA bundle' - I guess you could consider an obsolete CA bundle as 'invalid' - but the more important thing is that that the 'CA bundle' that (I assume) you are referring to, is the one found on a webserver. This is *not* quite the same as the CA's that are found/used by the various web-browsers - The CA's in the web browsers are constantly updated with each new release of any given web browser. The CA's in the web browsers are used for the authentication processes when a person visits an SSL enabled website. (is this SSL cert self signed, was it signed by a company I can trust, was it signed by company that has gone rogue, and so forth.
The CA's found on a web server, serves the same purpose, but from the perspective of the web server - 'Hey. I've been asked to connect to paypal. Is the certificate I'm seeing legitimate? Has it been revoked, has a new certificate been issued and signed by a CA I can trust' and so on. IOW, the 'CA bundle' on a server server serves the same purpose as the CA's embedded into all the major web browsers, but they tend to be more static and often/occasionally need manual updating, depending on the server. IOW, the CA Bundle on a webserver can be as obsolete as fsck, and it will have no bearing/affect whatsoever on any persons visiting the website. - simple put, it is incoming data vs outgoing data. (from the servers perspective).

I don't wish to offend, but the mere fact that you encroached the topic of 'CA bundles' tells me that your understanding of SSL is severely lacking. It is nothing to be offended about - I'm trying (probably unsuccessfully) to teach you in a single post (or two), what took me 6 months of full time study to fully comprehend, but more than that - it is sh*t that most people don't even *need* to know. I am making this attempt because unlike most people, you are NOT the just the end user/customer, you run a hosting business, you *should* know more than the typical internet user - even though there is really no technical reason reason for it - I simply feel that in your position, you should know more than your clients - plus the fact that since you *do* run a hosting business you really are a lot smarter than the average bear - If I didn't believe this I really wouldn't be trying to 'teach' you these things. You really are a smart guy Rob, I've no doubt about that whatsoever - but heck, you frustrate me no end in that in regards to SSL/Security you seem to fall for the same fallacies and misinformation as the 'typical' end user that barely know how to turn a computer on.

Sounds like you are saying everyone should use an EV SSL?

Yes/no
If the typical end user knew how to tell whether EV SSL was being used, vs Authenticated SSL vs Free SSL (none of which was ever an issue/consideration when SSL was 1st devised) - Then heck yeah - EV SSL is far better (for those end users) than 'free/shared' SSL could ever be - it provides a token amount of authentication at a relatively small cost, compared to 'full' authentication, but the fact is, the end user/average person doesn't 'see' this, so it is a 'sucker' implementation that serves no purpose other than to to extract $$ from web hosts that would be equally served with a free SSL.
Even if you opt to pay ~$1000 for full authentication you, as a webhost, would be no better of for it, simply due to the lie that SSL == 'security'

Sorry, but this has taken me far longer than i had anticipated, as such I've not been able to setup and show you sniffed login page data to demonstrate how pointless encryption really is in comparison to Authentication (which is also pointless these days) - but like I said, I'm trying to teach you in a single message or two, what took me 6 months of full time study to learn.

My final words - Does SSL == security - No. I still feel less safe shopping online now than I ever have in the past.
Is SSL in any way secure? No, not any more - Might just as well use ROT13 (Google this if you've never heard of it before).

Is the encryption aspect of SSL a viable/valid 'layer of security? Yes, if you don't trust those that you should be able to trust anyway. (your ISP/Internet provider/webhost/NSA), otherwise, no, it as as useful/secure as plugging a single hole in a colander.

Rgds
Rod