Leo Laporte (15:35)
No communing here. Okay. So based upon the feedback I've received, as I said over the past week, we appear to have hit it out of the park with our first podcast last week of 2026. I received a bunch of feedback about each of the major topics we covered. And no one complained about my spending time sharing what I learned firsthand about magnesium. In fact, many of our listeners want more. So from time to time, you know, again, this is not going to be the nutrition podcast, but again, we're all together. All what, 100 or 100,000 plus of US aging as a group. And we've been at this for 21 years, so we're getting there. I was gratified to find a great deal of unity over what's going on in our industry regarding the shortening of certificate lifetimes, coupled with the concomitant rising costs of code signing since last week's three hour podcast, which, you know, couldn't have handled any more content. I stumbled upon a terrific blog post that was so on point that I want to begin with it. This week. Much as I began with the this same topic last week by looking at in this case an a different aspect of code signing. The guy's name is Rick Straw. His post was this past Summer on July 20th and he made a he he he tweeted a few days before that. I'll share that in a second. But He he posted July 20, 2025 from Hood River, Oregon. He gave his posting fighting through setting up Microsoft Trusted Signing. And while I share what Rick wrote, please keep in mind that no matter how much this guy may sound like me and may be echoing my recently expressed sentiments, this is really his own original writing. So you know, he's further evidence, I guess that, you know, I and our many listeners who have expressed an opinion are not alone and are not off base in raising an extremely skeptical eyebrow at the recent changes that have been occurring and which will be adversely affecting everyone who wishes to author code going forward. So here's what Rick wrote He said so it's that time of year, actually the time of several years to renew my code signing certificate. I always dread this because it's a manual process and invariably if you're not intimately familiar with the complexities of public key cryptography, the terminology is enough to drive you batty. It's gotten easier since I made some decent notes the last few times I went through this, but all that's out the window this time around because the code signing rules have changed drastically. It actually happened a few years ago, but I was lucky and got my local still exportable certificate just before the rules changed. So I was able to freeload for at least nearly three years on the old certificate plan. The new rules don't allow for locally stored exportable certificates. Instead certificates have to be served from one of a few certified online authorities or the certs must be stored in a FIPS142 Level 2 compliant hardware security module. The keys cannot be exportable so they effectively cannot be copied and stored or used elsewhere. So you got the option of a server provided keys or hardware keys. The idea behind this is to stop keys getting jacked and being used by the non originating organization so the new keys are one time generated and non exportable so that they are much more restricted. Online services issue certificates that are good for only a few days when you can use them to sign with and then automatically roll over to a new certificate. What all this means the complexity of getting a certificate has gotten exponentially worse and along with that prices have gone up significantly. Base non EV certs run in the 350 to 500 range with fully verified EV certificates starting around $500 per year. What used to cost me $180 for three years the same provider now wants nearly $1,000 for, he says. Yikes. It all seems like a huge grift. Okay, now in his posting Rick, as I mentioned, then posts he quotes a separate tweet which he had posted two days prior to this blog posting. On July 18, Rick posted to X he said as it is the whole code signing thing has turned into another scam of X and shidification of a captured audience. If you're publishing software or even packages on Nouget now you pretty much have to have a code signing certificate. Certificates that used to be 100 to 150 or less for multi year certs per year a few years ago now cost 300 to 400. For basic certs the EV cert start at 500 and go up from there. The validation rules for businesses have not changed and you would think most of the expense is all in that. But this isn't about security, it's about gatekeeping and just one more hurdle for a small business to have to jump over. So that was his his tweet then he continues turning his attention to Microsoft's Azure Cloud Signing solution. He writes, Microsoft is in the game too. Microsoft, who requires these code signing rules in the first place for Windows Smart Screen validation and also for other things like NuGet packages, is also providing an Azure service called Trusted Signing to provide code signing services. So they're on both sides of that transaction. Create the problem, provide the solution. To their credit, their pricing is much better than what most traditional SSL cert providers are now charging. Azure Trusted Code Signing is still in preview, but then again it's been in preview for well over two years. But it looks like what you see and what and what can sign up for now is in the final stages before going to a proper release as a service. One reason to look at Microsoft Solution despite the potential pain and suffering he writes, is that the pricing is quite good as of the time of this post. So and then he has a little chart. The base price monthly is $9.99. The premium as opposed to basic per month is 99.99. The quota as in maximum number of signatures per month for the basic 9.99 cents is 5,000 signatures per month. Then an over quota is half a cent per signature. So $0.005, you know, half a penny per signature. Once you've gone over 5,000 per month for the premium plan, which is that, that the hundred basically $100 99.99. You get 100,000 signatures per month and then the same half a penny for each of the signatures over that. So he said these are non EV base certificates. Oh, so that means the, the basic, the, the difference between basic and premium is not signature quality. Which makes sense, right? Because we know you don't get any benefit anymore for EV from Microsoft, so why charge more for it? But it's, it's quantity of signatures. So for 5,000 signatures, for $10 a month, basically for 10 times that fee, a hundred dollars a month, you get 20 times the maximum number of signatures before you start having to pay per signature, you get a hundred thousand signatures. So he says these are non EV base certificates that only do basic vetting. For fully vetted EV certificates you'll need to look elsewhere. This pricing, which ends up at a hundred and about $120 per year for the single cert, is cheap compared to most of the SSL vendors. Most, most of which start at around $300 for certificates with mailed hardware keys, meaning they, you know, postal mail, they send the key to you, then you plug it in and you're good to go. He says. So you got to give Microsoft credit here for keeping costs down and providing reasonable pricing. The certificates issued by Microsoft are very short lived with expirations that last only three days to aggressively thwart invalid signing attacks in case a certificate certificate is compromised. Thus the title of today's podcast, three day Certificates. We're going to look at the mechanisms behind that, he says, doing a bit of research. Out of all the bad options out there, Microsoft's trusted signing seems like the least bad solution that's also cheaper than traditional certs from various SSL vendors. The good news is that it works and pricing is reasonable. The bad news, I wasted nearly an entire day trying to get it to work. Hopefully this post will help you. Reading will help you reading this not to wait will help. So he means those of you reading this not to waste quite so much time. And he then his next section he titled Navigating the Azure Jungle. I'm not going to go through it all, but I'm going to touch on the beginning of this. He said if you end up going the Azure trusted signing route, plan on having to wade through the Azure dependency jungle of setting up several resources and trying to understand what all the mumbo jumbo Azure jargon amounts to. If you're doing Azure all day, then much of this infrastructure Dance will be familiar to you. But as someone me, he wrote, who only occasionally jumps in for some very specific services like trusted signing, it's incredibly painful to deal with Azure security and the resource dependencies and the endless nesting of services with badly defined and overlapping naming boundaries. For trusted signing, finding documentation via search engines was hit or miss. The docs for this are buried behind deeply nested links, perhaps because it's still in or just out of preview, he says. Parens even that's hard to tell since some prompts show preview. None of the headlines do, he said, and also because previous releases of this technology used a completely different publishing pipeline through the Azure key vault, he says there's official documentation, although it took me a bit to discover it, and he put a link in the blog posting and I copied that link into the show notes, so that's there, he says. This has everything you need, but the instructions require some interpretation. The tools are terrible and the docs don't make working with them a lot easier by making you figure out where to find files and dependencies and how to install tools. Don't believe you're lying AIs, he wrote. In this day and age of AI assistants and chatbots, you would think that that things like Azure configuration instructions for setting up an Azure task would be readily available. Heck, there's even an Azure specific copilot model that you can use from the VS Code Copilot integration. But that actually yielded surprisingly bad results and did not work well with Trusted Signing either for setup or for the signing part. Part of this might be because Trusted Signing is still in preview or because the documentation for this is almost non discoverable and because things have changed so much with the tooling. Long story short, after a very pissed off day of going down many wrong paths, I managed to get Trusted Signing to work for my projects and I'll try my best to provide the details how I have this set up, hopefully sparing a few of you all the pain I ran into. Okay, and that at this point I'm going to stop almost, he said. So so this is about the first 10% of Rick's entire blog posting. Throughout the next 90% of his posting, he painstakingly and charitably details the the entire process of setting up Microsoft Azure Cloud Code signing. I've got a link to his detailed instructional posting in the show notes and I also gave it a GRC shortcut just to make it easy for everybody to find GRC SC Code sign all one word GRC SC code sign will bounce you over to this blog posting of Rick's where you'll see the first 10% is what I just shared and the other 90 are like how he solved the problem. He finally wraps up this terrific setup walkthrough with a summary that's also worth sharing here. As you'll hear, Some of this assumes that by now, by the time you've gotten to here, you've managed to slog through everything that he wrote which preceded it. So he sums it up by saying the process to set up trusted signing was way harder than it should have been. In fact, the entire process took me the better part of an entire workday. The server process is complicated primarily because the nomenclature is so crazy confusing and the dependency management on Azure is such a pain in the ass. The missing rights from the account to create an identity is particularly maddening, and how you fix it is even more so. But it wouldn't be Azure if you weren't cursing the thing every step of the way. The signing process is also a pain in the ass with three different tool chains required. The fact that an Azure Trusted Signing command line interface add in exists but doesn't actually support signing is just ridiculous. With all the resources that are thrown in Azure, it seems petty to not support the one feature that everybody is going to need without having to jump through hoops of managing several tool installation instructions. But somewhat grudgingly, I have to say that at the end of the day, the process works, warts and all. Microsoft's comparatively lower pricing for the service compared to others maybe makes it worth it. And frankly, the fact that I have my cert running as a service that hopefully doesn't ever need to be updated unless I quit the service is enticing. Yeah, it costs more than it did last time around. I'm now paying almost as much every year as I used to pay for three years. But given the circumstances and and the insidification that now surrounds the entire code signing process, this is the best we can do for now. I'm hoping writing this up is helpful to some, and that these instructions won't be obsolete in a few short months because Microsoft changed their designs again, as is so often the case. Despite that I finally got it to form, one would hope that they fix its performance. Maybe he meant to perform one. Oh yeah, despite that I finally got it to perform, one would hope they fix its performance. He and he said five to eight seconds per file to sign with no parallelism for multiple submissions is bad.