JohnLiles
Tue Mar 11 12:33:07 CDT 2008
Thanks, Dobromir. It's always good to hear from someone who's successfully
been through the process already!
JL
--
JL
"Dobromir Todorov" wrote:
> John,
>
> I have followed these steps in KB298138 and I can confirm that this works.
>
> To your specific questions:
> - the procedures are the same for the root and subordinate CAs (although if
> I remember correctly, I've had to import the certificate chain on subodinate
> CAs...)
> - It doesn't - the connection between the root and subordinate CAs is the CA
> certificate (by which the root delegates authoritity to subordinates), and
> the trust established on the subordinates (by putting the Root CA on their
> trusted CA list, subordinates become part of the PKI hierarchy). As long as
> these two are met, it doesn't matter which is upgraded first and which is
> next. Not only can they run different Windows versions, these can be
> products from different vendors as well.
> - See below
>
> Certificates and trust are pretty much checked locally, on the client or
> server, and often do not require access to the servers. There are a few
> exceptions though:
> - CRL checking - in order to verify wether a specific certificate is valid
> (as in - has not been revoked), along with other checks, the client or
> server may contact a CRL distribution point (CRLD) with a request to
> download the CRL. If the CRLDP is on the actual CA that you are currently
> upgrading, clients and servers may fail to validate certificates. It is
> important to make sure that you cover CRLDPs, as otherwise some of your
> applications - such as Web protals, or TLS protected e-mail, or OCS for
> instance - may just stop working if they are unable to verify the
> certificate validity. In order to avoid this, you should either disable CRL
> checking while you are doing the server upgrade (some products, such as
> Cisco routers and IOS in general may allow for tolerance if the CRL is not
> available and use an older version), or put another server in place to
> publish the CRL using LDAP or FTP, and make a change in DNS to point to that
> server. Once the original server is back online, you will remove the CNAME.
> If you are upgrading an offline root CA, you've probably already taken care
> of that scenario, and your CRLDPs reside on other servers anyway, so you can
> proceed with the upgrade at any time.
> - Access to Certificate Web Pages and online certificate requests - while
> you are doing the upgrade, clients will be unable to apply for new
> certificates, or renew expired certificates. I assume you can use a
> maintenance windows to carry out the upgrade and that wouldn't be a major
> issue.
>
>
> --
> ---
> HTH,
> Dobromir
>
> Visit
http://www.iamechanics.com
>
> "John Liles" <JohnLiles@discussions.microsoft.com> wrote in message
> news:7DBAF720-1B54-458D-94AF-3A8393D3ADAE@microsoft.com...
> > We're preparing to lease refresh our PKI servers, which will mean moving
> > them
> > to new hardware. I've found a good Microsoft KB article on this (298138),
> > but wanted to post here to see if anyone else has direct experience with
> > this
> > sort of thing. Specifically:
> >
> > -- are the procedures outlined in this KB article the same for the root CA
> > and the issuing servers?
> > -- does it matter whether the root CA or the issuing servers are done
> > first?
> > -- any landmines to avoid that aren't covered in this article?
> >
> > Thanks in advance for any advice! I really don't want to blow up our PKI
> > infrastructure.
> >
> > --
> > JL
>
>
>