Ever wondered why SSL works for some sites and not others? Welcome to the Microsoft Root Certification Programme!

If you're not a crypto geek then don't be scared - read on! If this makes as much sense as boiling icecream then please let me know and I'll explain it in simpler terms - just hit the "comment" button.

When you visit a website via HTTPS you're viewing HTTP content over Secure Socket Layer (SSL). This much is pretty well understood by most IT Pros I think.

The browser challenges the website to prove it's identity by presenting a certificate and performing an operation with the corresponding private key. The certificate contains the associated (**EDITED TO CORRECT A TYPO AS IT'S THE PUBLIC key not the Private key as originally stated**)  together with a series of attributes including usage information such as an expiration date and details of the issuer. The issuer is known as a Certification Authority. One of the roles of the issuer is to validate the physical identity of the subscriber (website in this case) with the digital identity of the certificate. The issuer digitally signs the certificate to assert it's authenticity and make it evident it's subsequently tampered with.

The Windows Operating Systems (XP, 2000, 2003, Windows Vista) ship with a series of "Trusted Roots" - also know as Root Certification Authorities" or "Self Signed Certificates". In order for your browser to trust the certificate presented by a website it must trust it's issuer - that's where the Trusted Roots come in.

By default every user of Windows will automatically trust the identity of any webserver via HTTPS assuming the associated certificate is within it's usage dates (and is otherwise valid) if it's signed by one of the Trusted Roots.

You can set up your own Certification Authority using the optional Windows Server components without any additional license charges. The challenge you'll face is that you have to distribute the Trusted Root to all clients. If you're working within an Active Directory Domain this is easy to achieve as your additional Trusted Roots can be automatically distributed. If you wish for clients outside your network boundary to trust your certificates then you have to convince them to install your associated Trusted Roots. Technically it's an easy process for the users to go through - just send them a very small file (containing the Trusted Root) and ask them to double click and answer the Operating System's question "do you wish to accept this trust?" - politically this may be more of a challenge as by doing so they'd trust ALL certificates issued by your Certification Authority.

If you provide a Root Certification Authority for third party customers and would like Windows Users to automatically trust them then you need to enrol in the Microsoft Root Certification Programme. Details of how to join the programme can be found here.

One of the wonders of this form of cryptography is that it's actually based on a well defined standard - X.509 certificates and associated RFCs - therefore you can interoperate across most modern operating system platforms including LINUX, Mac and of course Microsoft Windows. The other platforms presumably have comparable Root Certification Programmes though I don't have experience of them.


Comments (4)

  1. nick says:

    A while back I did a 5-part series of blog entries about about setting up and working with the certificate authority (CA) that’s built into Windows.  Part 5 has links to the entire series in case you’re getting started with CA and/or want to learn more.


  2. Steve Lamb says:

    Nick> Thanks for sharing.

  3. mdubh says:

    Two minor corrections:

    – It’s X.509, not X5.09

    – The certificate contains the public key, not the private key, which is never distributed

  4. Steve Lamb says:

    Thanks for pointing out my typos – like you I get frustrated when people think the private key is part of the certificate.

Skip to main content