@luckyluc0902 Ah, ok. Fine. 🥳 The in tag this Resolved.

@adam2222 I could not imagine that your .pki folder had the wrong permissions. You can be happy that you found it. Enjoy now browsing with your own certificates.

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.

@FBorrmann Thanks for your feedback. Now you can use Vivaldi as your favorite browser tool.

@collin-obol Did my advice typing thisisunsafe had helped you?

@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.

@gwen-dragon It is already possible (in the Linux version) to import server certs (not tested for CAs) via the basic UI chrome://settings/certificates on the Server section. After import the trust flags are wrong (,, instead of P,,) so the cert is shown in Others instead of Server section and without posibility to change trust flags. I'm not shure if this is a Chromium bug or intentional design choice. In bug case: Might be a good idea to dispatch this to Vivaldi or upstream devs. In design choice case: A better integrated and more comlete cert managment interface for Vivaldi with Better overview of cert trust states (no modal window for show/edit) Option to restore default settings for builtin certs might be the more useful in general. The regular Windows import (in CA section, no separation for server certs) on the other hand adds a number of unnecessary permissions. It might be possible to wrap this operation for easier access and a more limited cert feature set.

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!