Hello everyone, and happy 2019. I’m back writing the first blog for the new year and to inform my dear readers, whoever it may be, of the status of my project. Hoping back into the project, the only problem that I have to deal with now is getting the automatic installation of client certificates to work. I had run into some major problems regarding this, as I had outlined in a previous blog.
Anyways, looking back into it, nothing good still came out of it. One of the option I was aware of was the <keygen> HTML element attribute, but at the moment only Firefox still supports it, while Chrome has already drop support for it, while other browsers may or may not support it. Either way, it would be removed eventually from all browsers, since its already been deprecated from the Web standards. For the other option, I was considering to use the Web Crypto API to generate the key pairs in the browser, but the problem is accessing the browser’s local key store to store the generated private key, while the corresponding public key gets uploaded to the server. There’s no JavaScript API to access the browser’s key store, so this can’t be done as well.
In actuality, the right way of automatically installing the client certificate into the browser, is for the server application to return the contents of the certificate with application/x-x509-user-cert as the MIME type. The condition for its successful installation is that the corresponding private key should also be in the browser’s key store, which would have been done by the <keygen> element. So the problem is getting the private key into the key store.
It is crucial that we try to make the certificate installation process more user friendly. This is because, ordinary users are not used to importing a certificate into their browser, certificate enrollment is only used by companies for their employees to access the office network these days. However, at the moment, the user downloads the PKCS#12 and has to manually import into the browser. Since the users would be under a subscription, having them doing the manual import every month, for example, would ruin their experience. Although fully aware of this, I was at the stage of almost giving up, as it just seems I hit a brick wall at every turn.
Suddenly, Dr Shawn had an epiphany. When a PKCS#12 gets imported into the browser, the private key gets stored into the browser’s key store. Therefore, the user should manually import the PKCS#12 for the first time. If the server application generates and stores the public and private key, then we can always reuse the private key for certificate renewals, and the new x509 certificate can be returned with the appropriate MIME type for automatic installation. The browser would have to accept the certificate, since the corresponding private key is already in their key store from the manual import of PKCS#12.
That being said, I still needed to test out if it actually works. At that point, I was only able to test it out with Chrome and Firefox only. For Firefox, it worked like a charm, but on the other hand, for Chrome, the certificate got downloaded as a normal file. When the file is clicked from the download pop up at the bottom of the page, it redirects to the certificate management page, but does nothing after that. So a manual import is still needed to be done. It turns out the Chrome also deprecated the special handling of the application/x-x509-user-cert MIME type. How frustrating can this get? 😞
Assuming that nothing else can be done, this is the best we have got so far. It is better than having the user navigate through the settings and get to the certificate management page, on a frequent basis. But to do this, I would need to make some changes to the backend as well. Dr Shawn gave me till the end of the month to finish everything, including the setting up of the store and testing 😱.
0 Comments