How to Replace an SSL Self-Signed Certificate (Nessus 57582, RDP 3389)

An SSL self-signed certificate finding means a TLS service (a website, an admin console, or RDP on port 3389) presents a certificate it signed itself, so clients cannot verify the server’s identity. Fix it by issuing a certificate from a trusted certificate authority (CA) whose SAN matches the host’s FQDN, binding it to the service, restarting, and rescanning.

What the scanner is actually detecting

The check is remote. The scanner completes a TLS handshake on each port and flags the service when the presented chain ends in a self-signed certificate it does not recognize. It never reads your certificate store, so deleting certificates on the host rarely closes the finding.

The Qualys and Rapid7 identifiers come from the vendors’ own knowledge bases, which require a customer login to view, so confirm the exact name in your console.

Nessus 57582 remediation is the same as for the Qualys and Rapid7 checks: replace the certificate the port presents. Nessus often also reports plugin 51192, “SSL Certificate Cannot Be Trusted”, which additionally covers missing intermediates and expired certificates. A properly issued, fully chained certificate closes both.

Typical sources: the default RDP listener certificate, “Create Self-Signed Certificate” in IIS Manager, the Debian and Ubuntu “snakeoil” certificate, the localhost.crt generated by RHEL-family mod_ssl, and factory certificates on appliances.

Real-world risk

A self-signed certificate still encrypts traffic. What it removes is server authentication: the client cannot tell the real server from an attacker on the network path presenting a different certificate. Exploiting that needs a man-in-the-middle position (ARP or DNS spoofing, a compromised router, a rogue access point), so it is not remotely exploitable on its own.

The bigger practical cost is habituation. When every RDP session and admin page shows a warning, people learn to click through, and a real interception looks like a normal day. If a user accepts the warning on an intercepted RDP connection, the attacker may be able to capture or relay logon credentials. Treat it as hygiene with real consequences, not an emergency.

How to confirm it on the host

Any TLS web service, from a Linux or macOS workstation

echo | openssl s_client -connect web01.corp.example.com:443 -servername web01.corp.example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Identical subject and issuer on the leaf confirm the finding. That test is sufficient but not necessary: 57582 also fires when the chain the server sends ends in a self-signed root the scanner does not recognize, while the leaf itself looks fine. To see the whole chain the server sends:

echo | openssl s_client -connect web01.corp.example.com:443 -servername web01.corp.example.com -showcerts 2>/dev/null | grep -E '^ *[0-9]+ s:|^ +i:'

Each certificate appears as a numbered s: (subject) line followed by its i: (issuer) line. If the last one has the same subject and issuer, the server is sending a self-signed root, and the scanner reports 57582 unless it trusts that root (see the false positive section below). In the unfiltered output, Verify return code 18 or 19 points to the same two cases when your workstation does not trust the root.

None of this works against port 3389, because RDP negotiates before TLS starts, so check RDP on the host.

Windows: IIS and other HTTP.sys services

netsh http show sslcert
Get-ChildItem Cert:LocalMachineMy | Where-Object { $_.Subject -eq $_.Issuer } | Select-Object Thumbprint, Subject, NotAfter

If a bound certificate hash matches a thumbprint in the second list, that binding is self-signed.

Windows: the self-signed certificate on port 3389

In Windows PowerShell 5.1:

Get-WmiObject -Class Win32_TSGeneralSetting -Namespace rootcimv2terminalservices -Filter "TerminalName='RDP-tcp'" | Select-Object TerminalName, SSLCertificateSHA1Hash, SSLCertificateSHA1HashType
Get-ChildItem 'Cert:LocalMachineRemote Desktop' | Select-Object Thumbprint, Subject, Issuer, NotAfter

Microsoft documents four values for SSLCertificateSHA1HashType: 0 (Not valid), 1 (Default self-signed), 2 (Default group policy enforced) and 3 (Custom). A value of 1 confirms the finding. A value of 2 or 3 does not rule it out, because the bound certificate may itself be self-signed. In that case, look up the certificate behind SSLCertificateSHA1Hash:

$h = (Get-WmiObject -Class Win32_TSGeneralSetting -Namespace rootcimv2terminalservices -Filter "TerminalName='RDP-tcp'").SSLCertificateSHA1Hash
Get-ChildItem "Cert:LocalMachineMy$h" | Select-Object Subject, Issuer, NotAfter

The issuer must differ from the subject, and the certificate must chain to a trusted CA (in certlm.msc, the Certification Path tab should read This certificate is OK).

Linux: Apache and nginx

