Re: Proper method to establish the PKI environment (Trusted Root

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/opens..._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

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:

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