Hi all, I´m just about to start the install of a 2 tier PKI hierarchy, and I would really like to get a second opinion on the design. The PKI will consist of the following:a. 1 standalone CA Root ( offline ) - Windows Server 2008 R2 Stdb. 2 Issuing CA´s ( online ) - Windows Server 2008 R2 Enterprisec. 2 web servers for CDP, OCSP and CES Certificate validity periods and key sizeOffline Root CA - 20 Years - 4096 -SHA1Online Issuing CA´s - 10 Years - 2048 - SHA1 I´ll use the default CSP ( RSA#Microsoft Software Key Storage Provider ) CDP´s will only be published via HTTP ( not LDAP ) Clients range from Windows XP SP3, Windows Server 2003 to Windows 7 and Windows Server 2008 R2 So I have those questions to ask:1. Is the key size for the Root and Issuing CA´s, sufficient? ( would selecting a different hash make it more secure )2. Is it correct to select SHA1 hashing algorithm as we still have XP SP3?3. Is it correct to use the default CSP 4. (extra question ) - One of my college suggest to keep the Root CA connected to the network, updated via WSUS and restrict access to it using ACL´s in the Cisco units and have the CA DB on a removable device that would not be connected unless when CRL renewal takes place. I must admit that he has a good point arguing that it is better to know the status of the server at all times, rather than have to find out if something is broken at the time of CRL renewal. What are your thoughts on this matter?Best regardsKonradKonráð Hall

> Offline Root CA - 20 Years - 4096 -SHA1make sure if all ypur software and hardware can work with long keys (more than 2048bit).> Is it correct to select SHA1 hashing algorithm as we still have XP SP3?of course! Actually Windows XP SP3 can verify certificates with SHA2 signature, but cannot enroll these certificates. So, your choice is correct.> Is it correct to use the default CSPit depends. While you haven't vendor-specific hardware (HSMs, smart cards, etc) you should use default CPSs. In cases when you use smart cards it is recommended to use smart card vendor's CPS.> 4. (extra question ) - One of my college suggest to keep the Root CA connected to the network, updated via WSUS and restrict access to it using ACL´s in the Cisco units and have the CA DB on a removable device that would not be connected unless when CRL renewal takes place. I must admit that he has a good point arguing that it is better to know the status of the server at all times, rather than have to find out if something is broken at the time of CRL renewal. What are your thoughts on this matter?it depends. If your organization dictates that Root CA must be turned off — it must be turned off. Remember that if server is online, it may be accessed in more easy way, rather than if server is offline. http://www.sysadmins.lv

Adding in on the last question.I would never deploy a root CA connected to the network (especially using a software key as you are).This is not best practices, and is in fact, a worst practiceBrian

Hi guys, and thanks for your answers.I'm still thinking about the Root CA and the pros and cons to keep it offline or online. I agree that it is not acceptable to use a software key if one is to keep the root online, so let's assume that a HSM is used, and as before the CA Database would be on a removable device and disconnected when not in use.Pros - onlineHardware monitoringPatching ( WSUS )Virus protectionCRL distributionCons - onlineNetwork attack surfaceManagement procedures, connecting the CA DB and start the CAPros - offlineNo network attack surfaceCA DB in placeCons - offlineMonitoring and patchingCRL distributionManagement procedures1. Would you add somethings to those pros and cons?2. Would you recommend any special HSM2. ( Silly question ) Have you guys never been in a situation, logged on a offline root ca and thought, "damn it would be good if I had a connection to the network"?Anyways hope you drop me a line or two on this matter, as I would like to have some weight if/when I get into a debate whether to keep it offline or not.KonradKonráð Hall

> 1. Would you add somethings to those pros and cons?shure:Cons - online - if your Root CA will be compromised in any way, you will loose ALL PKI. You SHOULD use offline Root CA and there is no other choices.> 2. Would you recommend any special HSMthe general question is OS support in HSM. And then you will need to choose dedicated HSM (PCI card) or network-attached HSMs. PCI is preferred for Offline CAs and network-attached HSMs are good for online CAs.> 2. ( Silly question ) Have you guys never been in a situation, logged on a offline root ca and thought, "damn it would be good if I had a connection to the network"?no.http://www.sysadmins.lv

Let's be more blunt, as my last reply was too touchy/feely.<RANT>NEVER DEPLOY A ROOT CA ON THE NETWORK- YOU WILL FAIL ANY AUDIT- IF COMPROMISED, YOU WILL NEED TO REDEPLOY THE PKI AND ALL CERTS ISSUED BY IT</RANT>Hope I was more clear this time.Brian

Well guys, I think you persuaded me into deploying an online root..... just kiddingAn offline Root it will be and no more beating around the bush.I appreciate your time you took to comment on the issue.Best RegardsKonradKonráð Hall

No problemHope I did not come across too crassBrian

Gents,have you ever seen compromised CA ?If it happens, it does mean someone is already domain admin and has full access to all domain servers/WSs.If subordinate CA will be compromised, you will revoke the subordinate CA cert and will also redeploy all clients certs.Isn't it the same ?

This is not necessary to compromise whole domain. You need at least local admin rights. If subordinate CA is decomissioned, you may quickly rededploy certificates using autoenrollment (this will required in both cases). You don't need to redeploy new root certificate. In compromised Root CA case you will have to deploy new root certificate manually. Also if subordinate is compromised you revoke it certificate and clients will see it in short time. In root CA case there is no way to revoke root certificate, therefore there is no way how to tell to everyone that root CA is compromised. http://www.sysadmins.lv

I.e. since root CA (public) certificate has any client in the local certificate store, it can't be deleted/revoked or checked via CRL. It can be only expired.I.e. this root CA certificate will be always valid for any server (with root CA cert in the local cert store).Is it correct ?

Yes. The only correction — Root certificate can be deleted, but this is manual process.http://www.sysadmins.lv

I.e. since root CA (public) certificate has any client in the local certificate store, it can't be deleted/revoked or checked via CRL. It can be only expired.I.e. this root CA certificate will be always valid for any server (with root CA cert in the local cert store).Is it correct ? No, this is not correct. It is true to say that you cannot revoke a root CA cert, you can. However, there's really no need to revoke a root CA cert as the vast majority of relying parties will not check a root CA cert for revocation. Any relying party that follows the relevant RFC will never check a root CA cert for revocation status as the RFC recommends that revocation checking stop at the second highest certificate in the trust chain. The fact that one has the root CA cert in their trusted root store has nothing at all to do with one's ability to either delete said cert nor whether or not it can be revoked.Paul Adare CTO IdentIT Inc. ILM MVP

> It is true to say that you cannot revoke a root CA cert, you canbut you can't to put this cert to CRL. At least Windows CA don't support this. When root CA certificate is revoked and you try to publish new CRL, certsrv fails to sign new CRL and this certificate will never appear in CRL. May be I have missed something but I don't know ways how to put root CA certificate to CRL. http://www.sysadmins.lv

Gents, thanks for answer.