Home » IT - Microsoft » Certification Authority Root Signing

Certification Authority Root Signing

Escribe tu dirección de correo electrónico para suscribirte a este blog, y recibir notificaciones de nuevos mensajes por correo.

Join 5 other followers

February 2016
« Nov   Mar »



All messages posted to this blog are provided "AS IS" with no warranties, and confer no rights. The content of this site are personal opinions and might not represent the Microsoft Corporation view. Regarding any sample code that we provide: This Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment. THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE. This blog serves 2 purposes. Firstly, I want to share information with other IT pros about the technologies we work with and how to solve problems we often face. Secondly, I use my blog as a notebook. There's so much to learn and remember in our jobs that it's impossible to keep up. By blogging, I have a notebook that I can access from anywhere. Anything you do to your IT infrastructure, applications, services, computer or anything else is 100% down to your own responsibility and liability. Mcselles bears no responsibility or liability for anything you do. Please independently confirm anything you read on this blog before doing whatever you decide to do.

Table of Contents

This article provides descriptional information about enterprise Certification Authority signing by commercial Certification Authority (sometimes, external root is referred as "common root").

What is Certification Authority Root Signing?

Consider the following scenario:
You work for an organization that requires many digital certificates. You want to ensure that these certificates are trusted by other organizations, such as external partners and customers. For example, you might want to use a code signing certificate for an application or a digital signature certificate for signing a document or email.

If you setup your own public key infrastructure (PKI), also known as a private PKI, the certificates you issue will only be trusted internally. For example, you can publish the root certification authority certificate into your Active Directory Domain Service (AD DS) and quickly have your organization’s computers trustting certificates issued by your PKI. However, external organizations, such as your customers and partners, would not (by default) trust the certificates issued by your PKI. This means they would see a validity or trust error message, if they viewed or tried to validate a certificate issued by your PKI.
If instead, you subordinate your PKI to one of the commercial PKI root certificates that are trusted by Microsoft Windows installations, you do not have the same problem. By default, Microsoft Windows applications install a set of predefined root CA certificates (well known commercial root CAs), which certificates are trusted on any Windows installation by default. For example, if you access https://login.live.com/ web site, no additional actions are required from a user. This is because SSL certificate is issued by a trusted CA.
Contrarily, if a remote user tries to access a web site that utilizes SSL certificate from a private PKI, the user receives an error message indicating certificate trust issues. When a user application (like Internet Explorer) does not specifically trust a PKI, an error message is presented each time that private PKI’s certificate is presented to the user.

To overcome such an issue, you may decide to implement a PKI that utilizes the trust of a well-known and trusted PKI. This allows your organization to issue certificates that can be trusted and recognized worldwide.

Target Audience for Certification Authority Root Signing

The target audience for CA root signing is organizations that require a large number of digital certificates to be considered as universally trusted. These organizations should have or be planning to have a certificate management strategy, tools, and expertise to perform internal certificate management.

Even if an organization fits that description, it does not necessarily mean that your PKI requires external signing. In most cases it is reasonable to implement private PKI for organization wide purposes only, and purchase individual certificates from a commercial CA for specific externally require uses. For example, an organization may want to buy an SSL certificate for a commerce web site and use their own PKI for securing communication with their internal web sites.  However, if management and costs for individual certificate purchases are significant enough, an organization may want to compare the costs of using a PKI that is subordinate to and trusted by a commercial CA.

How much does it cost?

There is no publicly available information about service pricing. Due to the fact, that if your have a PKI that is signed by the external root, you are eligible to issue almost unlimited certificate count to your company*. The Root Signing service is provided on a annual contract with a defined price basis, therefore the price is quite high.
Note: Root Signing is implemented in a Qualified Subordination or Cross-Certification form. This means that your PKI (under an external root) will be eligible to issue certificates only for a set of specified purposes, such as Server/Client Authentication, Code/Document/Email signing and so on. In addition, your CA will be restricted to issue certificates for the domains owned by the trusted organization. This includes an inherent limitation of issuing certificates to third-party domains, without mutual agreement with all relying parties.

Are there any requrements to implement an external root?

In all cases where commercial Certification Authorities define special requirements for an organization’s PKI to be trusted, these requirements typically include:

  • all CAs in your PKI must use Hardware Security Modules (HSM) to protect CA keys from tampering and theft.
  • in most cases you will have to define and follow your own Certificate Practice Statement (CPS).
  • in most cases, your company will have to pass annual external audits to prove does conform with CPS and certificate security.
  • additional requirements may take a place.

For example, a brief service description can be found at the TrustCenter web site (PDF document):http://www.trustcenter.de/media/TCRootSign-StatementServices-0907-en.pdf

Which commercial CA’s provide Root Signing service?

A number of commercial CA’s offer this type of service, including but not limited to (in no particular order):

Source: http://social.technet.microsoft.com/wiki/contents/articles/5973.certification-authority-root-signing.aspx


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Microsoft on the Issues

News and perspectives on legal, public policy and citizenship topics

Mike Crowley's Whiteboard

“There are no limits to what you can accomplish when you are supposed to be doing something else."


There Be Dragons

Ken Cenerelli

My life in software development

VMware, Windows, Virtualization (Servers & Desktops)

VMware, Windows, Virtualization (Servers & Desktops)

Just a random "Microsoft Server / Client Tech" info..

"Feeding Your Training and Technology Obsessions"


WordPress.com is the best place for your personal blog or business site.


Documentación técnica, notas y apuntes sobre Administración de Sistemas, Servidores, Redes y más

Microsoft Taste

Mary's Blog

%d bloggers like this: