none
ADLDS SSL - fatal error occured when attempting to access the SSL server credential private key

    Question

  • Hi All,

    I am having trouble with installation of my internal domain PKI cert on ADLDS.  I have used this PKI for other server SSL so know that part is valid.

    Upon import of the PFX into computer personal certificates, I have verified its okay via indication I have the private key that corresponds to this certificate.  Checking certification path, everything leads up to the root PKI and all is well.

    I restart my ADLDS and try to connect SSL and no go.  Server event logs indicate an Schannel error:

    A fatal error occured when attempting to access the SSL server credential private key.  The error code returned from the cryptographic module is 0x8009030d.  The internal error state is 10001.

    Following the MS ADLDS instructions for SSL it states to add the network service rights to the MachineKeys file.  It doesnt say what type of rights so I assume read & execute.  I am unsure which file to change attributes so for now apply this to all of them.

    Restarting the ADLDS instance doesnt solve the problem.  I then tried launching Certificates MMC and instead of computer, used service and picked my ADLDS instance.  Under Personal I imported the PFX, restarted ADLDS, but still no luck.

    I am doing file level audting on the machinekeys folder and see security failures via network service.  What gives?

    Wednesday, August 25, 2010 11:59 PM

Answers

  • Hi,

     

    Based on the process monitor, the private key file that it was trying to access is 4d0e9759c3974f256ec070ade1ad673f_***-*** in C:\ProgramData\Microsoft\Crypto\Keys.

     

    2:23:13.1867291 AM      lsass.exe           480       CreateFile            C:\ProgramData\Microsoft\Crypto\Keys\4d0e9759c3974f256ec070ade1ad673f_***-***       ACCESS DENIED            Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, AllocationSize: n/a, Impersonating: NT AUTHORITY\NETWORK SERVICE

     

    It seems that CNG is being used in your environment and therefore the folder path is different. Please grant read permission to Network Service on the file and check the result.

     

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, September 03, 2010 2:30 AM
    Moderator

All replies

  • Step by step instructions are listed at http://technet.microsoft.com/en-us/library/cc725767(WS.10).aspx

    In addition, the certificate must satisfy requirements listed in http://support.microsoft.com/kb/321051

    Have you confirmed that both of these have been followed?

    hth
    Marcin

    Thursday, August 26, 2010 1:09 AM
  • Thanks Marcin, those were the instructions I have been following.  So either I am still not following something correctly or there is something different in my environment that isnt covered by those instructions.

    What sticks out to me is the auditing of the actual file access of C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys showing failure of NETWORK SERVICE.  I have checked each file individually and it has read & read/execute to NETWORK SERVICE.

    I continue to get the same Schannel errors as well which I assume are because of some failure to read the certificate properly.

    Anybody else have this issue?

    Thursday, August 26, 2010 6:39 PM
  • Hi,

    It should work if the Network Service has read permission on the machinekey file.

    To check the security setting on the file, please help collect the following information on the AD LDS server:

    • Please run certutil -store my > cert.txt
    • Please run cacls C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\* > acl.txt

    After that, please upload the cert.txt and acl.txt files to the following space:

    https://sftasia.one.microsoft.com/choosetransfer.aspx?key=c496b9c4-ded8-4769-9eb4-e1adcc833370
    Password: %J_BVJD8eWoq)mgs


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, August 27, 2010 2:55 AM
    Moderator
  • Thanks Joson,

    I have zipped the files and uploading them now, I appreciate your help looking into this!

    Paul

     

    Monday, August 30, 2010 9:33 PM
  • Hi,

    Thanks for your information.

    According to the files, the certificate used for LDAPS is Serial Number: 17269fb100000000001c and it is generated based on the certificate template OpsMgrCert. The private key file of the certificate is 00a0580f79**** and it seems that you have granted full control permission to Network Service. As a result, Network Service should be able to access the private key.

    Based on the current situation, I suggest that you enable process monitor and then reproduce the issue. Once the issue occurs again, please save the process monitor and upload the file to me.

    Process Monitor
    http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Tuesday, August 31, 2010 4:03 AM
    Moderator
  • Thsnka again Joson - I have captured 2 proc mon dumps, the first being when I start the ADLDS service and second when I attempt LDP connection via SSL.  In either case I get windows event log errors indicating an SSL cert issue.
    Tuesday, August 31, 2010 6:26 PM
  • Hi,

     

    Based on the process monitor, the private key file that it was trying to access is 4d0e9759c3974f256ec070ade1ad673f_***-*** in C:\ProgramData\Microsoft\Crypto\Keys.

     

    2:23:13.1867291 AM      lsass.exe           480       CreateFile            C:\ProgramData\Microsoft\Crypto\Keys\4d0e9759c3974f256ec070ade1ad673f_***-***       ACCESS DENIED            Desired Access: Generic Read, Disposition: Open, Options: Sequential Access, Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, AllocationSize: n/a, Impersonating: NT AUTHORITY\NETWORK SERVICE

     

    It seems that CNG is being used in your environment and therefore the folder path is different. Please grant read permission to Network Service on the file and check the result.

     

    Thanks.


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Friday, September 03, 2010 2:30 AM
    Moderator
  • Hi,

    How's everything going? We've not heard back from you in a few days and wanted to check the current status of the issue.

    If you need further assistance, please do not hesitate to respond back.


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Wednesday, September 08, 2010 1:11 AM
    Moderator
  • Thanks for the follow up, I missed your earlier post which I have verified as the solution to my issue.  I appreciate you taking the time to look at my logs and figure out what is different in our environment.  Thanks again,

    Paul

     

    Wednesday, September 08, 2010 5:42 PM
  • Thanks for your update. I am glad that the issue has been resolved.

    Have a nice day.

    Joson Zhou

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com


    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    Thursday, September 09, 2010 1:16 AM
    Moderator
  • Hi,

    Thank you for this great tool. I was not aware for this tool.

    I was getting the same error with a Windows 2000 SP4 domain controller on which I was activating LDAPS: "A fatal error occurred when attempting to access the SSL server credential private key. The error code returned from the cryptographic module is 0xffffffff". The rollup 1 for Windows 2000 SP4 has solved my issue.

    Regards

    Richard GOTWE

    Wednesday, January 12, 2011 2:21 PM