Things like this are no longer possible as an extension, which is why HTTPS Everywhere lost a bunch of the security features it used to add.
An extension would also run a whole new instance of the browser, which is totally overkill for such a feature.
As for usefulness I remember people saying similar things about showing any form of HTTPS or cert info at all, due to worry that users won't understand.
Users lack understanding because they are kept in the dark all the time. This is the big difference between the old Amiga world and the Windows world.
On the Amiga OS you get lots of visual feedback and so learn passively what the normal operation to expect is.
When the feedback differs from normal or shows something unusual, you do not need to be an expert to realise something is amiss and needs to be checked.
Lets say you land on a site and see the message in the browser that the encryption has been downgraded. What does this mean ?
Downgraded from what to what, and where does the user see that this is normal or abnormal behaviour for the site in question ?
Unless a user tests the site they do not know what cyphers should normally be in use on a site they frequent.
Just having a small amount of visual feedback somewhere obvious is enough to teach people to pay attention.
It can help all of us spot if something has been compromised in the browser or site.
@mows said in SSL Handshake Error (CERT_PKIXVerifyCert Bug 2013):
ich habe mir das Cert noch mal vorgenommen und exakt so gechained - es hat funktioniert, und die Fehlermeldung ist ebenfalls verschwunden!
Ja. Gut so!
Wird es aber, wenn ihre Produkte das Zertifikat anerkennen? Oder ist Google/Chromium da einfach laxer im Umgang mit den Checks?
Ich weiß ja nicht was das los ist, inwieweit Chrome was anders machen könnte.
Vielen Dank für die Hilfe und die unglaublich schnelle Aufklärung
Aber sicher doch, gern geschehen.
@hstoellinger a further requirement is not met when called via (that) command line:
Certificates must have correct SubjectAltName fields, using CN (CommonName) for host matching was disabled more than a year ago.
Use an openssl config file to consistently create (renewable) certificates.
It comes in handy the 3rd time you will have to fiddle with options until you get them right.
Settings for a special webdomain are at chrome://settings/content/siteDetails?site=https%3A%2F%2Fsecure.comodo.com
But you can not set any key generation in Vivaldi, such setting does not even exist in Chromiums.
The Comodo page gave you a wrong information about key generation.
I remember that something changed since Chromium 57.
@chas4 Yes, all user blogs.
It is a server issue where the server forgot to send all certificates in a connect.
That results on connection errors on some browsers.
But on Windows and Linux all is opened fine. Seems a Mac-only problem.
@Hadden89 said in Certificate info missing from the address bar:
I hope vivaldi keep on the flag jumping to chr60 ^^
Yes, if you get the (i hope, the first) Snapshot Vivaldi with Chromium/60.x that link will be brought back. There is no need and sense to disable such link.
It is planned to give users a better information popup for certificates of a visited page. But i do not know about the progress.