GNOME Bugzilla – Bug 618429
Add login certificate support (client-side SSL certificates)
Last modified: 2018-08-03 19:28:59 UTC
Some websites allow to log in using a certificate. It works find with Firefox, but not with Epiphany. An example of a website using this is http://myopenid.com. The principle is that the browser generates a certificate and gives the public key to the server that stores it for later usage. The login is (I suppose) a TLS session using the private certificate sorted in the browser. Here is the text used to describe certificates on https://www.myopenid.com/settings_authentication > Click the button below to install a secure client certificate into your Web browser. Your browser > will use your certificate to prove your identity to myOpenID using Transport Layer Security, or > TLS. Using this certificate avoids the necessity to enter any sensitive information, such as your > password. > > This certificate will be installed on the hard drive of your computer. If you use more than one > computer, you will need to install a certificate on each of them.
This feature is used by many sites like bank account access. Most of the browsers have it. And if I remeber well, also the old epiphany based on gecko was supporting it. Could you please add it soon? Is there any issue to support this. In addition, according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560310 and to bug 594856 the certificate manager is not working. So maybe these should be fixed before this one cold be fixed. Please advice if you need any additional information.
I'm also interested in supporting this feature.
The lack of support for even client certificates added via the GNOME "Passwords and Keys" tool breaks any use of Epiphany with my company's operational and dashboard tools.
Just to update the version information, I'm running Epiphany 3.8.2 on Fedora 19.
The libsoup part is now done in master; you can set a GTlsInteraction on the SoupSession, and that will get used by any GTlsConnections it creates. You'll still need to create a GTlsInteraction implementation with the certificate-fetching behavior you need, and whatever UI is going to be needed.
*** Bug 594856 has been marked as a duplicate of this bug. ***
I confirm this limitation is still present in 3.14.1.
I've heard Chrome is planning to drop client-side certificate support.
> I've heard Chrome is planning to drop client-side certificate support. Do you have a link for related discussion (even speculation) on this?
No, sorry, I forget where I read it a few months ago, and it's not easy to Google for. The basic premise was that almost nobody uses client certs so almost nobody will care, they're very confusing for nontechnical users, and two-factor auth is more than good enough for most sites. That doesn't mean we necessarily have to WONTFIX this bug, especially since most of the work is already done in libsoup, and it's just waiting for someone who cares to hook it up in WebKit and expose API for Epiphany to use. But it does mean this is a much lower priority now IMO. If Firefox decides to follow along, then I would WONTFIX this.
(In reply to Michael Catanzaro from comment #10) > they're very confusing for nontechnical users Well, in their defense, they're very confusing for technical users too. OK, so that's not a very good defense. Do any of the people who "me too"-ed this bug before still use sites that need this feature? (Interestingly, https://fedoraproject.org/wiki/Using_the_Koji_build_system still explains how to install client certificates into your browser, but then nothing else on the page actually discusses using the [authenticated] web interface to koji rather than the command-line interface, leading me to wonder if everyone has just given up on trying to make that work...)
> Well, in their defense, they're very confusing for technical users too. It's an awful chicken-and-egg issue. We set up all of our certificate generation and installation using the <keygen> tag, which had a really clever way of generating a private key, a certificate-signing request, submitting that request, and allowing the browser to install the combined private key and certificate. That makes things super easy for users, but <keygen> is now deprecated because (surprise) it wasn't widely deployed because most human-accessed, web-based applications don't use or support certificates. Anyway, we'll just be moving back to fully server-side certificate creation, which isn't perfect from a cryptographic architecture but meets our needs fine. > Do any of the people who "me too"-ed this bug before still use sites that need this feature? Yes. We use it extensively, especially for internal systems that are jointly accessed by automation clients and humans. It's just nice to issue from one authority for machine clients and another one for our humans; the actual backend can distinguish the two but not have to support two different authentication standards. If it looks like more than a rumor that client certificates will be removed from the major browsers, though, we'll probably move those systems to SAML or OpenID Connect.
(In reply to Dan Winship from comment #11) > (In reply to Michael Catanzaro from comment #10) > > they're very confusing for nontechnical users > > Well, in their defense, they're very confusing for technical users too. > > OK, so that's not a very good defense. > > Do any of the people who "me too"-ed this bug before still use sites that > need this feature? At least in Spain, all the public administration websites use client side certificates to authenticate users so you could pay your taxes etc... Adding this to WebKit will be a killer feature for a lot of people I think. I'll definitely take a look.
BTW I forgot to update this, I've a local working branch for the webkitgtk changes. Just need to add some default UI for the feature, and then we could add something to epy.
Oh cool surprise. I was thinking about WONTFIXing this, but if it's mostly ready then great. Since this feature is extremely rarely-used, I think the UI doesn't have to be great or fancy, just a way to choose the certificate to be used, and a preferences dialog for changing it would be good enough.
(In reply to Michael Catanzaro from comment #15) > Oh cool surprise. I was thinking about WONTFIXing this, but if it's mostly > ready then great. > > Since this feature is extremely rarely-used, I think the UI doesn't have to > be great or fancy, just a way to choose the certificate to be used, and a > preferences dialog for changing it would be good enough. Well in Spain for example you can request a user certificate to access the electronic services of some public administrations: paying taxes, request grants etc... so having it would be extremely useful and not rarely used at all. Regarding the UI I agree, I would propose something really minimal (although I think we should provide a signal in webkitgtk so that clients could implement their own)
Sergio, is the branch available anywhere? I'd like to give a spin! :)
(In reply to Emanuele Aina from comment #17) > Sergio, is the branch available anywhere? > > I'd like to give a spin! :) Just worked on the WK part. I'll try to post a patch soon even if not complete. Regarding the ephy part, I haven't started yet so you could take over.
Hehe, in fact I was more interested in the WebKit part of it. :D
Sergio, did you have the chance to publish the WebKit patch anywhere, even if it may still be rough around the edges?
(In reply to Emanuele Aina from comment #20) > Sergio, did you have the chance to publish the WebKit patch anywhere, even > if it may still be rough around the edges? Same question. Is there a WebKit bug?
(In reply to Michael Catanzaro from comment #21) > (In reply to Emanuele Aina from comment #20) > > Sergio, did you have the chance to publish the WebKit patch anywhere, even > > if it may still be rough around the edges? > > Same question. Is there a WebKit bug? Yes there is, Emanuele took over long time ago. Here you are https://bugs.webkit.org/show_bug.cgi?id=164509
Oh, sorry for the misunderstanding, sadly interest shifted away from this feature and I haven't had the chance to do any work on it. :(
Please develop its necessary to grow the project epiphany. If not develop this feature the browser is unusable and never begins a principal browser. Its a good browser but needs develop this feature. thanks.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/142.