As time goes on, the details and requirements of the project start to emerge themselves progressively. At this point of time, we have two kinds of products, one for individuals and another for organizations. In the case of organizations, they have the choice of buying an intermediate CA certificate and manage the issuing of new certificates themselves, or they entrust us with that process. Now if it is the latter option, the intermediate CA certificate will be stored in our servers. There is actually a third kind of product as well, i.e individual certificates belonging to an organization, however they are dynamically created when an organization buys the intermediate CA certificate.
The reason this is being done so is because those end-entity certificates need to inherit certain attributes from their parent certificate, i.e the intermediate CA. This is crucial for identifying that such a certificate belongs to a member of the organization. Other than that, the product would also needs the ID/fingerprint of the parent certificate, so that when the order is made, the new certificate gets signed by the correct intermediate CA. All these would be attached as product attributes. Hence, this means that each organization will have a special product for their members to buy from.
Apart from creating that product, coupons would also need to be dynamically created. They are to be used by the members of the organization to purchase the product at a discounted price. The number of coupons to generate as well as the the rate of discount is up to the organization themselves.
Progress and Frustrations
So now on to what I have done for this week. I have implemented the sending of emails for both individuals and organizations. The difference between both is that individual emails have a download link to the certificate, while the organization email has their CA certificate and its corresponding private key bundled in a PKCS#12 file as an attachment. Recall that it is only for organizations that want to manage the issuing of new certificates themselves. All those are fine and dandy, but the problem now is how to actually get the browser to automatically install the certificate for the user.
I’ve found some clues on how it might be done. There are actually certain MIME types that enables the browser to identify what kind of certificate is in the HTTP response, and then proceed to add that certificate in its local database. The MIME type that should be relevant to our case would be application/x-x509-user-cert . I’ve already set up a simple REST API endpoint to return the certificate with that MIME type in its Content-Type header. However, since it returns a PKCS#12, this doesn’t work. Even after returning the certificate in its PEM format, the browser would throw an error saying I do not have the corresponding private key for the certificate. Bundling both the private key and the certificate itself in PEM format yields the same error. After a little more research, I found out that there are more specific MIME types for PKCS file formats as well. The MIME type for PKCS#12 would be application/x-pkcs12. I thought I already found the answer, but using that MIME type makes the browser download the file itself without actually installing it automatically.
I have decided to work on other things first, such as the dynamic creation of the product and coupons. So far I already have a template for the product and some code to make the request, but I have yet to test it out. I guess that’s all from me for this week.
0 Comments