grep -RnE 'SSLCertificateFile|ssl_certificate[[:space:]]' /etc/apache2 /etc/httpd /etc/nginx 2>/dev/null
openssl x509 -in /etc/ssl/certs/ssl-cert-snakeoil.pem -noout -subject -issuer

Point the second command at whichever file the first one reports.

How to fix it

Start with the right certificate

• Put the FQDN (and any other name clients use) in the Subject Alternative Name; browsers match on SAN, not CN.
• Include the Server Authentication extended key usage.
• Issue it from a CA that clients and your scanner trust: AD CS or another enterprise CA internally, a public CA for internet-facing hosts.
• Serve the full chain. A missing intermediate just trades 57582 for 51192.

A TLS certificate inventory helps you find every instance and keeps renewals from recreating the problem.

Replace a self-signed certificate in IIS

$pw = Read-Host -AsSecureString -Prompt "PFX password"
Import-PfxCertificate -FilePath C:certsweb01.pfx -CertStoreLocation Cert:LocalMachineMy -Password $pw

In IIS Manager, select the site, click Bindings, select the https binding, click Edit, choose the new certificate under SSL certificate and click OK. Repeat for every https binding, then check netsh http show sslcert for leftover old hashes.

Apache httpd

Since Apache 2.4.8, SSLCertificateFile can hold the leaf followed by its intermediates, which makes SSLCertificateChainFile obsolete. On httpd older than 2.4.8, keep SSLCertificateFile for the leaf only and put the intermediates in SSLCertificateChainFile; otherwise the intermediates in a combined file are ignored and 57582 turns into 51192. Check the version with httpd -v or apache2 -v.

<VirtualHost *:443>
    ServerName web01.corp.example.com
    SSLEngine on
    SSLCertificateFile    /etc/ssl/certs/web01.fullchain.pem
    SSLCertificateKeyFile /etc/ssl/private/web01.key
</VirtualHost>

apachectl configtest && systemctl reload apache2    # the unit is httpd on RHEL-family systems

On Debian and Ubuntu, also fix or disable the stock default-ssl site.

nginx

cat web01.crt intermediate.crt > web01.chained.crt

server {
    listen 443 ssl;
    server_name web01.corp.example.com;
    ssl_certificate     /etc/nginx/tls/web01.chained.crt;
    ssl_certificate_key /etc/nginx/tls/web01.key;
}

nginx -t && systemctl reload nginx

The server certificate must come before the intermediates in the combined file.

Replace the RDP self-signed certificate with Group Policy

1. In certtmpl.msc, duplicate the Computer template and name it without spaces (for example RDPServerAuth). Keep Server Authentication, build the subject from Active Directory with the DNS name, and grant Domain Computers (or a narrower group) Read and Enroll.
2. In the Certification Authority console, right-click Certificate Templates, choose New > Certificate Template to Issue and select the new template.
3. In a GPO linked to the target computers, open Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Server authentication certificate template, set it to Enabled and enter the template name.
4. Run gpupdate /force on a pilot host, or wait for the normal refresh.

Per Microsoft, a host without a matching certificate requests one and keeps its current certificate until enrollment completes, and a certificate selected manually on a host takes precedence over the policy. For other listener settings worth changing at the same time, see the RDP hardening guide.

RDP on a single host: SSLCertificateSHA1Hash in Win32_TSGeneralSetting

Import the certificate into the computer’s Personal store first, or the command fails with Invalid Parameter. Then, in Windows PowerShell 5.1:

$thumb = (Get-ChildItem Cert:LocalMachineMy | Where-Object { $_.Subject -ne $_.Issuer -and $_.HasPrivateKey -and $_.DnsNameList.Unicode -contains 'rdsh01.corp.example.com' -and $_.NotAfter -gt (Get-Date) } | Sort-Object NotAfter -Descending | Select-Object -First 1).Thumbprint
if (-not $thumb) { throw 'No CA-issued certificate found' }
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace rootcimv2terminalservices -Filter "TerminalName='RDP-tcp'" | Set-WmiInstance -Arguments @{SSLCertificateSHA1Hash=$thumb}

The filter skips self-signed certificates (such as one made with IIS Manager or New-SelfSignedCertificate, which land in the same store) and matches on the SAN rather than an exact subject, so a CA-issued certificate whose subject carries extra fields such as O= or C= still qualifies. If nothing matches, the script stops instead of writing an empty hash. You can also paste the thumbprint explicitly, as Microsoft’s own example does.

On older systems, Microsoft documents the equivalent WMIC command:

wmic /namespace:\rootcimv2TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"

