> I am not Mr. Komar - and my consulting fees are about 1/3 of his (per hour). > :-) But I feel pretty good about my answers above.
One of my old bosses used to quip that Brian had a PhD in PKI. You have a MBS in PKI, hence the 1/3 fee. But despite that, I feel pretty good about your answers too :-] -----Original Message----- From: Michael B. Smith [mailto:mich...@smithcons.com] Sent: Wednesday, May 11, 2011 5:19 PM To: NT System Admin Issues Subject: RE: Server 2008 R2 PKI questions - long and complicated... So.... o - Don't put your Enterprise Certificate Authority on a DC. The tombstone lifetime of the DC can expire long before you want to bring out the Enterprise root. o - Placing a CA root on a DC is fine in a test environment, but not in the real world. IMO. o - Use at least a two-tier environment. In general, I recommend that you put your CA root into a safe - whether logical or physical. o - Will one-tier work for DA/UAG? Yes. As per above, I don't recommend it. o - I don't know about versions of X.509 certificates. Sorry. However I can tell you that "upgrading" a certificate means replacing it on the client. Not simply doing something on the CA. o - In regards to code-signing - if you don't make at least one of your CAs visible to the Internet (and configure the certificates to use that CA for validation), then you shouldn't use your internal CAs for code-signing. In general (IMO), it's cheaper to purchase third-party code-signing certificates than to do the appropriate lock-downs to export your internal CAs to the Internet. So... I am not Mr. Komar - and my consulting fees are about 1/3 of his (per hour). :-) But I feel pretty good about my answers above. Regards, Michael B. Smith Consultant and Exchange MVP http://TheEssentialExchange.com -----Original Message----- From: Kurt Buff [mailto:kurt.b...@gmail.com] Sent: Wednesday, May 11, 2011 8:04 PM To: NT System Admin Issues Subject: Server 2008 R2 PKI questions - long and complicated... All, I'm still in the process of learning this PKI stuff, so I can roll out DA/UAG. I picked up a copy of Brian Komar's Windows Server 2008 PKI and Certificate Security [1], and in reading it I've come up with a buncha (TM) questions. I'm starting on my second time through the book, and am also going through the Ben-Ari and Dolan book on DA/UAG, but the only thing that book says is that you need a fully functioning PKI before doing DA/UAG, and doesn't address what is needed out of that infrastructure in any depth at all. I'm also looking at the lab guides from Microsoft. So, some questions: o- Is a single-tier PKI infrastructure sufficient for DA/UAG (and possibly 802.11 security and other internal use)? One thing I'm worried about is cert requests from our overseas offices, and the probable need to extend PKI over there, as we're a single forest/single domain entity (connected by site-site VPNs), and I'm considering the possibility that I'll need a two or even three tier solution. We're only about 250 people in the US office, and no more than 40 people in either of the overseas offices, if that makes a difference. o- Will Version 1 X.509 certs be sufficient for DA/UAG and other internal purposes? o- Is it still the case with Win2k8 R2 that I will need at least Enterprise to issue Version 2 or Version 3 X.509 certs? In working my way through the Komar book, I see it stated, on page 263, this: Important: An Enterprise CA running on the Standard Edition of Windows Server 2003 or Windows Server 2008 can issue certificates based only on version 1 certificate templates. This is a common problem encountered by companies because they do not realize that the Standard edition cannot issue version 2 or version 3 certificate templates. The only way to issue version 2 or version 3 certificate templates is to perform an upgrade in place to the Enterprise Edition for your version of the operating system. o- Apropos of the previous question, our engineers produce hardware and software - if we're going to contemplate signing our software, and/or doing other externally-focused activities that might require a PKI, can I upgrade to Version 1 certs to Version 2 or 3 certs fairly easily, or from Version 2 to Version 3, or will I be able to mix versions? I want to avoid the mistake of doing it the easy way first at the cost of a lot of pain later, but also want to balance that with initial cost and complexity of installation and management. o- The lab guide from MSFT and Brian Komar's book are in conflict, with Brian stating that it's a bad idea to put your CA on a DC, but the lab recommending to install the CA on the DC. I'm guessing that the lab guide is suggesting doing so just in the name of making a demo project work, without reference to a production implementation. Brian's reasoning certain makes sense. Has anyone here put up a CA on a DC, and thinks it is a good idea? Thanks, Kurt [1] This book is out of print, with no reprint date set. I had to buy it in soft version, and chose PDF as being most portable. This also applies to Understanding IPv6, Second Edition, by Joseph Davies. I got those, plus the Windows Powershell Cookbook, Second Edition by Lee Holmes for the price of just two of them from O'Reilly. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin