I’ve installed hundreds, if not thousands, of certificates in Windows since NT 3.5.1 and I’ve never seen anything like that.
What I _really_ see here is “procmon to the rescue!” ☺ From: [email protected] [mailto:[email protected]] On Behalf Of Richard Stovall Sent: Monday, June 2, 2014 11:05 AM To: [email protected] Subject: Re: [NTSysADM] CRM 2011 SSL cert error - Completely down This was the third time I've installed a wildcard cert on this server in its 2.5 year life. Never had a problem before. This time, obviously, there were problems. The AppPool's account could not read new cert's private key. All of the research I did said to manually add a read ACE on the private key's ACL in the certificates mmc snapin. I did that with no effect. Some others people reported success by subsequently adding a similar ACE to the key's ACL in the machinekeys folder. That did not help either. I worked on it for several hours yesterday before calling PSS. When they did call me back, two gentlemen worked on it for about 7 hours and got nowhere. While they were working on it, one of the techs added a read ACE for the AppPool's account to the machinekeys folder's ACL so that the permission would propagate down, but that did not help. Soon thereafter the CRM guys decided that it was definitely a Windows issue and punted to another team. This morning, while waiting for the second team to call, I fired up procmon to see what the heck was really going on. It turned out that the w3wp process was trying to access a key in the machinekeys folder that did not exist anywhere on the drive. Seriously. Phantom stuff. I e-mailed a screenshot to the CRM PSS techs and they suggested deleting the cert and re-importing it. I did and presto! Back in business. It turns out that the ACE on the machinekeys folder's ACL has to exist BEFORE you import the certificate or the whole thing is mangled, and mysterious calls to non-existent keys are created. Why this was not an issue the prior two times I installed previous iterations of the same certificate on the same server is unclear, nor is it evident why the (undocumented) procedure has to be in the correct (undocumented) order. I hope none of you ever have to deal with this, but if you do, the fix is really simple. (If you know the secret handshake.) On Mon, Jun 2, 2014 at 9:55 AM, Richard Stovall <[email protected]<mailto:[email protected]>> wrote: Yup. Very. It is finally resolved. I'll write a post-mortem in a bit. On Mon, Jun 2, 2014 at 8:18 AM, Michael B. Smith <[email protected]<mailto:[email protected]>> wrote: That's....odd. Sent from my Windows Phone ________________________________ From: Richard Stovall<mailto:[email protected]> Sent: 6/2/2014 6:42 AM To: [email protected]<mailto:[email protected]> Subject: Re: [NTSysADM] CRM 2011 SSL cert error - Completely down Still no resolution. The CRM people are handing it to the Windows team because they believe it is an issue with the IIS AppPool not being able to read the private key. (Which is what it looked like all along.) None of the known fixes are working, however. Ugh. On Sun, Jun 1, 2014 at 10:09 PM, Richard Stovall <[email protected]<mailto:[email protected]>> wrote: Yep. I have done this before without trouble, but this time it's not working. I did get a call from PSS (apparently there's one CRM engineer on duty on weekends) about an hour ago and he's (very politely) scratching his head and having me repeat all the troubleshooting steps I've already gone through. Thanks for checking. If we ever get this resolved, I'll post the fix. On Sun, Jun 1, 2014 at 9:50 PM, Susan Bradley <[email protected]<mailto:[email protected]>> wrote: Have you reran then claims config wizard and ifd config wizard after replacing the SSL cert ? (passed this onto a crm listserve) On 6/1/2014 11:01 AM, Richard Stovall wrote: Any one out there using CRM 2011 on premise? I have been for years and went to replace an expiring SSL cert today and now cannot successfully enable claims or IFD. Getting the dreaded "keyset does not exist" error. I have granted the network service account access to the private key, which is usually the answer, but this does not work in this case. I'm completely stumped and PSS is apparently not available to work on CRM issues on weekends.
