Hvad kan vi hjælpe med?
< Alle Emner

Securing Connections with Trusted TLS Certificates

**Disclaimer**: Please note that the following actions involve making changes to your system. We provide this information for guidance purposes only. We are not responsible for any damage or loss that may occur as a result of implementing these steps. It is recommended to proceed with caution and have a valid backup of your server before making any modifications.

Vulnerability Details 

The remote host makes use of a self-signed certificate. The traffic is still encrypted but it is up to the user to validate if the certificate can be trusted or not. If an attacker changes the certificate to one with a known decryption key, the users data can be eavesdropped or changed before reaching the recipient.

Severity Rating


How to Verify if a Device is Vulnerable

Use Nessus plugin ID 57582 to scan the device and check for self-signed certificates. The output shows who created the certificate.

Or use the powershellscript we provided with the IP address or hostname and the port number. This will make a connection to the service like HTTPS or RDP and get the values from the certificate.

What You Should Be Aware of if You Apply a Fix

The fix relies on Active Directory Certificate Services (AD CS). If it has not been set up previously then make sure it is set up correctly and is protected.

After the fix has been applied add the internal root CA to “Trust a Custom CA” in Nessus to make sure Nessus treats the CA as trusted. https://docs.tenable.com/nessus/Content/TrustACustomCA.htm

How to Fix


Create an RDP Certificate Template in a Certificate Authority (CA)


Deploy RDP SSL/TLS Certificates

This can be done by following this guide: https://woshub.com/securing-rdp-connections-trusted-ssl-tls-certificates/


Create a new certificate in Active Directory Certificate Services and use that in the web servers settings.


Follow the guide in the article.


Powershell script to show CA from a certificate

# Get User Input

$ComputerName = Read-Host -Prompt ‘Enter the remote server name or IP’

$Port = Read-Host -Prompt ‘Enter the port number’

# Establish TCP Connection

$TcpClient = New-Object -TypeName System.Net.Sockets.TcpClient

$TcpClient.Connect($ComputerName, $Port)

# Create callback method to handle certificate validation – this will bypass certificate validation.

$CertificateValidationCallback = {







    return $true  # Bypass certificate validation and accept all certificates.


# Start SSL Negotiation with certificate validation bypassed

$SslStream = New-Object -TypeName System.Net.Security.SslStream -ArgumentList $TcpClient.GetStream(), $false, $CertificateValidationCallback


# Get Certificate Details

$Cert = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList $SslStream.RemoteCertificate

Write-Host “Certificate Details:”

Write-Host “Subject (CN): $($Cert.Subject)”

Write-Host “Issuer (CA): $($Cert.Issuer)”

Write-Host “Expiry Date: $($Cert.NotAfter)”


  • Remove the certificate and use a selfsigned again.

How to Verify the Fix

  • Rescan the device with Nessus plugin ID 57582 and check for any self-signed certificates.
  • Test if the user is getting prompted because the certificate not can be validated.
  • Use the powershellescript to check if the certificate CA has been changed.

Preventative Measures

  • In new installations make sure to run the GPO to add the trusted certificate on RDP.
  • When installing a new application make sure to apply a trusted certificate.
  • Scan the devices regulary to identify new software using self-signed certificates.

Links (for additional resources and references)


https://www.tenable.com/plugins/nessus/57582  https://woshub.com/securing-rdp-connections-trusted-ssl-tls-certificates/