I think there's currently no way to permanently ignore the certificate error. You can temporarily ignore it for a single session by clicking Technical Information -> Accept Risk and Proceed.

I think you're probably requesting the feature described in bug #765364, right? I'll mark this as a duplicate... let me know if that's wrong.

*** This bug has been marked as a duplicate of bug 765364 ***

Not exactly a duplicate, though certainly related.

The workaround for bug 765364 is to save certificates manually and install them using ca-certificates.

This works for sites that have defined their certificates correctly. This isn't the case with https://cp.us2.net. The certificate works, but contains the CN (Common Name) "www.foundationapi.com" and no alternates. Though the certificate has been saved and installed, it isn't referenced for cp.us2.net because the name doesn't match.

Firefox also fails to use the certificate when it relies on certificates installed with ca-certificates. However, when it saves the certificate internally, it matches it to the host it downloaded it from. The certificate downloaded from cp.us2.net is used when going there.

Maybe there's an easy way to devise a workaround for the workaround so the faulty cp.us2.net certificate works correctly?

If not, then yes, it belongs with bug 765364 :-)

I think what both bug #765364 and this bug are requesting is a way to pin certificates to particular sites, right? Then the connection would succeed if the certificate is unchanged, and not otherwise, and no certificate validity checks will not be performed at all. So the solution is really the same, right? It doesn't make any difference whether verification fails because some intermediate certificate is missing or because the common name is wrong.

Agreed. The only reason to take this first is that it's already possible to save certificates for Epiphany. Bug 765364 is more difficult because it asks for the process to be made easy.

The problem with cp.us2.net shouldn't be hard to replicate. Maybe there's a simple solution? (If not, then as you say, it gets fixed along with the solution for Bug 765364.)

(In reply to Technical Support from comment #5)
> Agreed. The only reason to take this first is that it's already possible to
> save certificates for Epiphany. Bug 765364 is more difficult because it asks
> for the process to be made easy.
> 
> The problem with cp.us2.net shouldn't be hard to replicate. Maybe there's a
> simple solution? (If not, then as you say, it gets fixed along with the
> solution for Bug 765364.)

It won't be simple. Epiphany will need to save a copy of the certificate into a new local database. The database would be a map of hostname -> certificate. Then Epiphany needs to check if a hostname is present in that database before each page load. That's the easy part. The hard part would be to hook into the TLS connection establishment, because Epiphany needs to verify that the certificate presented in the TLS connection matches the certificate stored in its local database. The right APIs for this all exist in GLib, but not in WebKit. In fact, it's hard to think of how that might ever be possible: there's a process boundary involved here, so it's not possible to expose the actual GSocket and GTlsConnection involved in the WebKit API. So designing any API that would allow Epiphany to implement its own pinning would be quite difficult.

It's possible to get the TLS certificate after the connection has been established, and check if it's right then. Some GNOME applications (like Banshee) are known to do just that. But that's wrong: if the verification fails, sensitive state (like secure cookies, or local databases) has already been leaked.

I think it would be much easier to add this functionality at the WebKit level rather than Epiphany level, since then the new WebKit API would be comparatively straightforward: there would just need to be a function, say webkit_web_context_set_tls_certificate_pins, that would allow passing a GHashTable of hostnames to certificate PEMs to indicate which certificates are pinned. Then that's just a bunch of strings, which will be easy to ferry across to the network process, and the network process can implement the check there. That's probably the best path forward here.

Either way, it's going to be several days of implementation work, and not a priority for me, unfortunately. Workarounds like this were more important 10 years ago when certificate verification errors were common on the web; nowadays it's quite rare to see a completely broken server like this one. Especially sad that it's a government website which nobody can access without clicking through a big scary and important browser security warning....

Now, there is an alternative. Epiphany could easily just turn off certificate verification altogether for a given hostname, by storing a database of websites for which no verification should be performed. The downside is that Epiphany won't be able to block the connection if the certificate changes unexpectedly, so unlike the Firefox approach, this would be completely turning off all security checks permanently (which is reasonable; that's currently what Epiphany does now, just for the current session instead of permanently). I don't plan to work on this either, but this should be straightforward for a new contributor to implement.

Thanks for the information and I *definitely* see your difficulty.

The idea of saving a list of websites that automatically turn off certificate verification is actually a good one. Right now, I install certificates for people who don't know how and only run into trouble when someone has to hit the ignore button themselves. As you say, the warning is scary :-)

Having a friendlier warning would be nice but if I could make the warning go away altogether, that would be best. With a saved certificate, if possible, but a simple list of excluded websites would be almost as good.

Or maybe a command line option to skip certificate verification? I don't mind a little effort if it's easy for the end user.

(In reply to Technical Support from comment #7)
> Or maybe a command line option to skip certificate verification?

I don't think so. ;)

*** This bug has been marked as a duplicate of bug 745351 ***