Change validatiy period of a Root certificate

[Guest Gunna]

Appologies if this is covered elsewhere, I did google it first. I have a

Standalone Root CA whos certificate is only valid for 5 years. Is there a

way I can renew the Root certificate extending the validity period. I know

setting the validity period etc on the CA seems to only affect certificates

issued from the CA but not the CA's root certificate.

 

Is this possible or am i looking at a rebuild? BTW I inherited this PKI so

I had nothing to do with the planning, i know good planning is important.

[Guest Gunna]

Ok, seems you can do it using a capolicy.inf file. What's the main reasons

for using one of these? From what I understand your options are selectable

using a capolicy.inf file. Any other good reasons?

 

"Gunna" wrote:

<span style="color:blue">

> Appologies if this is covered elsewhere, I did google it first. I have a

> Standalone Root CA whos certificate is only valid for 5 years. Is there a

> way I can renew the Root certificate extending the validity period. I know

> setting the validity period etc on the CA seems to only affect certificates

> issued from the CA but not the CA's root certificate.

>

> Is this possible or am i looking at a rebuild? BTW I inherited this PKI so

> I had nothing to do with the planning, i know good planning is important.</span>

[Guest Paul Adare - MVP]

On Wed, 10 Sep 2008 20:16:01 -0700, Gunna wrote:

<span style="color:blue">

> Ok, seems you can do it using a capolicy.inf file. What's the main reasons

> for using one of these? From what I understand your options are selectable

> using a capolicy.inf file. Any other good reasons?</span>

 

For some operations, such as changing the key length, the lifetime, or

setting the CDP and AIA locations to null for a root cert you have to use

CAPolicy.inf. It is best to get into the habit of always using this file,

both when installing and renewing a CA.

 

--

Paul Adare

MVP - Identity Lifecycle Manager

http://www.identit.ca

Analog: Hors d'oeuvre, usually made from cheese and covered with crushed

nuts. Served at all staff parties.

[Guest Gunna]

Many thanks Brian,

 

Could you answer a question rasied from the info below. I notied in a lot of

the sample capolicy.inf files for a Root CA that the CDP and AIA are set to

empty. Does this mean that the recomendation os not to have a CDP or AIA for

a Root CA or is it suggestting use the settings in the management console or

soemthign else?

 

Apollogies if the answer is in your book, im not that far yet.

 

"Brian Komar (MVP)" wrote:

<span style="color:blue">

> 1) You need to edit the %windir%capolicy.inf file (this does a 20 year

> renewal)

> [Version]

> Signature="$Windows NT$"

>

> [certsrv_server]

> renewalkeylength=2048

> RenewalValidityPeriodUnits=20

> RenewalValidityPeriod=years

>

> CRLPeriod=weeks

> CRLPeriodUnits=26

> CRLDeltaPeriodUnits=0

> CRLDeltaPeriod=days

>

> [CRLDistributionPoint]

> Empty=True

>

> [AuthorityInformationAccess]

> Empty=True

>

> 2) Renew the root CA with a new key pair (there is a bug here in 2003, that

> does not recognize the capolicy.inf when you renew with a new key paior

> 3) REnew the root CA with the same key pair (this reads the capolicy.inf)

> Now good for 20 years.

>

> Brian

>

>

>

> "Gunna" <Gunna@discussions.microsoft.com> wrote in message

> news:66F7DC9F-F1E7-4C93-8D17-564C27E09A46@microsoft.com...<span style="color:green">

> > Appologies if this is covered elsewhere, I did google it first. I have a

> > Standalone Root CA whos certificate is only valid for 5 years. Is there a

> > way I can renew the Root certificate extending the validity period. I

> > know

> > setting the validity period etc on the CA seems to only affect

> > certificates

> > issued from the CA but not the CA's root certificate.

> >

> > Is this possible or am i looking at a rebuild? BTW I inherited this PKI

> > so

> > I had nothing to do with the planning, i know good planning is important. </span>

> </span>

[Guest Paul Adare - MVP]

On Sun, 14 Sep 2008 15:58:01 -0700, Gunna wrote:

<span style="color:blue">

> Does this mean that the recomendation os not to have a CDP or AIA for

> a Root CA or is it suggestting use the settings in the management console or

> soemthign else?</span>

 

The former.

 

--

Paul Adare

MVP - Identity Lifecycle Manager

http://www.identit.ca

If it was easy, the hardware people would take care of it.

[Guest Gunna]

