On a previous blog post, I talked about the flow of my project in detail, but then I realized that I was missing something important. The crux of the matter was I mentioned that when the customers have made the order and paid for the subscription, the certificate would be created and an email will be sent to them, with a download link provided to install that certificate into the browser. This actually only applies to individual users. What about the case for organizations?
For organizations, they will have the option of whether we issue them an intermediate CA certificate and they manage the issuing of end-entity certificates signed by that intermediate CA themselves, or they entrust the certificate management to us. If it is the first option, then the application only needs to email them the certificate file, and anything that happens after that is up to them. If it is the latter option, then the intermediate CA certificate would be stored in our own public servers.
To authorize access to our applications, the members of the said organization needs to acquire their very own client certificate that is issued under the intermediate CA corresponding to that organization.
PKCS#12
Individual certificates and the organization certificate that needs to be sent over by email has to be in the PKCS#12 format. It is basically a file format for bundling the x509 certificate along with its private key. This is the required format in order to install the certificate in the user’s browser. It is totally fine to send an organization their certificate in this format as well, since they need both the certificate and the private key for signing new client certificates anyways.
To my surprise, Botan C++ does not have any APIs for encoding the certificate as PKCS#12. Therefore, my other option for doing so was to use OpenSSL API libraries. An example of creating the PKCS#12 with OpenSSL can be found here. Note that the example loads the certificate, its private key and CA from their respective PEM files stored on disk. However, it seems ridiculous to export the certificate as a PEM file after creating it with Botan and then load it again to be exported as PKCS#12. To avoid that, we could load the newly created certificate in memory, by first storing it as PEM encoded in an std::string, and then using the BIO_new_mem_buf() API, which returns some OpenSSL datatype to be used in PEM_read_bio_X509(). The same is done for the CA certificate, and its private key, except that PEM_read_bio_PrivateKey() is used instead. In the project, all these are put in a wrapper class, so that if Botan were to support PKCS#12 encoding in the future it would be easy to change.
And that’s a wrap, for now.
0 Comments