WMIC is deprecated and may be absent on Windows 11 and Windows Server 2025; use the PowerShell command above there.

The registry method writes a REG_BINARY value SSLCertificateSHA1Hash under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp and also requires granting NETWORK SERVICE Read on the private key (certlm.msc, All Tasks, Manage Private Keys).

If the listener still presents the old certificate, restart the Remote Desktop Services service (TermService) from a console or out-of-band session, since it drops RDP connections. Deleting the self-signed certificate from the Remote Desktop store is optional clean-up and fixes nothing by itself.

For appliances (out-of-band controllers, hypervisors, printers), generate a CSR on the device and upload the signed certificate following the vendor’s procedure.

How to verify the fix and rescan

openssl s_client -connect web01.corp.example.com:443 -servername web01.corp.example.com -CAfile corp-root.pem -verify_return_error </dev/null

Look for Verify return code: 0 (ok). For RDP, rerun the Win32_TSGeneralSetting query: the type should read 2 or 3, the hash should equal the new thumbprint, and that certificate’s issuer should differ from its subject. This check and the rescan are the proof. A missing certificate prompt on a domain-joined client proves nothing on its own: when the client connects by FQDN and Kerberos authenticates the server during Network Level Authentication, mstsc shows no certificate warning even while the default self-signed certificate is still bound. For a client-side check, connect by IP address, or from a non-domain machine that trusts your internal root, and open the certificate shown in the prompt to confirm its issuer (a name mismatch warning is expected when you connect by IP).

Then rescan the same ports with the same policy and confirm that 57582 (or QID 38169, or the Rapid7 check) is gone and that 51192 did not appear in its place.

What can break and how to roll back

• RDP lockout. A certificate the service cannot use (wrong store, no private key access) can block connections, so keep console access. To roll back, delete the SSLCertificateSHA1Hash value under the RDP-Tcp key (or set the GPO to Not Configured) and restart TermService.
• Web server fails to start. A wrong path or mismatched key stops Apache or nginx. Test the config first and keep the previous one. Key and certificate match when these hashes are identical:

  openssl x509 -in web01.crt -noout -pubkey | openssl sha256
  openssl pkey -in web01.key -pubout | openssl sha256

• Pinned thumbprints. Scripts or agents that trust a specific certificate rather than a CA will fail after the swap.
• Non-domain clients. Machines that do not trust your internal root will see an unknown-issuer warning; distribute the root to them.
• IIS. Rollback means reselecting the previous certificate in the binding, so keep it until the rescan is clean.

Common false positive reasons

• Internal root unknown to the scanner. If a server sends your internal root in its chain and the scanner does not trust it, the chain ends in an unrecognized self-signed certificate and 57582 fires on a properly issued leaf. Add the root to the scanner’s trusted CAs instead of suppressing the finding.
• Scanning by IP. Without SNI, a server or load balancer returns its default certificate, often self-signed even when every named site is correct.
• Another port. The finding is per port; fixing 443 does not cover 3389, 8443 or WinRM on 5986.
• Pending RDP enrollment. A rescan run before enrollment completes still sees the self-signed certificate.

FAQ

Is a self-signed certificate a vulnerability if traffic is still encrypted?

Yes, a moderate one. Encryption without server authentication only stops passive eavesdropping; an attacker on the path can present their own certificate.

Why does the RDP self-signed certificate come back after I delete it?

The listener is still on its default, so Windows regenerates it. Bind a CA-issued certificate through the GPO or SSLCertificateSHA1Hash.

Can I just trust the self-signed certificate on clients?

Each self-signed certificate is its own root, so you would distribute one root per server, and the scanner still reports it. An internal CA needs a single trusted root.

Do internal servers need a public CA certificate?

No. A certificate from your enterprise CA is enough, provided clients and the scanner trust that CA’s root.

Tracking this finding across many hosts

Self-signed certificates reappear with every new server build, appliance and RDP-enabled workstation, so this finding is easier to manage as a fleet-wide list than one ticket at a time. If you use SITEY, a self-hosted vulnerability management platform, you can import these findings (Nessus results by uploading the .nessus export), have its AI draft host-specific remediation scripts that run only after human approval through its Windows and Linux agents, and re-test to verify closure; per-finding retest is available for Nessus results.

Sources

• Tenable: Nessus plugin 57582, SSL Self-Signed Certificate
• Microsoft Learn: Remote Desktop listener certificate configurations
• Microsoft Learn: Policy CSP ADMX_TerminalServer (Server authentication certificate template)
• Microsoft Learn: Win32_TSGeneralSetting class
• Apache HTTP Server: mod_ssl directives