It was about time to start writing some code since I already got the gist of how the application is gonna work overall. Nothing much has been done at this point, but so far I had set up two REST endpoints to handle both Subscription Created and Updated webhooks. As mentioned before, the Subscription Created endpoint is responsible for saving the subscription ID into the database temporarily as well as marking it as a subscription CREATED event. That’s all it does. Then, when Subscription Updated hook is triggered and the status of the subscription becomes ACTIVE, all the necessary data are extracted from the webhook’s JSON payload to create the certificate and store it in some directory, until the user downloads it from a link in the email that will be send shortly after.
It is easy to create the certificate using the Botan C++ library. I know that all the information regarding the user should be stored in the Distinguished Name (DN) attributes (e.g: Country, State, Common Name, etc). The fingerprint of the parent certificate, aka the Intermediary CA that issued the new certificate, is stored in the Organizational Unit (OU) attribute.The Subject Alternative Names (SANs) like email can be obtained from the WooCommerce billing info, while the IP address or Domain Name is obtained from the product attributes, which means that an organization is buying the certificate.
There is also other extra information that needs to be stored somewhere in the certificate. I do not know what those will be at the moment, but it should not matter since they are all gonna be strings in the application anyways. The problem is finding an appropriate place in the certificate to store those “features”, as coined by Dr Shawn. The only DN attribute that is not being used is the Organization attribute, but it seemed very inappropriate to just stuff unrelated data into it. At first I thought of using the Pseudonym attribute to store the “features”, but the current version of Botan we are using only has a limited number of DN attributes to specify before creation, which excludes the Pseudonym attribute.
Dr Shawn then suggested to use one of the x509v3 Certificate Extensions instead. Unfortunately, the Botan library only supports a limited number of Certificate Extensions as well, and they have specific usages which are not suitable to store the “features” at. If its not too difficult to do so, I may need to define my own Certificate Extension class that extends Botan’s Certificate Extension base class, worst comes to worst. It is frustrating, to say the least, since its taking more time than it should to just store those “features”. We’ll see how it goes in the next blog post.
0 Comments