Blog: Certificate

There was a 2012 R2 server I had configured and been using to test with for several months. After a few months, I could no longer connect to the server with remote desktop. I could ping the server and browse the admin shares across the network. I logged in and verified the Remote Desktop Services service was started and enabled.

Looking at the event log, I could see that every time I tried to remote in, the System log was adding event 36870 – “A fatal error occurred 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.”

More research seemed to indicate that this was a problem with the Remote Desktop certificate on the system.  I opened the certificate manager for the local system, backed up the remote desktop certificate and then deleted it the certificate store.  Now, when I restarted the Remote Desktop Services service, I started getting a different event 1058 – “The RD Session Host Server has failed to replace the expired self-signed certificate used for RD Session Host Server authentication on SSL connections.  Access is denied.”

More research pointed me to checking the permissions in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.  When I tried to set a permission on the folder, it propagated to all the files within except for one which said that access was denied.  I was unable to modify the permissions on the file itself even though I was logged in as the local administrator.

Taking a chance, I stopped the Remote Desktop Services service and was able to delete the file with the permission issues.  I restarted the Remote Desktop Services service and observed that a new Remote Desktop certificate had been created as well as a new file in the MachineKeys folder.  I was now able to connect to the server using remote desktop.


 

There is a feature in Google Chrome that can make browsing secure internal web sites a little less painful and possibly more efficient. When you access a site with a self-signed, untrusted, or expired certificate, Chrome will present you with a warning in your browser like below:

This is intended to protect you from going to a site that may have been compromised by some type of man-in-the-middle attack. However when you browse to an internal management interface like a UPS or other appliance, you're likely going to receive this warning because IT administrators typically don’t install public certificates on these peripheral devices. Therefore, we know that this certificate is untrusted and would prefer not to see the warning every time because it will always be untrusted.
 
Enter chrome://flags. This includes the under-the-hood settings for Chrome – similar to about:config in Firefox.
 
The Flags area allows you to configure a setting to bypass the SSL warning every time you visit for a period of time. Setting this for 1 week is typical but you can extend it to up to three months.


 
 


 

On October 6, 2014, ISACA launched the Cybersecurity Fundamentals Certificate.  The Cybersecurity Fundamentals Certificate is aligned with the Skills Framework for the Information Age (SFIA) and the National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework. [more] It tests for foundational cybersecurity knowledge in five areas:

  1. Cybersecurity concepts
  2. Cybersecurity architecture principles
  3. Cybersecurity of networks, systems, applications and data
  4. The security implications of emerging technology
  5. Incident response

To see ISACA's press release visit http://www.isaca.org/About-ISACA/Press-room/News-Releases/2014/Pages/ISACA-Launches-New-Cybersecurity-Certificate.aspx