Hi all,First time poster, not many forums around that talk about PKI. I have a standard set of procedures that I have used many times. We have a pretty elaborate PKI environment that has both offline and online components. My issue is the following. In my DEV environment everything works 100%, my Prod is 100%. We are in the process of rebuilding the QA environment (relocating the equipment and new equipment), anyhoot. I created some "fake" third party CA's to emmulate the real Third Party Signers, no issues there. Then building out my internal subordinate "Root" (offline), is tied to an HSM. All goes well until I take the CSR and get is signed by the "Fake" third party CA. I bring the Signed cert and install it, and then trouble hits. The CA tries to launch the CSP Token (the HSM software) but can not launch it and the CA is stuck in an infinite loop trying to get the Token from the HSM. I have used the same software and run books several times; however this last attempt this issue is appearing. I have verified that the networking is fine by starting another CA in the same Security World/HSM and it launches as expected. I know this might be hard to understand but a little frustrated and hoping for some things to look at that I have not thought of yet.

It sounds like your fale third party CAs have misconfigurations.Be sure that they are publishing CRLs and that the CRl publication points are accessible by the CA with issues.Also, consider loading the CRLs locally using certutil -addstore CRLFile.crl RootBrian

yes both the Crls and certs are published and all my policy\crlflags are set correctlyI even throw the no crl check on the "internal root" ca for added measure. I don't believe it is the CRLs as you can visibilly see the CA loose its focus (the blue title bar shifts to grey) as if another application (the hsm token load s/w) is trying to spin up but fails. I do realize this is hard to imagine, as I don't think I am doing justification in my explanation. If it helps, I am using nCipher NetHsm, and running the nCipher CSP. I verified the CSP are available by certutil -csplist and ran the CSPtest.exe from ncipher with positive results on both. My gut says it is the hook between the CA and the HSM stuff. I might try your suggestion and use another CA to sign the CSR as another test to try. However the same configuration is made in my DEV environment and all works so I don't think it is a misconfiguration on the Fake GS CA's.

When you configured the HSM CPS at the CA, 1) did you enable the option to interact with the desktop2) When you connect to the CA, are you possibly using RDP. If so, make sure that you are connecting using the /admin (or /console) switch. The ncipher interaction only occurs with the console.3) In R2 and 2008, the interaction takes place "off-screen" you have to click a message box to view the message, and then do you PINs etc. for the OCS cards.Brian

Brian, thanks for the suggestions. The environment is all VM sessions and I have built about 30 of these CA's (considering all the environments and testing purposes) and this is the first time I have experienced this issue (this should cover points 2 &3). The s/w from Ncipher is 10.5 (older version then available at this time) and it doesn't have the Ineract switch available (this covers point 1).I am going to build out another Fake third party and have this a straight out of the component box install, I was putting in the capolicy file:[Extensions]2.5.29.15 = AwIBBg==Critical = 2.5.29.15run the following certutil commands:certutil -setreg policy\editflags -EDITF_ADDOLDKEYUSAGE > resulting in editflag reg_dword = 83e6 (33766)certutil -setreg policy\EnableRequestExtensionList +"2.5.29.32"not other changes are done to the FAKE CA's.

The option to allow the CSP to interact with the desktop is set in the CS install wizard, not in the nCipher install/config wizard. Your symptoms really sound like you missed selecting this check box.Paul Adare CTO IdentIT Inc. ILM MVP

Paul,I will have to check into this. but I have install scripts for these types of CA's and it builds an answer file for the install, oc_certsrv.txt.I do appreciate both of you helping me troubleshoot this. I am not new to building CA's and my run books are pretty thorough as are my scripts that build them, that is why I am so frustrated with my current situation. Nothing makes sense to me, as far as I can tell, everything is in place and configured correctly. However there has to be something I overlooked or I would not have started this thread..

Not that it has helped, I was on the phone with nCipher for the entire day, running this and running that. And I leave today with no progress at all in my issue. It comes down to the fact that nCipher's software is not prompting for the card set needed. It tries but doesn't happen. If I take off the password to my card (currently 1 of 1 for this environment) and have the card in the HSM it works. but with password or card removed I get the hung state. ARRRRGGGHHH...

I recommend the following:1) Backup the %nfast_kmdata%\local folder2) export your CA certificate to a base 64 file3) Backup your CA database and registry4) Uninstall certificate services5) remove the CA certificate from the local machine store (delete it)6) import the certificate back in certutil -addstore my certfile.cer7) Use certutil -repairstore to reassociate the certificate with the private key8) run certutil -verifystore my to verify everything worked9) Reinstall ADCS10) This time, say to use an existing CA certificate and enable the option to Allow interaction with the desktop (as we have stated on every response in this thread!!)11) Restore the CA database from backup and the registry12) all should workBrian

Ok an update. Was working with nCipher and DSE from MS. After several attempts, and logs and monitoring. We have no clue why this is happening. We looked at all previous installations and on the VMWare VM's all the "ALLOW INTERACTION..." were checked, this was not done manually so can only conclude that the NCSS software did this upon installation. The small Kink in this, the Microsoft Virtual Server R2 VM's using the same procedures / scripts this box was not checked and they are working fine. So the end result I added a line to ensure that his box is checked in teh SERVICES.MSC for Certificate Services under the LOGON tab. In doing this, everything worked as expected. Still no answer to WHY this install this didn't work out of the box like all the installs before it. Gotta love this stuff :)Thanks to Paul and Brian, whom I didn't doubt their answer, but more curious why a standard set of procedures that worked before didn't work now with no changes to the system except name of CA and which CA signed it.