[Today's post comes from Carol Bailey ]
Many companies do not currently have their own public key infrastructure (PKI) with an issuing Certification Authority (CA) but still want to benefit from native mode and Internet-based client management - which has a dependency on PKI certificates. So a natural follow-on question is whether native mode can use certificates from a public CA rather than using an internal CA.
The technical answer is yes. Native mode is PKI-agnostic, supporting industry standard certificates (version 3 of the x.509 certificate format) and has no dependencies on the issuing CAs. This is in contrast to the out of band management feature, introduced in Configuration Manager SP1, which has a dependency on a Microsoft enterprise CA and certificate templates for the certificates issued to the AMT-based computers.
If you decide to use a public CA for your native mode certificates, identify the certificates that you need by using the Certificate Requirements topic ( http://technet.microsoft.com/en-us/library/bb680733.aspx ) and gather the related certificate information - using the columns Certificate Use and Specific Information in the Certificate . This is where the OID numbers come in use, because these uniquely identify the certificate capability in a format that will be understood by all PKI vendors.
The CA hosting company will provide their own instructions for requesting and installing the certificates that you need, and usually this involves connecting to their own Web site and filling out their own forms - so exact instructions will differ between companies. They might also support a standard certificate request file that you can create using Windows certificate tools.
Microsoft Windows computers and some devices are automatically configured with some well-known public root certificates and their intermediate CAs. If you use certificates that chain to one of these CAs, the benefit is that the certificate will be automatically trusted by default and no additional configuration is required. However, if you use certificates that do not chain to one of these CAs, you must install the root CA (and possibly any intermediate CAs) on the computer on which you are installing the certificate and any communicating computer. For example, if you purchase a client computer certificate that chains to the root CA called "ComputerCerts Root CA", you would need to install not just the client certificate, but the chain on the client computer and any native mode servers that the client communicates with - for example, its management point, distribution points, software update point, and state migration point.
Having to install certificate chains on multiple computers is just one reason why using a public CA might prove impractical, even if it's technically possible. The flip side is that using a well-known public CA that is automatically trusted by all the computers decreases the security of your site. That's because the client certificate is used to authenticate the client during registration - you're saying "I trust you to upload data into my Configuration Manager hierarchy". Anybody can buy a certificate with client authentication from a public CA but you probably wouldn't want anybody to have the ability to join their computer to your site. If your Configuration Manager servers automatically trust the public CA, they will trust this computer and site assignment will succeed. If you use a public CA for your client certificates, Configuration Manager has no way of distinguishing between the computers you really want to join the site, and computers that you might not.
(This possibility also exists when you're using native mode certificates with your own CA, because by default, all computers trust certain public CAs. This is why you should configure an IIS CTL that identifies which root CAs should be trusted for native mode communication. For more information about this, see Determine If You Need to Configure a Certificate Trust List (CTL) with IIS (Native Mode) .)
The main reason why it might be impractical to use a public CA for native mode, is cost and manageability. Many PKI-dependent solutions use just one or two server certificates, but native mode requires server certificates on a number of site systems and a unique certificate on each client computer. For the majority of our customers who have a high number of servers and hundreds (if not thousands) of client computers, a Microsoft enterprise CA is ideally suited to this requirement. It can automatically deploy and maintain client certificates with group policy, and after the certificate templates are configured for the servers, the overheads of deploying these in-house are also very minimal.
Having said that, I do know of customers who have used a public CA for a handful of computers that never connect directly to the intranet, and then use their internal CA for the remaining certificates. They decided that the administrative costs of deploying and maintaining certificates outside their own network was higher than the costs of buying individual client certificates from a public CA, and they used additional external security controls to protect the site from unauthorized computers that might have a client certificate from the same CA.
Using more than one CA hierarchy to support native mode is the subject of my next blog posting.
This posting is provided "AS IS" with no warranties, and confers no rights.
Microsoft
