CoNetrix

Blog: Certificate

When a FortiGate is managed via FortiManager, administering the FortiGate outside of FortiManager can cause the configuration to become out of sync. While updating an SSL certificate used for VPN access on a FortiGate for a customer, I found that I was unable to create a certificate signing request from FortiManager. After doing some research, I found a Fortinet cookbook article that explains that the certificate must be requested and the certificate request completed from the FortiGate itself, even if the device is managed via FortiManager. To complete this process, do the following:
  • Login to the FortiGate in read-write mode
    • Create a certificate signing request on the FortiGate
    • Download the certificate signing request from the FortiGate
    • Submit the certificate signing request to the certificate authority
    • Download the issued certificate from the certificate authority
    • Import the certificate on the FortiGate to complete the certificate signing request
  • Login to FortiManager
    • Select the FortiGate in Device Manager and go to the "System: Dashboard" page
    • In the "Configuration and Installation Status" pane, click the "Revision History" (four horizontal lines) icon on the "Total Revisions" line
    • Click the "Retrieve Config" button
    • The current configuration, including the new certificate, will be retrieved.
    • The certificate should now be able to be used in configurations managed in FortiManager
If you are deleting the old certificate, you will need to write the config to the FortiGate from FortiManager so that it is no longer using the old certificate. After the old certificate is no longer in use, you can login to the FortiGate in read-write mode and delete the old certificate. After the old certificate is deleted, you will need to repeat the "Retrieve Config" operation.
 
The Fortinet cookbook article explaining this process can be found at https://kb.fortinet.com/kb/documentLink.do?externalID=FD35142
Fortigate, 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.

Networking, RDP, Remote Desktop, Certificate, Windows Server 2012 R2, SSL,
 

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.


 
 

Networking, Certificate, Chrome,
 

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

Security and Compliance, Cybersecurity, CSX, Certificate, ISACA,