PKI Question -- Moving CA to New Hardware

[John Liles]

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

 

[Dobromir Todorov]

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

 

[John Liles]

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
>
>
>