Checking Our TLS Trust Stores After the eMudhra CA Compromise

We've deployed updates to DocSpring's hosted service in response to the eMudhra certificate authority compromise. The changes cover our HTTP clients and PDF renderers. If you use our hosted API, these updates are already in place.

We had to follow the TLS configuration through our HTTP libraries and PDF renderers, because an application can use several certificate stores at once.

According to Mozilla's investigation, eMudhra generated intermediate CA keys that were weak enough to recover from the public certificates. An attacker with those keys could create certificates for other people's domains. For a susceptible HTTPS client, an attacker who could intercept its connection could then impersonate the destination.

Browsers distributed protections through their certificate revocation systems. Many server clients don't receive those updates, so they needed separate fixes. The certificate authority that issued your own website's certificate doesn't determine which authorities your application trusts when it connects to another service.

DocSpring makes outbound HTTPS requests to deliver webhooks and fetch resources used in PDFs. Our Debian application images picked up the updated ca-certificates package, which removed the affected trust roots. That covered Ruby clients using the system certificate store, including Net::HTTP.

But the versions of Stripe's Ruby library and Excon that we were using also shipped their own CA bundles. Those bundles still trusted the affected chains after the system store had been updated. We configured both libraries to use the patched system bundle. A successful check with curl alone would have missed that difference.

Our HTML-to-PDF renderers needed another change. Chromium uses a separate certificate trust configuration. We launch it with --disable-component-update, so it wasn't receiving the CRLSet updates used to block the compromised intermediates in Chrome. We installed an explicit distrust policy for the affected intermediate certificates and updated the renderer's system trust store as well.

We tested requests against the disclosure's test hosts, including chains through both the eMudhra root and the cross-signing authority. The application clients rejected those connections after the changes. We also checked that connections to the external services those clients use still succeeded with valid certificates.

For the PDF renderer, we tested certificate handling inside Chromium and through an actual staging render. The affected hosts failed verification while resources with valid certificates still loaded. We then deployed the updated application and renderer images to our hosted service, and verified the application clients in production.

If you're reviewing your own application, check the certificate source for each HTTP library and browser runtime in the deployed images. Look for bundled CA files and settings that affect revocation updates. Test the paths your application actually uses, with both rejected and valid certificates. The disclosure page maintains test hosts and package-update information to help with that review.