Fix non-working certificates

My team provides X509 certificates for many use cases inside of the company network. One such use case is to use them for a sandboxed web service identity. Almost every company engineer uses these web services to test their changes to web sites and APIs in preproduction.

The company has a lot of sites and APIs, so we have thousands of different web service identities. The sandbox certificate had all possible identities encoded as subject alternative names because we didn’t know which identity engineer would use. It led to the size of these certificates going beyond supported for several clients like OpenSSL library, IE11, and mbedTLS library. So engineers won’t be able to test their resources in such cases. This problem started a couple of years ago but no one had time or hands to fix it.

We were adding more and more web service identities on a weekly basis as company resources grew. I realized that these problems eventually will block more and more dev engineering flows. I decided to fix it before it totally blocks everyone.

From one of the engineers, I learned that the web services supported TLS Server Name Identification. It allowed a web service to have a list of X509 certificates and choose one based on a requested host in TLS Client Hello. The solution came naturally out of it. Let’s define an upper limit of subject alternative names one certificate can have. The limit will guarantee a supported size across all libraries. Instead of generating one certificate, we will generate N certificates based on a total number of identities divided by the upper limit.

I was able to prototype the solution to prove the point. I implemented required changes in Certificate Authority service, client, and provision workflows and able to fix a many-year problem for the company engineers.