After several years of developing my main Ruby on Rails project on my personal MacBook Pro, (like any sane developer), events have conspired to push me back to using my ossified corporate laptop for development. I didn’t expect to mind too much.
Even though I’ve worked almost exclusively on a Mac for all these years, I’ve always made sure that the corporate laptop can do the job. I have admin access (so many places won’t allow this), so I can install Ruby via RubyInstaller, and go from there. I’ve even been able to install some nice-to-haves, like a good git GUI. (Tower, which, on a Mac is sublime, but at least has a Windows versions, and is dual-licensed, FTW.)
What I wasn’t prepared for was the change in the workflow. Any tool that doesn’t use the Windows networking stack has to include the corporate firewall cert in its trust chain to access the internet. In the past, RubyInstaller has handled this “SSL problem” for bundler. I’ve had to work it into npm as well.
However, I’ve upgraded my app to Rails 8, and RubyInstaller’s Ruby won’t run the app server any more, so I’ve been forced into using WSL. Now, I tried this early on (when it was a translation layer), and quickly decided that it was terrible, and fundamentally broken for Rails development. Microsoft rather quickly admitted defeat, and released a version 2 (which was a full VM). “It does what it says on the tin,” but I’ve avoided it ever since, because native Ruby worked just fine.
Also I can’t use Kamal to deploy the app to a Linux VM, because that relies on key-based SSH authentication, and my company simply doesn’t allow it. I mean, are they supposed to support the industry-standard way of deploying web apps to Linux hosts or something!? Are you crazy? They have to put every session through Cyberark and log every keystroke, right!? So now I’m also forced to containerize the app, and deploy it to Azure’s Web Apps for Containers service, which is a terrible product with the worst dev tooling I’ve seen in 20 years of cloud services.
So now I’ve spent literally days working out how to deal with the SSL problem in several more contexts.
First, you have to get the WSL Linux made aware of my corporate certs. On Ubuntu, that involves putting them in /usr/local/share/ca-certificates and running update-ca-certificates.
Okay, that wasn’t too bad, but it was still a new trick I had to learn.
Second, you have to get the Docker image of the app aware of them, so that when you build the image, the build process can do things like install packages and bundle gems. In the Dockerfile, that involves something like:
COPY ./script/misc/certs/theirs/firewall_bundle.crt /usr/local/share/ca-certificates/firewall_bundle.crt
RUN update-ca-certificates
Easy, right? It’s the same thing.
Now there comes the problem of the az command. I tried to debug why my ASP container wasn’t running my image, so I naturally tried to do az webapp log tail... because the online version of the log viewer in Azure’s web portal is literal trash, and takes forever to scroll to the bottom. This has led to many hours of working through the issue with AI.
The first error messages were, again, about SSL. After several back-and-forths, AI finally pointed out that the error messages were from Windows, and I had to learn the harsh lesson that WSL will “fall through” to running Windows binaries if it doesn’t find a native one. I complained to Claude, and he said:
“Yeah, the Windows PATH passthrough in WSL is one of its worst design decisions.”
So I installed the native Linux az command, and still the horrors persist. So I tried patching az‘s Python environment to include the certs. Then I got even weirder errors. Something about the corporate certs being broken because they don’t have an “AKI extension.” I complained again to Claude, and he said:
Yeah. To summarize the chain of absurdity you just had to debug:
- Corporate firewall does SSL MITM with a malformed cert (missing AKI extension).
- WSL silently falls through to the Windows az. exe instead of telling you it’s not installed.
- Linux az ships with Python 3.13, which is stricter about certs than anything else on your system.
- AZURE_CLI_DISABLE_CONNECTION_VERIFICATION works for half the code paths but not the one you need.
- The Azure CLI’s own log streaming function doesn’t honor its own disable flag.
None of that is your fault. It’s layers of bad defaults and incomplete implementations stacked on top of each other.
An independent search on Google about SSL AKI gave me this snippet:
Validation Issues: If the AKI is missing, malformed, or does not match the issuer’s SKI, it can lead to certificate verify failed errors, particularly in strict environments like Python 3.13 or with outdated proxies.
Uh… yeah. No kidding.
This is your brain. This is your brain on Windows trying to do anything that resembles modern web development. I can work around this, but, dang. Between Microsoft and #CorporateIT, this is so much harder than it needs to be. What a disaster. And I know what I’m doing.