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

@madiso A sensible move. We will add additional EV information to the identity panel instead, effectively reducing the exposure of EV information to users while keeping it easily accessible.

@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 } } # …

This seemed to be the same as Setting to Ignore Missing SSL Certificates Merging the threads did not work as intended, so I split them again. Please vote for that thread if it is what you want.

@dantesoft Because this's Linux, probably the old Cert land in user profile. I doubt OP Cert package from his/her distro repository outdate/broken in any way. Except, he/she never update the cert package. Edit: typos

@gwen-dragon Thanks!