Thanks a lot everyone. Sorry if the questions are basic, but as I said I've never messed with PKI, and there's no documentation on what we have right now. I am actually not sure where the CRL is, looking for that now, but the idea of just moving one of our issuing servers to the DR site sounds very appealing. We're mainly using this for user certs for VPN access, and we have about 2500 clients, so doing it that way may be enough. And if I can take our root CA offline and just store it on a SAN volume mirrored between our primary and DR sites that may be enough. OK, got some reading to do. Thanks again. Ryan
From: [email protected] [mailto:[email protected]] On Behalf Of Eric Morrison Sent: Tuesday, November 11, 2014 7:00 PM To: [email protected] Subject: RE: [NTSysADM] RE: making ADCS resilient There's really no reason to have two subordinate issuing servers unless you're getting tons of cert renewals, or your CRL is on those servers. Root should always, ALWAYS, be offline and never connected to the network. Only time to bring it online is to renew the CRL, or to issue a new cert to your Sub CA. You could take one of the Sub CAs and move them to your DR site, assuming they're portable VMs or something like that. I would also recommend publishing your CRL on an internal web server, or two. Using common names, not server names, to publish the CRL URL with. Something like PKI1.domain.com and PKI2.domain.com. This will give you a lot of flexibility going forward. Really, the resiliency focus should be on the CRL and making sure it's available for your systems to check at all times. Hopefully this helps! We just rebuilt our PKI infrastructure with a PFE and tried to go best practice and make it as practical as possible and low maintenance as possible since we have a small team managing everything. Thanks! Eric Morrison From: [email protected] [mailto:[email protected]] On Behalf Of Ryan Shugart Sent: Tuesday, November 11, 2014 5:49 PM To: [email protected]; [email protected] Subject: [NTSysADM] RE: making ADCS resilient Thanks everyone. So if I'm understanding right, the root CA can be shut down with no issues, and I can just bring up new issuing servers in our DR site and they'll work along side the ones at our main site? Thanks. Ryan From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Tuesday, November 11, 2014 11:55 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] RE: making ADCS resilient I advise my clients to only have the root server online when they are bringing up new DCs or renewing certificates for the sub-authorities. They also bring it up once a month to patch and then create a full-backup that goes over-the-wire to the DR site. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ryan Shugart Sent: Tuesday, November 11, 2014 1:35 PM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] making ADCS resilient Hi all: I just got handed our ADCS infrastructure, and was told that it needs to be made resilient. From what I can tell (the old admin left the company and didn't provide much documentation) we have a two teer infrastructure with one root CA and two issuing CAs all running Windows Server 2012. From what I'm seeing now, I should be able to bring up another issuing server relatively easily in our DR site and we should be good there, but the root CA isn't that easy to make resilient, and may not need to be resilient anyway. So question, is this what people are doing to make ADCS resilient across multiple sites or is there another approach to this? Thanks. Ryan Ryan Shugart LAN Administrator MiTek USA, MiTek Denver 314-851-7414 MiTek Holdings, Inc., 2011-2014, All Rights Reserved ________________________________ This communication (including any attachments) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
