There is nothing much to be said for this week. The only implementation I’ve attempted to get done for this week, is the part where the server application interfaces with the WooCommerce REST API, in order to create products and coupons, when an organization makes an order for a certificate. Even so, I have yet to get it fully working, as I have some weird issues with boost::json parser.
Regardless, not too long after that, Dr Shawn gave me access to an account for CAcert.org. It is basically a non-commercial certificate authority that allows the public to have server or client certificates get signed by their root certificate, free of charge. Anyhow, the purpose of him doing so was to hope that maybe I could learn about the process of how they are able to install the client certificate into the browser automatically, which is given as an option to the user when they create a new client certificate. As what I had done previously, they were using the application/x-x509-user-cert MIME type as well when returning the new client certificate from their server. However, the only difference is that they generate the public and private key pairs in the browser itself, and then the public key is uploaded to their server, so that it can be signed by their root certificate, and generate the corresponding certificate. This is supposedly the correct way for most CAs to do it, since the private key should not be anywhere as other than in the user’s possession. Hence, the client certificate was able to be installed without any errors.
In our case, our problem is that the creation of the public and private keys and the certificate generation are all done in the server side, which is why I got the missing corresponding private key error when attempting to install the certificate directly into the browser. If only we could follow the way it is being done by other CAs. Few years back, there was a <keygen> HTML attribute, that allows the creation of public and private key pairs within the browser and submits the public key to the server in a HTML form. It has been deprecated, unfortunately, for some reasons. On the bright side, though, there are alternatives to the <keygen> attribute, namely employing the use of the Web Cryptography API, which is part of the web standards. Taking that into account, we would need to rethink the application’s flow for creating client certificates.
0 Comments