Hi, We are using networked HSMs and want to ensure that should they be unavailable for any reason that the CA operations are blocked. During testing I have found that ADCS will fall-back to a non-HSM CSP. Can this behaviour be changed? Thanks, -- Dan

Hi Dan, Thanks for posting in Microsoft TechNet forums. I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience. Thank you for your understanding and support. Regards Kevin

On Wed, 12 Sep 2012 18:19:38 +0000, Dan Colquhoun wrote: We are using networked HSMs and want to ensure that should they be unavailable for any reason that the CA operations are blocked.? During testing I have found that ADCS will fall-back to a non-HSM CSP.? Can this behaviour be changed? Can you provide some concrete examples of the actual behaviour you're seeing? If the private key of the CA is truly protected by an HSM, and that HSM is not available, then CA operations will fail. There is no "fall back" built-in to ADCS, with one notable exception and that is for the CAExchange certificate. Paul Adare MVP - Forefront Identity Manager http://www.identit.ca Base 8 is just like base 10, if you are missing two fingers. -- Tom Lehrer

Have you tested it with the below options: "Choose which cryptographic providers can be used for requests" 1. Requests can use any provider available on the subject's computer 2. Requests must use one of the following providers:Thanks.

Hi Paul, thanks for the quick reply. The example you cited is actually the only case I've come across so far. It was during the build of a developement lab. We hadn't actually made it to the point where we had templates created/midified and end entity certificates being requested. The subordinate/issuing CA's HSM was offline for a bit and when I checked if it was working again by having a look at the CA service status I accidentally dismissed the prompts to present the smartcards to load the CA's private key into the HSM. Checking the logs I noticed the following: Log Name: Application Source: Microsoft-Windows-CertificationAuthority Date: 9/7/2012 2:06:26 PM Event ID: 88 Task Category: None Level: Warning Keywords: Classic User: SYSTEM Computer: [FQDN] Description: Active Directory Certificate Services switched to the default provider for encryption keys. Microsoft Strong Cryptographic Provider Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-CertificationAuthority" Guid="{6A71D062-9AFE-4F35-AD08-52134F85DFB9}" EventSourceName="CertSvc" /> <EventID Qualifiers="33370">88</EventID> <Version>0</Version> <Level>3</Level> <Task>0</Task> <Opcode>0</Opcode> <Keywords>0x80000000000000</Keywords> <TimeCreated SystemTime="2012-09-07T18:06:26.000000000Z" /> <EventRecordID>9611</EventRecordID> <Correlation /> <Execution ProcessID="0" ThreadID="0" /> <Channel>Application</Channel> <Computer>[FQDN]</Computer> <Security UserID="S-1-5-18" /> </System> <EventData Name="MSG_E_USE_DEFAULT_CA_XCHG_CSP"> <Data Name="DefaultProviderName">Microsoft Strong Cryptographic Provider</Data> </EventData> </Event> I also saw a new CAExchange certificate had been created. From your reply it sounds like this is expected behaviour. Should I expect that after the CA builds and service deployments (e.g. OCSP, CRL CDPs, NDES etc.) are completed successfully and the CAExchange certificates exist that this fallback would happen again and a new CAExchange certificate would be created? Or will the function fail/block?

Thanks. We'll be checking and testing that as well, but we're not progressed to template configuration yet for issued certificates. Unless there's a CAExchange certificate template that I could/should modify? Paul's answer suggests this isn't the case.

On Fri, 14 Sep 2012 20:43:40 +0000, Dan Colquhoun wrote: From your reply it sounds like this is expected behaviour.? Should I expect that after the CA builds and service deployments (e.g. OCSP, CRL CDPs, NDES etc.) are completed successfully and the?CAExchange certificates exist that this fallback would happen again and a new CAExchange certificate would be created?? Or will the function fail/block? This is expected behaviour, and will continue to be so even after you've got your solution in place completely. If this is still an issue for you then according to the documentation, you should be able change the behaviour by doing the following: 1. Modify the issuance requirements for the CA Exchange template to use only the HSM vendor's CSP. 2. Ensure that Local System on the CA has Read and Enroll permission on the CA Exchange template. 3. Modify the registry on the CA to force it to use only the settings in the certificate template by running: certutil ?setreg ca\CRLFlags +CRLF_USE_XCHG_CERT_TEMPLATE 4. Restart Certificate Services. Note the I said this should work. I've never actually had a need to do this before. You also need to consider the implications here. If you're configuring your HSM such that it requires a PIN or more than 1 of 1 protection of the CA's private key, then your CA will never be able to successfully issue a CAExchange certificate unless you've got someone waiting around every week when the previous certificate expires. Paul Adare MVP - Forefront Identity Manager http://www.identit.ca People who deal with bits should expect to get bitten. -- Jon Bentley