Patrick Patterson wrote: > Hi there; > > On Monday 24 March 2008 12:24:40 Cabz.List wrote: > >> Morning, >> >> I am experiencing some PKI comprehension issues: >> >> 1) When one talks about creating the "Trusted Root CA" is this different >> from the "Signing CA"? >> a. The Trusted Root CA's private key is hidden away from the world >> (not on an internet accessible disk) >> b. The signing CA does all the "real work"? By this I mean, is the >> "Signing CA" now used to sign client certs, and other servers certs such >> as SMTP, HTTP, RADIUS, SSL-VPN solution, etc.? Basically the Trusted >> Root CA, has intermediary CAs do all the work? >> c. Am I looking at a forest and planting an unnecessary trees? By >> this I mean, what is the better practice, having the Trusted Root CA do >> the signing of all certs, or attempting to establish this Trusted Root >> CA - Signing CA - hierarchy? RFC 1422 seems to desire a CA hierarchy, >> while RFCs 2459 and 3280 seem to argue that with x509v3 it is uncessary >> - ack!?! >> >> > How you set up your CA is determined by several things: > > 1: Policy Constraints: Essentially, if you want to have a particular > certificate trusted by others, you need to have a Certificate Policy. Take a > look at RFC3647 for the "standard" format, if you don't already have a policy > that your environment says you have to follow. > > 2: Technical Constraints: What sort of programs are you using? What are your > relying parties (the programs and people using the certificates to validate > the identity presented) capable of? Can they (like Microsoft CAPI) do full > RFC 3280 path validation and discovery, or are they limitted (like stock > Apache, which doesn't even do CRLs without a lot of pain and suffering). > > 3: Your budget. If you are using raw OpenSSL for your CA, you probably don't > have a lot of cash to spend on infrastructure (since OpenSSL, while > technically very good, is missing some functionality that more capable tools > like Entrust, Microsoft CA, or Redhat Certificate Services have - which is > understandable, given that it is, first and foremost, a library, and not a CA > product). So you may not have the extra funds for an offline root (we > usually use a laptop, a dedicated HSM, and a good safe in a secure location), > and for it's operation (even though it's offline, you still need to, at least > periodically, issue CRLs (or, more correctly, an ARL)). > > However, you can satisfy quite a few of the requirements that even a fairly > demanding Certificate Policy puts on your environment. We've written up a > howto guide that shows how an OpenSSL CA could be used as a test CA in the > Aerospace "CertiPath" framework - it can't be used in production, because > several of the bits of functionality that the CertiPath Certificate Policy > requires are only available in 0.9.8 and later, which doesn't have FIPS > certification, which is another of the requirements. > > You can find the howto (which includes how to set up a Root and Signing CA) > at: > > http://www.carillon.ca/library/openssl_testca_howto_1.2.pdf > > References to the policy are in the appendix of that document. > > >> 2) Is the file index.txt (and the associated brethren), given question 1 >> above, related to the Signing CA or the Trusted Root CA? >> a. Should index.txt contain the serial number and cert of the >> Trusted Root CA OR the serial number of the Signing CA? >> b. Should the Signing CA (and any other intermediary CA) have its >> own cert database? >> >> > > See the above guide for how to handle this. You probably want a separate > index.txt for each CA (or else you'll have them clobbering entries in each > other, or have an unclear idea of who issued what). > > >> 3) Is there a How To, that is considered a definitive resource on the >> matter, that discusses using OpenSSL to build out a RFC compliant PKI >> hierarchy for someone who is sleep deprived due to an infant? >> a. I have created CAs in the past and gotten plenty of this to work, >> but now that I have to try to due a true PKI environment, I realize I >> have more questions than knowledge. >> > > Well, we're currently using that guide for customers that are working within > a > very rigid environment, so while I won't claim it is "definitive", it > certainly shows how to do it, in a very policy constrained and technically > demanding environment. :) > > Again, it sounds like you should start with your Certificate Policy, and then > build out from there what is required within your community of trust. > > Afternoon Patrick,
After reading through the document you link to, I will agree that it is a wealth of knowledge and actually helps me see how OpenSSL can be used to build out the PKI environment. Policy not withstanding... Also, I'm not in a government environment so FIPS compliance isn't a concern. I personally appreciate having the raw openssl calls so that I can build localized scripts around them. This is great information and I hold the highest regards to you and your organization for putting the information together and making it available to us, the public. Also thanks to the OpenSSL developers for producing a great library... I think they need a few tech writers to vet there documents though because I haven't be able to find the CA.txt file on the internet anywhere :) Again, thanks Patrick! Kind regards, Carlos
