Changing CA CRL's

[EJS]

We currently have a W2K Stand-alone CA that supports issuing client
certificates for a large web farm. We need to add CLR paths that use web
addresses (we currently only have machine name paths). I know how to
add/remove CRL paths on the CA certificate.

My question is do I need to reinstall the CA in each IIS Certificate Trust
List or will the CRL paths be updated automatically the next time they are
published?

Also at some point we need to migrate our existing CA to Win 2003.

Can anyone point me to some resources for these two tasks?

Thanks in advance
Ed

 

[Vishal Agarwal[MSFT]]

You must re-issue client certs if your are going to change the CDP (for CRL)
paths. Following document should help:

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/maintain/operate/ws3pkibp.asp

http://www.microsoft.com/technet/tr...l=/technet/security/topics/crypto/tshtcrl.asp



Thanks,
Vishal[MSFT]

 

[EJS]

Do client certificates need to be re-issued when authenticating using IIS?

I thought that IIS will accept client certificates if the certificates CA is
in ISS' Certificate Trust List and the CRL information is cached using the
CDP information in the certificate that is listed/installed in the CTL.
Then when a client certificate is presented to IIS the cached CRL is used to
reject revoked certs.

I was hoping I could change/update the CA's CDP then reissue the CA to all
my web servers CTL's. Then the cache would be updated using the new CDP and
existing client certs would work as before.

Thanks in advance.
Ed

You must re-issue client certs if your are going to change the CDP (for CRL)
paths. Following document should help:

http://www.microsoft.com/technet/pr...l=/technet/security/topics/crypto/tshtcrl.asp



Thanks,
Vishal[MSFT]


--
This posting is provided "AS IS" with no warranties, and confers no rights

We currently have a W2K Stand-alone CA that supports issuing client
certificates for a large web farm. We need to add CLR paths that use web
addresses (we currently only have machine name paths). I know how to
add/remove CRL paths on the CA certificate.

My question is do I need to reinstall the CA in each IIS Certificate Trust
List or will the CRL paths be updated automatically the next time they are
published?

Also at some point we need to migrate our existing CA to Win 2003.

Can anyone point me to some resources for these two tasks?

Thanks in advance
Ed

 

[Brian Komar]

Do client certificates need to be re-issued when authenticating using IIS?

I thought that IIS will accept client certificates if the certificates CA is
in ISS' Certificate Trust List and the CRL information is cached using the
CDP information in the certificate that is listed/installed in the CTL.
Then when a client certificate is presented to IIS the cached CRL is used to
reject revoked certs.

I was hoping I could change/update the CA's CDP then reissue the CA to all
my web servers CTL's. Then the cache would be updated using the new CDP and
existing client certs would work as before.

Thanks in advance.
Ed

<snip>

It is not so much a factor of authenticating with IIS. If you are using
the certificate for client authentication, the CA must evaluate the
certificates for revocation when they are presented.

If you change the CDP URLs at the CA, the change is only affected in the
certificates that are issued after the modification. The CDP contains
the URL information put in the certificate by the CA at the time of
certificate issuance. You cannot modifiy this attribute in any way,
shape, or form, as it will invalidate the signature on the certificate.

So, as Vishal stated, you would have to re-issue *all* client
certificates, if you wish to change the URL location. Alternatively, if
you are using a similar path, why not redirect with a CNAME record.

Brian

 

[Brian Komar]

<snip>

It is not so much a factor of authenticating with IIS. If you are using
the certificate for client authentication, the CA must evaluate the
certificates for revocation when they are presented.

If you change the CDP URLs at the CA, the change is only affected in the
certificates that are issued after the modification. The CDP contains
the URL information put in the certificate by the CA at the time of
certificate issuance. You cannot modifiy this attribute in any way,
shape, or form, as it will invalidate the signature on the certificate.

So, as Vishal stated, you would have to re-issue *all* client
certificates, if you wish to change the URL location. Alternatively, if
you are using a similar path, why not redirect with a CNAME record.

Brian

Bad form to respond to your own response, but I wanted to clarify
further...

If the relevant CRL is maintained (and updated prior to each expiration
date of the CRL) in the local machine's Intermediate CA cert store, then
it will not matter whether the client certificates' CDP URLs are correct
or incorrect. Maintaining the CRL in this store would have to be done
manually, or via a periodic batch job.

If the CRL happens to already be kept in the internet cache and is
updated at appropriate intervals, that is *not* sufficient to ensure
that the CRL will be available to perform revocation checking of client
certs with misconfigured CDP URLs. If the CRL also happens to have
*already* been referenced by the same process when validating a
correctly configured certificate and is already loaded into the same
process that is attempting to validate the misconfigured client cert,
then the CRL should be found and used for the client cert. Since IIS
may not actually have to verify its own certificate (clients do that),
this sequence of events is too tenuous to be relied on. This prompted
Vishal's statement that the old client certs should be re-issued, to be
certain they will properly validate.

For more information on how CRL checking is performed (especially the
fact that the certificate chaining engine will check the inetcache
before using the CDP to download a CRL, check the Troubleshooting
certificate status and revocation whitepaper at
http://www.microsoft.com/technet/treeview/default.asp?
url=/technet/security/topics/crypto/tshtcrl.asp

Brian (again)