I recently attended a workshop about app/web product design. The presenter asked us to think of a well and badly designed app. Dash sprang to my mind as an example of the latter. While its design is an ongoing issue, it happened at least once that its server certificate expired and users couldn’t do payments.
We all have seen it – I go to visit an interesting blog, DEFCON website, or pay for your parking on the go. But I can’t – the website or web service has an expired certificate and the “damn security wouldn’t let me do it”.
We have finally completed a GLOBAL certificate look-up table for real-time notifications in our re-designed KeyChest service. KeyChest has been using an external service to check for new certificates. This has become unsustainable due to the number of users and certificates we monitor.
We have handed over the first deployment of our CloudFoxy (smart cards over RESTful API) for PDF signing and it is now in live use. Here are a few observations of mine about dependencies, performance, and delivery.
Our certificate monitoring KeyChest has an initial RESTful API for remote enrolment of new certificates and for checking certificate expiry. Its design supports automation without any initial security/authorization setup.
This text is about creating a process around planning certificate renewals. As part of our KeyChest re-design, we created a sequence of meaningful checks for TLS certificates to get them always renewed before your web services go down.
We checked recent statistics of the KeyChest service. While the overall load is gradually increasing, we also increase the number of checks we perform. It’s now over 500,000 a day since March 26. But we should be fine till a major system upgrade coming soon.