Question : Root CA PKI buildout what SSL Cert type?  Will Smime email certs not be authenticated by non-domain recipients?

I am really confused.  I have read a whole PKI book and still feel dumb.  I know I cannot get a root CA subordinate cert from my Enterprise CA, but I am wondering what I can do to ensure certs that are seen outside my network are seen as valid and not untrusted.  I thought it would make sense that my Enterprise (single tier) CA would get it's SSL cert from some fancy Internet CA like Verisign or Godaddy, and therefore all certs I generated for my clients or servers would be attached to that chain and validated as cool.  Doesn't even seem like that is remotely possible.  I looks like the only way to set it up for yourself so that you can issue certs, is to make your server the root... whereby every cert it issues is untrusted by people who have not imported my Enterprise Root Certificate... which I guess is self-signed?  No need to get a public SSL cert for that?

My biggest concerns are:
1.  One of our VPs that is trying to access his Outlook Web Access account from an IE 6 browser in Nowheresvill, IN is going to have the browser pop up and tell him the certificate is untrusted.
2.  That when my AD users use their certs to sign Smime signed or encrypted messages, that the client on the other side of the country, on someone else's domain, is going to get a message that the cert is untrusted.

What do I do to avoid these problems other than continue to pay $29 bucks for every server or client workstation that needs a cert (and also needs that cert to be valid outside my network without an intermediate or root CA download to all our customer's machines).   I know that for smime you can send a digitally signed message, and have the remote user create a contact and save the public key- but if the key we send throws and error message, that won't work either.

Thank you so much in advance for your ideas and help.

Answer : Root CA PKI buildout what SSL Cert type?  Will Smime email certs not be authenticated by non-domain recipients?

"That totally sucks.  I cannot believe technology has left a trusted infrastructure so far behind.  Why in world there is not a framework for authorization and authentication is totally beyond me.  I mean, how in the heck am I supposed to train users on how to use Smime encrypted or signed email if they have to jump though all those hoops.  Even the idea of using smime through OWA requires a plug-in on every browser they are going to use remotely... pathetic really."

Well, the trick is that trust is not an automatic thing. The users would have to trust you in some form anyway. And yes, for web applications PKI is a really difficult, if only because web-apps are relatively new and security is always the last thing on people's mind.

"A subordinate CA cert is out... too much $ and audit crap.  Is there a way I can put a Windows 2008 CA server on my dirty-net that will allow those external users to validate the cert automatically?"

Not as far as I know. Of course, other AD admins can add your root certificate to their trusted certificate store, which is then automatically distributed among all their users.

"Another clarification needed ... when I create the root CA, it actually creates a new root cert that has no CA higher than it, right?  So getting a cert from Verisign to validate my Root CA is not something that is done or even possible within that framework, right?"

Well, yes, you can do a cross certification. This would be the same as a subordinate CA in all other means, but you have the fortune you don't have to setup an entirely different CA tree.

PGP has a different structure. Here you may trust peoples certificates because other people trust those certificates. Trust is shown by creating a signature for the certificate and storing these signatures with the certificate. So you have more of a mash than the traditional PKI tree. IMHO, this does not work either by the way.