Last post I mentioned how to setup the original TLS certificates in Azure Web Apps. I mentioned this history because it is the common history which most of Azure customers have built web applications. Azure has been busy creating a more secure platform tackling these fundamental problems which every customer experience. This post I’ll introduce what autorotation is.
Autorotation is the complete replacement of certificates in application use without human touch.
It’s the responsibility of the software engineers to setup an engineering system or application workflow to help achieve this.
Why is autorotation important?
As a junior software engineer or even a consumer you may have seen this type of error when browsing websites.

This is the simplest explanation of how consumer information can be compromised and even your application may be vulnerable to attacks. It reduces the attack vector for any form of public-private key pair using certificates. Rotation every 90 days or more frequently in an automated removes the possibility of an attack to exploit use of a compromised private key + public key pair. If you read more on security StackExchange there is an excellent question about the purpose of rotating TLS certificates.
The main point is to avoid the need of CRL or OSCP to revoke a compromised certificate.
- Certificate Revocation List (CRL) maintains a list of endpoints for which the certificate should verify if it has been revoked.
- OSCP protocol is used to communicate to a server to indicate whether the certificate has been revoked.
A CRL check is what makes your browser report an Error and prevent attackers from stealing information:

Before dismissing this as low priority:
Consider no support for Android/Chrome on CRL or OSCP. The argument is that is that in most cases if network connectivity for OSCP is blocked by the attacker the application will soft-fail and still accept the certificate as validate. The only mitigation is to sign the application and prevent any unsigned application from running. This would prevent interception of any network traffic including that of OSCP checks. Additional reading is found on this StackOverflow question. The post will eventually take you to a great explanation of why CRLs and OSCP is a weak form of protection.
The point is:
Short lived certificates are an easy and reliable way to prevent private key extended exposure.
Next week, I’ll go into more details about how a high scale Azure service would implement something like this.
