@Gwen-Dragon Thanks Gwen, that worked perfectly fine! 🙂

Hi, Good news. I actually didn't notice you giving me location of the certs earlier. I compared it now and found the fault. The issue was in permissions. I had ls -lah /home/username/ | grep pki drw-r--r-- 3 username username 4.0K Apr 27 2017 .pki I did chmod -R 700 /home/username/.pki/ ls -lah /home/username/ | grep pki drwx------ 3 username username 4.0K Apr 27 2017 .pki Which fixed the issue. Thank you for thorough investigation.

Despite of several Loud Throats here I completely agree with the subj and with thouse who named present state as "security theater", as with who pointed that Google isn't Idol in the UI. If the fact of this EV presence is such important just move detailed info into tooltip or "Site info" popup and use a different padlock icon with a big fat checkmark over it.

@Gwen-Dragon its working now, the browser accepts saving a login-password again 0_1550216127584_4cee789d-01bd-432f-98b0-251feb422898-image.png the last thing about the obsolete cipher suite will hopefully be away, when the server was migrated from Server2008R2 to Server2016; unfortunately Server2008R2/IIS has no support für SHA-2 but it's green in the browser and working

Thanks everyone! I will check with the company IT department regarding the certificate issues. I am still puzzle though over why it works on 2.2.1350.4, but i guess it has to do with this upgrade: Upgraded Chromium to 71.0.3578.27 Thanks! Regards, Collin

@patrik_halfar manual addition of entries was supported via vivaldi://net-internals/ until the option was removed by the according Chromium update. HTTP headers are only the most common way of distribution. The cert (or CA for that matter) is not in the loop for PKP. If the server does not have the matching private key for the requested domain (or the trust period expired), the client will throw an error. If website operators are not up to the task to renew entries in time, there are deadlocks. This happening regularly unfortunately lead to Google pulling the plug (public reason) without (as you mentioned) an adequate replacement. The difference in the suggested feature is to use a cert hash with expiration bound to cert lifetime instead of a public key hash with expiration supplied by the user (or server). Subdomain inclusion is covered in PKP as well.

Vivaldi has a real opportunity here to innovate in a big way with such a simple design change. For example. Something like this would not work anymore? https://twitter.com/musalbas/status/1038919152826757122 Why? Because the full domain would be shown instead of the full URL. This is exactly the sort of thing the URL address bar can prevent with this. Vivaldi can then advertise as a feature the new anti phishing address bar.

For a self-contained hacky workaround, I would setup a local transparent proxy for each internal website. E.g. with Caddy: https://localhost:1443 { # or even setup a nickname in your hosts file, then add it here after a comma e.g. https://service1.local:1443 tls ../cert.pem ../key.pem # tls self_signed # alternatively, Vivaldi allows you to trust problematic localhost certs automatically (--allow-insecure-localhost) proxy / https://service1/ { transparent websocket insecure_skip_verify # this tells the Caddy proxy to ignore the website cert problems, and proxy it regardless } gzip log ./access1.log errors ./error1.log } https://localhost:2443 { tls self_signed proxy / https://service2/ { transparent websocket insecure_skip_verify } } # …

@gwen-dragon Thanks!