Hello, I'm doing some research on deploying PKI internally and was curious about any best practices for deploying PKI in an environment where the FQDN is not a registered TLD. In this case, a .local or a .pvt. IE, internal.local. Is it easier to just create a new namespace, like internal.corp.com and via GP have all the users trust any certs from the PKI behind the namespace?What if you wanted to keep the .local, what type of issues would we run into?If we wanted to deploy secure mail is it even possible with the two questions above?Where / if / when would we need to get an external CA involved within an internal PKI setup given the first two design options? I don't think it's possible with a non-routable TLD. Curious as to what the best practices are and what other people have implemented given this issue.

1) I would not publish any of the CDP and AIA extensions to the internal.local namespace 2) I would publish CDP and AIA extensions to a namespace that is both accessible internally and externally 3) If you want to deploy SMIME for use globally, get your certs from a commercial provider The non-routable TLD really does not matter. I assume for email that you are not use bkomar@internal.local as your email address. Brian

Hi Brian, Could you clarify point number 2 for me. What benefits would there be to deploying PKI to a split DNS infrastructure over let's say creating another namespace that is disjoint from anything on the public side? To clarify, why not create an internal namespace like internal.corp.com for internal PKI and use anything in corp.com for the external ca's?

Can you clarify if you are asking an AD design question or a PKI design question? The answer depends on what you are asking. From a PKI perspective, if you are planning on using any applications that are external facing (VPN, SSL, SMIME), then you need to ensure that CDP and AIA extensions are accessible externally. Based on best practices, you would want to limit the # of CDP and AIA extensions, hence, you would use a namespace that is both internally and externally accesible. BTW, your clarify point is the way I would do the internal design as .local and .pvt are proposed RFCs that did not make the standards track. Brian

Hi Brian, It's from a PKI perspective. I just trying to get some feelers out there for some design suggestions. I was ultimately looking for a good list of pros and cons, but your reply's helped to clarify many points.