Re: Change validatiy period of a Root certificate
On Mon, 22 Sep 2008 22:08:00 -0700, Gunna wrote:
> Im loosing my mind here so bear with me. You say "The root certificate
> should not have either an AIA or a CDP URL in it" But when I go to install
> my subordinate stand alone CA it asks me for a Root CA to get it's cert from.
> I picks up my newly created standalone Root CA.
I'm not sure I understand what you're saying here. A standalone root CA,
and a standalone sub CA (also referred to as a policy CA) should both be
offline, in other words, not connected to the network at all. When
installing Certificate Services on the policy CA you should be saving the
request file to removable media, taking that to the root CA, issuing the
certificate, copying the certificate to removable media and then installing
the certificate on the policy CA.
> But then after i start the
> service and point it to the Root to pickup the Certificate I just issued
Again, this doesn't make sense to me.
I
> get the error "Cannot verify certificate chain....The revocation function was
> unable to check revocation for the certificate" Doesnt this mean it checking
> to see if ther Root CA cert hasn't been revoked which would mean I need to
> publish a CRP for the Root? Makes no sense me to.
No, that's not what it means. What it means is that it is checking to see
if its own certificate has been revoked. It needs to be able to find the
root CA's CRL. It tries to find the root CA's CRL in its local store. The
error you're getting means that you haven't installed the root CA's CRL
into the local store on the policy CA.
You're getting two concepts here confused:
1. The root CA certificate should not contain a URL for either the AIA or
the CDP.
2. The root CA does issue CRLs and relying parties (those applications,
services, and users who consume certificates) need to be able to locate the
CRL issued by the root. The only thing that will ever be listed in the
root's CRL are certificates issued by the root CA itself.
Say you're an application that has been presented with an end entity
certificate from your PKI. Here's roughly what needs to happen:
1. A chain of trust needs to be built. In your case, that means that the
application needs to make sure that you can build the following trust
chain:
End entity cert=>Issuing CA cert=>Policy CA cert=>Root CA cert
In this trust chain, the Issuing CA cert and the Policy CA certs are the
intermediate certs. They need to be retrieved and cached locally on the
client. This is done by examining the AIA URLs. To get to the Issuing CA
cert, the AIA URL in the end entity cert is used. To get to the Policy CA
cert, the AIA URL in the Issuing CA cert is used. While you could use the
AIA location in the Policy CA cert to get the root, in an Active Directory
environment, the root cert is typically published to the directory which is
then downloaded to all forest members via the Group Policy engine.
Notice that the AIA URL in each cert is used to find the next cert in the
chain. Since the root CA is the top of the chain, there's no need for an
AIA URL in its cert. There's nothing more to retrieve at this point.
2. Once the trust chain is successfully built, the certs in the chain need
to be checked for validity. To simplify things I'm only going to talk about
revocation checking here.
The CDP URLs in the end entity certificate are examined and if need be a
CRL is retrieved from the specified URL. Next, the CDP URLs in the Issuing
CA are examined and if need be a CRL is retrieved from the specified URL.
Finally, the CDP URLs in the Policy CA certificate are examined and if need
be a CRL is retrieved. Note that CRL checking stops here, the root CA is
assumed to be valid. This is why there's no need for a CDP URL in the root
cert.
>
> When i uninstalled all my CA's, cleared AD out etc and started again I get a
> differnet error "The Root Certificate is untrusted" What's going on ?
You need to make the Root CA cert available to all relying parties. In the
case of an offline policy CA you need to manually install the root CA cert
into its local store.
--
Paul Adare
MVP - Identity Lifecycle Manager
http://www.identit.ca
A list is only as strong as its weakest link. -- Don Knuth
