|
|
The same bug happend to me to with - Chromium 55 on Ubuntu 16.04 - Vivaldi 1.6 64 Bit on Ubuntu 16.04 - Edge on Windows 10 But I could create a new certificate with - Firefox 50.1 on Ubuntu 16.04 |
|
|
Some other checks to create new certificates: it does NOT work with - Edge 38 on Windows 10 - Opera 42 on Windows 10 - Vivaldi 1.4 on Windows 10 it works still with - Firefox 48.0 on Windows 10 |
|
|
I filed a bug at Chromium and at Vivaldi a few days ago. Following the answer from Chromium: Issue 799246 in chromium: Cannot create a certificate with cacert.org Absender Von: asa… via monorail Updates: Components: Internals>Network>Certificate Status: WontFix Comment 0000003 on issue 799246 by asanka@chromium.org: Cannot create a certificate with cacert.org https://bugs.chromium.org/p/chromium/issues/detail?id=799246#c3 This site is using the <keygen> element to generate a keypair. This feature is deprecated. See https://www.chromestatus.com/features/5716060992962560 Attachments: Screen Shot 2018-01-05 at 4.44.07 PM.png 22.1 KB -- You received this message because: 1. You reported this issue |
|
|
"Since Chrome 49, <keygen>'s default behaviour has been to return the empty string, unless a permission was granted to this page. Removed in Chrome 57." "IE/Edge do not support <keygen> and have not indicated public signals to support <keygen>. Firefox already gates <keygen> behind a user gesture, but is publicly supportive of removing it. Safari ships <keygen> and has not expressed public views regarding its continued support." source: https://www.chromestatus.com/features/5716060992962560 |
|
|
keygen.png (22,621 bytes) |
|
|
Further information at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/keygen "Deprecated This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Avoid using it and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time." |
|
|
Alternatives to <keygen>: https://w3ctag.github.io/client-certificates/ https://w3ctag.github.io/client-certificates/ Other discussions about alternatives: https://stackoverflow.com/questions/36350954/html-keygen-alternative-generating-key-pair-in-browser https://security.stackexchange.com/questions/106257/alternatives-to-htmls-deprecated-keygen-for-client-certs Further readings: https://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/pX5NbX0Xack |
|
|
https://developer.mozilla.org/de/docs/Web/HTML/Element/keygen https://productforums.google.com/forum/#%21topic/chrome/FGU6TvIgPY0;context-place=forum/chrome https://support.comodo.com/index.php?/Knowledgebase/Article/View/475/0/which-browser-can-i-use-to-signup-for-a-email-certificate |
|
|
Generating keys still works for me with Firefox 57.0.4 (64-Bit, Linux) installed in openSUSE Leap 42.3. |
|
|
On Fri, 2 Feb 2018 10:29:41 +1100, Peter Yuill <peter AT NO SPAM c.o.> wrote at CAcert Board List: I went through the process of generating keys and CSR in openssl then submitting CSR through the advanced section of “New Certificate” and it worked perfectly for me (using current Firefox). I have to say it is not a simple solution and it certainly requires a much higher level of technical skill than the browser solution, but it does work. I did some research on possible tools to simplify the process and I have a proposal. As far as I can see the browser route is dead, so we need to look elsewhere. I am looking at the possibility of a desktop app that would generate keys and CSR then connect to the cacert.org <http://cacert.org/> site through a screen scrape library to submit the CSR and store the certificate back in a local keystone. The one extra step required is to import the certificate into browsers/mail clients, which should not be difficult for most people. I am starting work on a cross-platform proof of concept which I hope to be able to demonstrate in a few weeks. |
|
|
"The browser route is dead" - indeed, so solutions running natively on the platforms are necessary. A technical discussion thread was started here: https://lists.cacert.org/wws/arc/cacert-devel/2018-04/msg00000.html Supporting many platforms can be challenging. Because a simple solution is better than none, I'd prefer to have console-based scripts using on-board tools such as openssl (usually available for UNIX-style systems) or certreq (on standard Windows since many years - Vista?) as a baseline. Automating the CAcert certificate request page is not essential for the simple tool variant, where a graphical, more powerful and comfortable variant can complement it and doesn't need to cover platforms on an equal level or have the same robustness. For UNIX-style systems I created a shell/openssl based solution as proof-of-concept here: http://70t.de/download/ , file with pattern cacert_client_certificate_<date>.tar.xz (at time of writing cacert_client_certificate_2018-04-11.tar.xz ) Read more on cacert-devel starting here https://lists.cacert.org/wws/arc/cacert-devel/2018-04/msg00000.html |
|
|
I tried out cacert_client_certificate_2018-04-09.tar.xz. Thanks for creating it. I have a few suggestions/remarks about it. A) Multiple inputs of a passphrase are required: 1. Unlock the key (from the file generated in the first task) ----- 2. Set a passphrase for the new certifcate file 3. Repeat (confirm) the passphrase from 2. above Input area (sequence of 3 passphrases): [1. Unlock key password] Enter Export Password: [2. passphrase for new cert] Verifying - Enter Export Password: [3. repeat 0000002] The three numbered items should be explicitly numbered and named in each of the prompts that come after. The first prompt of "Input area (sequence of 3 passphrases): " does not indicate that you are supposed to type on the "passphrase to protect the generated key" when generating the RSA private/public key pair. B) If ready, press enter to open the certificate with the browser for import. [ In the case of Firefox 59.0.2 (64-bit), Ubuntu 16.04.4, a dialog box will ask What should Firefox do with this file? (*) Open with [View file (default] ( ) Save File [ ] Do this automatically for files like this from now on. [OK] Questions about passphrase and labels eventually displays the certificate details but is not imported. I had to go to Firefox's Certificate Manager and manually [Import...] the newly created new_certificate_$USER.pfx file. You will need to unlock the .pfx file with the "Enter Export Password: [2. passphrase for new cert]" from above. ] |
|
|
Oops. That note should have gone to the mailing list where cacert_client_certificate_2018-04-09.tar.xz was posted. There is no edit/delete. |
|
|
It is nearly three years since this issue was raised. Has there been no viable alternative process found for generating client certificates without the deprecated keygen tag? Would it be possible for someone to write a HowTo guide for manually performing the process on the command line using OpenSSL and putting a corresponding CSR submission form on the website for the server side part of the process. |
|
|
Could something like this be used? https://pkijs.org/ |
|
|
Here is an example that uses that code: https://csrhelp.peculiarventures.com/ |
|
|
Here's another option: https://www.php.net/manual/en/function.openssl-csr-new.php |
|
|
As a reply to https://bugs.cacert.org/view.php?id=1417#c5828 there indeed is a workaround for this problem. If you click the "show advanced options" checkbox you can provide a manually created CSR, which makes the keygen tag obsolete. But the process in not really easy or user friendly. See https://wiki.cacert.org/FAQ/CSR as a starting point if you want to try that way. |
|
|
I had a (very short!) look at the proposals of BarryN. https://www.php.net/manual/en/function.openssl-csr-new.php will probably not help us, because this is code that runs on the server. It would not be appropriate for our standards to create a keypair on the server and then send it to the browser, because of the additional risk of compromising the key on the server or during transfer. BTW, this is the reason why CSRs have been invented. https://pkijs.org/ looks more promising to me. As the provided example shows, the library seems to be able to create a keypair and a corresponding CSR locally in the Browser. If the library uses the key storage of the browser for key generation and therefor does not have access to the private key itself, this may be a valid replacement of the keygen tag, since this is exactly what the tag does. But, first of all, this assumtion has to be verified by a code review. If the library creates the private key "itself", therefor having access to it, this also imposes the risk that the private key is compromised during the creation process. Another downer is the sentence "Safari, Edge, and IE do not have complete, or correct implementations of Web Crypto.", which once again leaves a significant portion of the browser market uncovered... Nevertheless, if there's anyone who would like to give it a try it may be worth to do more research in this direction. |
|
|
The 'downer sentence' was from 2015. Almost all browsers are supported now. To see what is and isn't supported visit https://caniuse.com/#feat=cryptography |
|
|
I thought the java script solution might be the better one. I have tested a few browsers and the basic functionality seems to work. According to the chart the current version of IE, Edge, Chrome, Firefox and Safari all have at least basic support. |
|
|
New Client Certificate.png (175,952 bytes) |
|
|
From a mail on the Support mailing list: Hallo zusammen, seht Euch mal die Library PKI.js an. Das ist ein Werkzeugkasten in Javascript für alle Operationen auf X.509 Zertifikaten. Damit kann man im Browser erzeugen: * Keypair * PKCS#10 CSR * PKCS#12 File Das PKCS#12 File muss der User dann nur noch in den Browser importieren. PKI.js kann deutlich mehr, als das alte <keygen>, damit kann man z.B. auch EC Keys erzeugen. |
|
|
What's the state of play? What happened to the app from Peter Y? What happened to the proof of concept from dops? What about pkijs.org? What happened to the Java Script solution? What about the library PKI.js? As a technical layman, I do not really understand it. The approaches sounded promising. Were they pursued further? |
|
|
same here as L10N here and hoping some type of solution would be soon proposed. |
|
|
Looking into https://pkijs.org/ once more. It seems possible to create a web page which could replace the key creation with openssl where openssl is not readily available (like on Windows): - Create a key pair with the generateKey API - Create a PKCS10 CSR with a user provided data for CommonName and SubjectAltName using the CertificationRequest class of PKIJS - Show the PEM encoded request to the user for Copy/Paste - The user must then paste the CSR into the CAcert web page, and use Copy/Paste to copy the created certificate into the PKIJS-based website - The PKIJS based website combines key and certificate in a PKCS#12 (*.pfx) structure which can be downloaded by the user This PKCS#12 structure can be imported into Mozilla's certificate database or into the windows certificate storage. Of course this also has the potential to be integrated in the CAcert web page, which could eliminate the Copy/Paste operations, but I'd consider that as the second step. The main problem I see is that the creating script knows the created private key and could easily compromise it (intentionally or unintentionally). This is essentially the same as in an openssl based script, but since the script is loaded on demand from some webserver, as well as several libraries, the potential of fishing-like abuse is IMHO considerably greater... Nevertheless it could be an easier-to-use variant for Windows users. |
|
|
Regarding download: Search engines present solutions for locally creating files for "download". The first link looks like a clean and modern solution, which is also later mentioned behind the 2nd link with a longer history: https://shinglyu.com/web/2019/02/09/js_download_as_file.html https://stackoverflow.com/questions/3665115/how-to-create-a-file-in-memory-for-user-to-download-but-not-through-server So should be promising that all private key related operations can be done locally in the browser. |
|
|
I've tried a "proof of concept" implementation at https://secure.convey.de/publish/ted/TestPKI.html The PKCS#12 file created there can be parsed by OpenSSL, but neither the Windows Certificate Storage nor Thunderbird/Firefox are able to use it for import... :-( Probably there's still some research necessary about the details of PKCS#12 creation... |
|
|
I implemented a GPL-2+ licensed proof of concept based on the Forge JavaScript PKI library (https://github.com/digitalbazaar/forge) with a small Go backend using an example openssl CA. The PoC can be found at https://git.dittberner.info/jan/browser_csr_generation and can be built/run using the instructions in the README.md file contained in that repository. I could import PKCS#12 files created by this PoC project successfully in Firefox and the GNOME keystore (Seahorse). |
- Anonymous
