Why is PKI so hard? – Tales from the Crypto

Why is PKI so hard?

I’ve spent much of the last several years working on PKI – Public/Private Key Infrastructure – in one way or another.  But I’ve been doing it as a developer.  I’ve frequently found myself frustrated by incorrect documentation where I’ve had to deduce, from samples and trial-and-error programming, what the correct documentation should be.  I’m on a mission to beat Microsoft over the head with those incorrect pages until they get them updated and corrected.  [Yeah, I know, working for Microsoft, for free, is a dumb idea]


But partly, I expect that – developing PKI and related solutions, such as SSL and encryption, probably should be hard, because if you don’t understand it in depth, you will get it wrong [I’m dealing with a vendor right now that crows about “double encryption” and “encryption with the source’s private key”, which are usually strong signs that they “just don’t get it”].  Naively, I assumed that this pain of PKI was restricted to developers.


My new job changed all that.


I found myself tasked with publishing an Infopath Form on a Sharepoint site.  Easy enough, except that if you want the Form to do anything interesting, you have to give it “Full Trust” (a phrase that should put shivers up the spine of anyone working in security).  To make sure that your users fully trust the Form, you have to sign it, and you do that using a certificate whose purpose is to sign code (not document signing, because the Form is really code, not a document).


Great – that’s easy.


Your company should have a root certificate authority for enterprise certificates, and there should be an enterprise-wide certificate for code signing.  They’re easy to create.


The non-easy part comes next, as you realise what the user experience is going to be.



The user is going to visit the Sharepoint page hosting the form, and they’re going to see a dialog box with several buttons.  This dialog box warns them that something bad is going to happen to their computer, and warns them away from allowing it to happen.  When they obey that warning, the form doesn’t display, and they don’t get to do their job.


Should I solve this with user education?


No, because then I’m teaching my users that if they’re presented with this roadblock, they should simply click the magic buttons that let them see the naked dancing pigs.


I should solve this by deploying the certificate to my users’ desktops (not the users, because I don’t want them running this form or other signed code on the server machines!).


Easy – just follow the instructions.


Uh… what instructions?


In the interests of brevity, I’ll save you how long it took me to search for a document talking about deploying certificates, but I eventually figured out that what I was doing was the same as distributing a certificate for an Authenticode-signed application.  The right search brought me to a page on “Trusted Application Deployment Overview“.  Maybe by the time you click on it, Microsoft will have fixed the page, but it says (as do a number of other pages on this topic) “If you are deploying your application in a managed desktop environment; for example, a corporate intranet running the Windows operating system; you can add trusted publishers to a client’s store by creating a new certificate trust list (CTL) with Group Policy. For more information, see Create a certificate trust list for a Group Policy object


Oh, hey, that link doesn’t take you to anywhere like the article you want to read.  Here, let me fix that – Create a certificate trust list for a Group Policy object.  Great, now we’re ready to go.


So, we create a GPO, we set it to disabled (wouldn’t want to accidentally roll it out until we’re ready), and go ahead and add in our certificates.  In goes the root CA, with no problems.  Now for the code signing certificate.


What’s this?  “The certificate is the wrong type” – what’s that supposed to mean?


Off to the system at home to try it out there…  Same result, but apparently the message is clearer, perhaps because we’re on Windows SBS 2003.  The warning now tells me that I can only add a Certification Authority (CA) certificate to a Certificate Trust List (CTL).


Off I go to my first port of call, the Usenet newsgroups.  I post my question, and within a few hours, I get a helpful post back from Steven L Umbach, an MVP.  He points me to the articles for “Trusted Application Deployment Overview” and “Create a certificate trust list for a Group Policy object“.  Geez, what are they teaching these MVPs these days – I could have figured that out for myself :-)


So, I call in a couple of favours with a few people I know at Microsoft that work with SSL.  Okay, so they didn’t actually owe me any favours, I just treat them as if they do, and they’re always really helpful.  I should send them a gift basket or something.  They’re a few layers removed from the admin side of things, so I don’t get much more than “we’ve passed you on to some other people that we know” for the next few days.


So, during the meanwhilst, I tinker.  I love to tinker.  That’s why I get into the scrapes that I do – but you learn so much from fixing the messes you get into, it’s worth it.  Eventually, I find a page that explains what the various certificate stores are supposed to be used for.  There, in the middle, is a single line in the table, describing Trusted Publishers:







Trusted Publishers Certificates from certification authorities that are trusted by Software Restriction policies.

“Software Restriction Policies” (SRP)?  Wow, that’s a whole different area from where I was looking.  SRP, also known within Microsoft as “SAFER” is a way to describe what software you will, or won’t, run.  It’s more of a policy tool than a security tool, in most cases, because if you restrict a program through SRP by, say, creating a rule that “Foxtrot.exe” is not allowed to run, it’s a piece of cake to rename it “Quickfire.exe” and have it work again.

But what SRP allows you to do that’s relevant to my story is to add a “Certificate Rule”.  This is where you state that “all code signed with such-and-such a certificate is immediately allowed”.  So I add a certificate rule, and associate it with my code signing certificate.

Whaddya know, the certificate is now magically in my “Trusted Publishers” certificate store!  What’s more, if I open the Certificate Manager (certmgr.msc), I see the certificate, but can’t delete it – to remove it, I have to delete the Certificate Rule in SRP.

And a Certificate Rule for SRP can be applied through a Group Policy Object.

A few hours later, I get a confirmation email from Microsoft…  “Alun is looking in the wrong direction, and should be thinking of Software Restriction Policies instead.  Oh, and he should have called PSS.”

“…should have called PSS.”  Yes, maybe, I might have gotten a quicker answer that way, but I have had a few frustrating experiences with PSS, where they read me the online help information, charged me my $$$, and sent me on my way.  I’d already tried the online help, it had been useless, pointing me in completely the wrong direction, and I didn’t anticipate PSS would do any better.  PSS, in my humble opinion, should be reserved for people who are unwilling to read enough of the help file and online documentation to understand how to solve their problem.  It should be a penalty for those who need a speedy response, and/or can’t be bothered to wade through documentation.

PSS should not be a penalty for having the temerity to do something where the documentation is clearly wrong, and was never tested against the programs it described.

7 Responses to Why is PKI so hard?

Leave a Reply

Your email address will not be published. Required fields are marked *