"There is a problem with this website's security certificate."
We've all seen them at some time, and when I do, I back out from the site where such an error exists. Is that still the best advice?
On a well known site, is it just sloppy management that causes such an error, or is the site really a risk?
[edited by: engine at 4:26 pm (utc) on Dec 15, 2010]
mack
11:20 am on Dec 15, 2010 (gmt 0)
I think the site is a risk because of the reason you have given... "sloppy management that causes such an error" it always makes me think, if they are sloppy with a cert, are they sloppy with security in general.
Mack.
lammert
3:15 pm on Dec 15, 2010 (gmt 0)
I have seen it happen with high profile sites. It often happens if the secure part of the site is moved to another (sub)domain without the webmaster thinking twice or testing it. Sometimes it is because the certificate expired, or the website owner installed a home-signed certificate, instead of one from an authority.
Given how easy the installation of certifcates is (most certificate issuers provide step by step instructions for installing them) and how cheap they are; not buying, installing and testing a proper certificate for a site is a big red flag IMO.
engine
11:17 am on Dec 16, 2010 (gmt 0)
Amazingly, this latest certificate error is an ISP.
lammert
11:51 am on Dec 16, 2010 (gmt 0)
That is nothing. Even Google has certificate errors on their ccTLD domains. For example on [google.ru...] which serves the Russian Federation.
wheel
3:17 pm on Dec 20, 2010 (gmt 0)
Yeah, I've seen security cert errors on my linux distribution.
Most of the security cert errors are bogus anyway, as is most of that entire industry. No reason why we shouldn't self-issue certificates for most situations but we don't. Why? Oh yea, browsers will give you a security cert. error.
engine
5:30 pm on Dec 20, 2010 (gmt 0)
I'm slightly confused (easily done) by what you're saying. Is it imortant or serious? In this instance of the ISP, it's meant to be an account area with https logon.
lammert
6:21 pm on Dec 20, 2010 (gmt 0)
I think I understand wheel's comment.
Certificates are used for two different things. One is encrypting the data stream to make it impossible to be read by a third party. The other use is to ensure that the website or site-owner is who it/he pretends to be.
In the first situation self-issued certificates work just as good as certificates issued by an authority. In the second situation you need a trusted authority which checks the validity of the submitted website or owner information.
Most certificate errors in browsers come from an authentication matching problem. Either the root authority mentioned in the certificate chain is not recognized by the computer, or the domain the certificate is served from is not in the domain list of the certificate itself. In both cases the authentication of the certificate fails, but the encryption of the data stream is still working.
Many sites only need data stream encryption, not a validation of the website or owner. That is where a self-issued certificate should be allowed.
wheel
10:51 pm on Dec 28, 2010 (gmt 0)
I'm slightly confused (easily done) by what you're saying. Is it imortant or serious? In this instance of the ISP, it's meant to be an account area with https logon.
As Lammert notes, encryption still works fine no matter what your browser is complaining about.
I've never seen a certificate error that mattered, i.e. one where I didn't just ignore the error. The encryption matters, not the 'who owns the site'. It's the 'who owns the site' part that is such a load or nonsense.