Hi, what are the advantages / disadvantages of clustered CA versus two separate CA installed? When I've got installed cluster then: (-) there is a single point of failure - shared storage; (+) there is a single point of configuration (AIA, CDP, roles and others); (+) single point where I must search certificate (in case of recovery, when I don't know where to find it); (-) more expensive hardware (I need a shared storage, but it may be a iSCSI storage); (-) it's only for certificate issuing role. When I've got installed two separate CA then: (+) there is no single point of failure (if CRL are publishing in other places); (-) there are two points of configuration - on two servers I must provide similar configuration; (-) two points where I must search certificate; (+) cheaper hardware (no shared storage); (+) I can select roles. Do these points cover all main adv/disadv of CA installed in these two configurations? What yet? Book of Brian Komar doesn't answer on my questions, it's rather based on my experience in other areas. It will be two tiered PKI - off line root CA and two separate Enterprise Sub CA or one clustered Enterprise Sub CA. No HSM, no separation certificates for departments. Number of users - between 5000 and 10000 users. Regards, e-micra

the most important thing is that if you have two separate CAs and one of them is down, you will be able to request certificates from working CA. However failed CA will be unable to issue CRLs as the result all issued by this CA certificates will fail until CA server is recovered. In most cases this is decisional point. You should setup two ow more CAs only when you need to separate them with different policies (or certificate types).My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Thanks Vadim, ok, it's clear for me, I must consider it. regards, e-micra

This is easy. You say your aren't going to use an HSM. No HSM TYPICALLY means no cluster. Someone asked this awhile ago: Clustered CA server *without* HSM? http://social.technet.microsoft.com/forums/en-us/winserversecurity/thread/183DF859-20F0-44E7-864C-6FFB280F28DC Besides, I don't think the pluses of clustering will offset the added complexities. Go with two CA's (if you even need two CA's). It'll be easier in the end. Vadim does make a valid point though. CRL signing is the most immediate thing that needs to be taken care of when a CA goes down. Having said that, if you have a backup of the private key, you can achieve this with certuitl. Thanks!

Thanks Sean, I'm sharing your opinion regarding clustering - it's unwanted complexity for company. I've read "Clustered CA server without HSM", ok, just another thing to consider. Probably shared storage will not be a problem - it's a part of bigger project, but I don't know if it's really important to have clustered CA, maybe just single CA on second level will be a better choice? regards, e-micra

I'd say the majority of customers have a single second tier CA. Looking at your requirements, I think that's the way you should go too. Keeping it simple will help in the long run. Besides, adding another second tier CA in the future would be super easy. Start up the root and issue a new certificate to the new issuing CA. With only 10,000 users though, performance shouldn't be an issue even if you decide on one. A few things I want to make sure you do: 1. Make sure you have an external anonymously accessible HTTP CDP. More times than not, someone implements a PKI that they think they will ONLY use internally, and then they decide they want to do DirectAccess or go Native Mode for SCCM and they wish they had an external anonymously accessible HTTP CDP. 2. Make sure that the HTTP path is the first published path in the CDP (besides the C:\blah\certentroll). There's a debate on whether or not the LDAP path is even necessary if you go with an external anonymously accessible HTTP CDP. Either way though, if you have the HTTP path first, then you won't suffer from slow timeout periods if you do decide to implement something like DA or NM for SCCM. If the LDAP path is first in these scenarios then the external client will have to timeout before hitting the HTTP path. Yuck. 3. BACKUP YOUR CAs!!! I typically recommend getting system state backups AND backing up the key/database/registry separately. You can script the individual components using certutil and reg. Put that script in a scheduled task and have it run daily (the key just needs to be backed up once). Thanks!

Thanks again Sean, it's not my first PKI implementation, but this time customer requires some kind of HA (and asking for clustering) and I must prepare for him possible options to choose. It may be my first implementation of clustered CA, but I must have solid base to implement cluster. Why performance may be and issue? When CA is loaded except time of signing certificates and other data? I know that I must have anonymously accessible HTTP site (for CDP) and that the most important is http path than LDAP path. I know that http side must be available from inside and outside (Internet).

I'm not sure I understand. Performance is almost never an issue with a CA. Just make sure to explain to the customer what implications there are if the CA is down (namely, can't issue certificates). If this is a big problem then maybe clustering is the way to go. But most likely it isn't. I'm sure you understand this, but most people don't understand that certificates still work fine even when the CA is turned off. Thanks!

> namely, can't issue certificates this is not the biggest issue. Also, clustering doesn't solve performance issues (as long as only single node is active at a time). The biggest issue with faild CA is that CA server cannot issue CRLs as the result many applications (that are using certificates) will fail. As I said this can be decisional point. > but most people don't understand that certificates still work fine even when the CA is turned off until current CRL is expired...My weblog: http://en-us.sysadmins.lv PowerShell PKI Module: http://pspki.codeplex.com

Here is the one consideration that has been missed in this thread, recovery of archived certificates. WIth a clustered CA, you can still recover the archived certificates if one node is down. With two CAs, you cannot recover archived certificates until the failed CA is brought back online Other than that, I agree with all other statements in this thread. The only time I deploy clusters personally is when the customer has high availability requirements that can only be met with a cluster. Arguments for two CAs - I can handle CRLs through re-signing the CRL at another box where I provide access to the failed CA's private key and certificate - I can handle certificate enrollment requests through a second CA Arguments for Cluster - I am using FIM CM and profile templates can only reference a single CA for a specific certificate template - I cannot have failure of access to archived certificates HTH, Brian

That's a good point, I hadn't considered accessing archived certs. How prevalent is key archival in the field by your estimation?

It is subject to whether the customer has deployed SMIME or EFS (typically). If yes, then it is the number of client certs deployed Brian

Thanks Brian, Sean, in my case archived certs will be important - for EFS and SMIME, but if server can be restored/recovered (in non-clustered configuration) then 2 days, I suppose, it won't be a problem, but I must consult it with client. What amount of certificates per day can be a problem? Looking at http://blogs.technet.com/b/pki/archive/2010/01/12/windows-ca-performance-numbers.aspx I don't know why performance is considered? Single CA can process and give more 100 thousands of certificates per day - in most cases it's sufficient for most cases. e-micra