So I managed to implement the reusing of private keys as part of the renewal process. The problem was that I was calling the wrong API for Botan, which yields an unexpected outcome. Shortly after that, Dr Shawn wanted me to implement one more feature for the application. It basically involves checking whether the user receives the email for the certificate download or not. This can be done using the Post Office Protocol version 3 (POP3).

When we send the emails to the customers, each of those emails would also be BCC-ed to a specific email address, in which the POP3 server would periodically pull email messages from that address inbox into its own inbox. On the application side, a REST API is set up so that when a GET request is submitted to that endpoint, the server application would get a list of those emails from the POP3 server. For every new subscriptions or renewals, the application saves data temporarily in some table in a database, so that it could be used as part of the certificate download process later on. Each entries of that particular table has its own unique random UUID. We could place that UUID into one of the email headers, in which for now I put it in the FROM header, as part of the sender email address. Hence, once we get the list of emails from the POP3 server, we use the UUID stored in the FROM header and cross check with the database.

If the email exists in the POP3 inbox, but the corresponding entry does not exist in the database, then it would mean that the email was sent successfully and the user has downloaded the certificate. On the other hand, if email does not exist but there is corresponding entry in the database, it means either that the email was not sent successfully or has not reached the customer yet. Thus, the timestamp in which that particular entry is created would also be checked. We would have a window time period, where that entry could remain in the database. But if it happens to be older than that window time period, it is marked as some anomaly. Any anomalies detected would send an alert to a specified email address, listing all the subscriptions that are having problems. Also, everytime the POP3 server is queried for the list of emails, each of those emails will be deleted so that it does not have to store them for long periods.

I was also able to implement it by this week, but have not tested it out yet. Dr Shawn had already given me access to the deployment server for me to test the application in production, so I might as well do it there. As you can see from this point, the application is almost ready for a beta release. But I should not be too lax yet, as I still have to make sure that everything is functioning as expected in the production environment. More to come in the following weeks.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.