Re: Adding second Subordinate Issuing CA

Brian Komar [MVP]

unread,

Nov 2, 2006, 4:09:29 PM11/2/06

to

In article <A99B7F70-0A64-40D8...@microsoft.com>,
Pega...@discussions.microsoft.com says...
> We currently have one Subordinate Issuing CA adn we want to add a second one
> for fault tolerance and failover. What is involved in building a second
> Subordinate Issuing CA? Is it simply a matter of creating a new Enterprise
> Subordinate CA during setup?
>
> Thanks in advance
>
Yep, that is really all it takes from a technology perspective.
Brian

Rich Raffenetti

unread,

Nov 10, 2006, 6:00:49 AM11/10/06

to

Taking that a little farther...

I expect that I want to configure the second issuing CA the same as the
first. That is, so it issues the same certs, for example, the same kind of
auto-enrolled certs. Is that correct?

Do they know about each other and work together?

Will the request for a renewal be fielded by either of the issuing CAs?

Is this an effective way to replace an issuing CA, that is, to put up a
second with identical configuration and after awhile, to remove the first?

I don't remember this in the MS course or in your book. I may have missed
that. References would be appreciated. Thanks.

"Brian Komar [MVP]" <bko...@nospam.identit.ca> wrote in message
news:MPG.1fb41a89f...@msnews.microsoft.com...

Brian Komar [MVP]

unread,

Nov 10, 2006, 7:42:03 AM11/10/06

to

Answers inline...

In article <uA5S6dLB...@TK2MSFTNGP02.phx.gbl>,
raffe...@comcast.net says...

> Taking that a little farther...
>
> I expect that I want to configure the second issuing CA the same as the
> first. That is, so it issues the same certs, for example, the same kind of
> auto-enrolled certs. Is that correct?

That is the best practice. In the event of CA failure, the second
issuing CA is still available to issue new certificates.

>
> Do they know about each other and work together?

Both CAs are listed in the Enrollment Services container of AD and are
available for certificate issuance. They do not, per se, work together.
Which ever hears the request first will respond to the certificate
request.

>
> Will the request for a renewal be fielded by either of the issuing CAs?

Yes, whichever responds first.

>
> Is this an effective way to replace an issuing CA, that is, to put up a
> second with identical configuration and after awhile, to remove the first?

Not really. If you are planning on decommissioning a CA, you have to
worry about CRL maintenance. If you just remove a CA from the network,
the certificates issued by that CA will start to fail as soon as the
next CRL is needed to be published.
I recommend, if you are planning to replace an issuing CA, to remove all
certificate templates from that issuing CA. You would still leave it
running, publishing updated CRLs, until the last certificate issued by
that CA expires. Only at that point, should you consider retiring that
CA. Finally, if you have archived encryption certificates at that CA,
you must consider how you are going to maintain these archived
certificates.

>
> I don't remember this in the MS course or in your book. I may have missed
> that. References would be appreciated. Thanks.

Sorry, on the road... No time to look up references presently
Brian

Rich Raffenetti

unread,

Nov 11, 2006, 10:05:21 AM11/11/06

to

Thanks Brian.

So a second, identically configured CA is not really a complete-standin for
the other. The certificates issued by the first CA are still tied to the
first CA and specifically, the CRLs from it. If a cert is being used, then
there had better be an unexpired CRL for the CA hierarchy.

Depending then on the size of the institution, one can search for certs
issued by the first CA and remove them before expiration so they will be
replaced by the second CA either automatically or by the manual processes
that may be in use. The issued certificates list in the CA is a good source
of information for doing that. I suppose one can do queries with certutil
to list only certs that have not expired, etc.

In our environment, that may be practical. We have a large number (~1600) of
auto enrolled login certs that expire monthly. We have ~100 smart cards
that would have to be reissued (our reissue process is manual). And we have
the usual domain server certs that get issued manually. And our smart cards
are not scattered around the globe. We have not done any encryption either.

Would there be additional issues if we had created encrypted resources
(email, files)?

Again, if available, references would be appreciated. Thanks.

"Brian Komar [MVP]" <bko...@nospam.identit.ca> wrote in message

news:MPG.1fbe2f96f...@msnews.microsoft.com...

Rich Raffenetti

unread,

Nov 11, 2006, 10:25:03 AM11/11/06

to

I heard that it might be a good idea to implement an issuing CA in a virtual
server. That would avoid the usual issues of restoring a server backup to
different hardware if the current server fails or if the server becomes to
slow for the increasing load. Is that a good idea?

If I were starting all over with a new PKI, then I would also be interested
in doing same for our offline, standalone root CA. As it is, I turn it on
only every four months to generate a new CRL and do backup. But someday the
hardware will be very obsolete and I wonder how I will deal with that. Is
there a process for moving a CA (e.g. the root CA) from one hardware
platform to another?

"Brian Komar [MVP]" <bko...@nospam.identit.ca> wrote in message
news:MPG.1fb41a89f...@msnews.microsoft.com...

Brian Komar [MVP]

unread,

Nov 11, 2006, 8:30:01 PM11/11/06

to

Brian Komar [MVP]

unread,

Nov 11, 2006, 8:33:01 PM11/11/06

to

In article <eRV8MWa...@TK2MSFTNGP03.phx.gbl>,
raffe...@comcast.net says...

> I heard that it might be a good idea to implement an issuing CA in a virtual
> server. That would avoid the usual issues of restoring a server backup to
> different hardware if the current server fails or if the server becomes to
> slow for the increasing load. Is that a good idea?
>
> If I were starting all over with a new PKI, then I would also be interested
> in doing same for our offline, standalone root CA. As it is, I turn it on
> only every four months to generate a new CRL and do backup. But someday the
> hardware will be very obsolete and I wonder how I will deal with that. Is
> there a process for moving a CA (e.g. the root CA) from one hardware
> platform to another?
>

<snip>
The requirements for product group support are:
- Virtual Server 2003 R2
- Host in the VM is running Windows Server 2003, SP1

In addition, you can not use a PCI or SCSI HSM (if using them), you can
only use network-attached HSMs, such as the Luna SA, ncipher netHSM, or
Safenet Orange External.

You can move the CA by doing disaster recovery. The topic is covered in
my previously referenced book. You must do manual backup and
restoration, as a system state will fail for this type of migration.
Some good details are available at
http://support.microsoft.com/kb/298138

Brian

Rich Raffenetti

unread,

Nov 12, 2006, 10:53:14 AM11/12/06

to

Thanks much.

"Brian Komar [MVP]" <bko...@nospam.identit.ca> wrote in message

news:MPG.1fc035c7a...@msnews.microsoft.com...