Thanks Paul. What wuold you say abotu the following? Standalone RootCA

running on Server 2003 standard, Standalone Sub running on Server 2003 and a

Entperise Sub for issuing. Should the standalone sub not publish a CDP or

AIA either? I would think yes but I could be wrong style_emoticons/

 

"Paul Adare - MVP" wrote:

<span style="color:blue">

> On Sun, 14 Sep 2008 15:58:01 -0700, Gunna wrote:

> <span style="color:green">

> > Does this mean that the recomendation os not to have a CDP or AIA for

> > a Root CA or is it suggestting use the settings in the management console or

> > soemthign else?</span>

>

> The former.

>

> --

> Paul Adare

> MVP - Identity Lifecycle Manager

> http://www.identit.ca

> If it was easy, the hardware people would take care of it.

> </span>

[Guest Paul Adare - MVP]

On Sun, 14 Sep 2008 20:48:01 -0700, Gunna wrote:

<span style="color:blue">

> Thanks Paul. What wuold you say abotu the following? Standalone RootCA

> running on Server 2003 standard, Standalone Sub running on Server 2003 and a

> Entperise Sub for issuing. Should the standalone sub not publish a CDP or

> AIA either? I would think yes but I could be wrong style_emoticons/</span>

 

The root certificate should not have either an AIA or a CDP URL in it, the

subordinate CA certificate should have both.

 

--

Paul Adare

MVP - Identity Lifecycle Manager

http://www.identit.ca

It is ten o'clock; do you know where your processes are?

[Guest Gunna]

Thank Paul

 

Shouldn't the Root CA at least have a local file CRL so it can check it's

own validity? I read that somewhere.

 

"Paul Adare - MVP" wrote:

<span style="color:blue">

> On Sun, 14 Sep 2008 20:48:01 -0700, Gunna wrote:

> <span style="color:green">

> > Thanks Paul. What wuold you say abotu the following? Standalone RootCA

> > running on Server 2003 standard, Standalone Sub running on Server 2003 and a

> > Entperise Sub for issuing. Should the standalone sub not publish a CDP or

> > AIA either? I would think yes but I could be wrong style_emoticons/</span>

>

> The root certificate should not have either an AIA or a CDP URL in it, the

> subordinate CA certificate should have both.

>

> --

> Paul Adare

> MVP - Identity Lifecycle Manager

> http://www.identit.ca

> It is ten o'clock; do you know where your processes are?

> </span>

[Guest Paul Adare - MVP]

On Mon, 15 Sep 2008 16:40:01 -0700, Gunna wrote:

<span style="color:blue">

> Shouldn't the Root CA at least have a local file CRL so it can check it's

> own validity? I read that somewhere.</span>

 

No, it shouldn't. A CRL is a signed document. Once you revoke a root CA's

certificate are you then going to turn around and sign a new CRL with a

revoked certificate? According to RFC 3280 CRL checking should stop one

level below the root.

 

--

Paul Adare

MVP - Identity Lifecycle Manager

http://www.identit.ca

Disc space -- the final frontier!

[Guest Gunna]

Hi Paul,

 

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. But then after i start the

service and point it to the Root to pickup the Certificate I just issued 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.

 

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 ?

 

"Paul Adare - MVP" wrote:

<span style="color:blue">

> On Sun, 14 Sep 2008 20:48:01 -0700, Gunna wrote:

> <span style="color:green">

> > Thanks Paul. What wuold you say abotu the following? Standalone RootCA

> > running on Server 2003 standard, Standalone Sub running on Server 2003 and a

> > Entperise Sub for issuing. Should the standalone sub not publish a CDP or

> > AIA either? I would think yes but I could be wrong style_emoticons/</span>

>

> The root certificate should not have either an AIA or a CDP URL in it, the

> subordinate CA certificate should have both.

>

> --

> Paul Adare

> MVP - Identity Lifecycle Manager

> http://www.identit.ca

> It is ten o'clock; do you know where your processes are?

> </span>

[Guest Paul Adare - MVP]

On Mon, 22 Sep 2008 22:08:00 -0700, Gunna wrote:

<span style="color:blue">

> 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.</span>

 

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.

<span style="color:blue">

> But then after i start the

> service and point it to the Root to pickup the Certificate I just issued</span>

 

Again, this doesn't make sense to me.

I <span style="color:blue">

> 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.</span>

 

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.

<span style="color:blue">

>

> 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 ?</span>

 

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