First published on CloudBlogs on Jan, 28 2009
[Today's post is contributed by
Carol Bailey
]
We've seen this question come up a few times, and the simple answer is no - as long as the communicating computers have a trust in common, and the correct certificates are used, native mode works just fine. This trust in common can use a single certification authority (CA) hierarchy or multiple CA hierarchies. Because native mode is PKI-agnostic, this all happens at a lower level than Configuration Manager - we just need the PKI connection established before we can proceed with native mode communication.
The phrase "trust in common" sounds very simple, but if you're not familiar with PKI, then trying to explain how this requirement pans out for native mode is actually quite difficult to explain, because there are multiple certificates to take into account and each could be issued by a different CA hierarchy.
One of the best ways to explain this is to work through an example where we'll achieve the common trust by installing root CAs - but this isn't the only way to achieve trust in common (cross-trust subordination is another method). If you need some tips on installing root CA certificates, see
http://technet.microsoft.com/en-us/library/bb693643.aspx
.
Our example uses the following:
(Note, this choice of CA hierarchy split is arbitrary - for example, there's no requirement that all the server certificates are from the same CA hierarchy, or all workgroup clients must use the same CA hierarchy.)
For native mode communication to be successful in this scenario:
-
If the servers install the root certificate for CA hierarchy 1, they will trust the domain-joined clients. And if they install the root certificate for CA hierarchy 2, they will trust the workgroup clients.
If you see WINHTTP_CALLBACK_STATUS_FLAG_INVALID_CA in log files, this usually means that the trust in common failed. Let's say with our example that the workgroup clients didn't have the root CA installed for hierarchy 3. When one of these clients tries to communicate with its native mode management point, it checks the Web server certificate and "walks" the chain to see if it ends in a root CA that it trusts. If it doesn't, it can't trust the server certificate despite the server certificate otherwise having all the right requirements (such as not expired, server authentication capability, FQDN in the Subject or SAN) - and communication will fail. Similarly, if the management point couldn't successfully chain the client certificate to a trusted source, it would reject the client certificate.
It's easy to make the mistake of thinking that the invalid CA in the error message refers to the computer's own certificate rather than the certificate on the other computer. If you get this error message, use the Certificates MMC to check the certificate path on the other computer (double-click the certificate and then click the Certificate Path tab), and ensure that the computer with this error message has the root CA and any intermediate CAs that chain from that certificate. If they are missing, export them by locating the lowest subordinate CA in the Certificates MMC, select Export, and then select the option for PKCS #7 Certificates (.P7B) with the option "Include all certificates in the certification path if possible". You can then easily import the chain onto the computer that reported the error message.
In addition to seeing this error message when you're using multiple CA hierarchies, watch out for it as well if you're deploying certificates outside the forest. This might include a subordinate CA in another forest, or workgroup computers. In these scenarios, these computers will not automatically install enterprise root and subordinate CA certificates through group policy, so you will have to take additional steps to ensure that they have installed the certificates required to successfully achieve trust in common with their communicating native mode computers.
I hope that this post helps to clarify how multiple CA hierarchies can be used with Configuration Manager native mode, and what additional steps might need to be taken to achieve the underlying PKI communication. And, for people who ask about using a
public CA for native mode
, the example works equally well for both internal CAs and public CAs.
-
Carol Bailey
This posting is provided "AS IS" with no warranties, and confers no rights.
