Back to scan results
What this check probes
The scanner first tests whether TCP port 3389 is reachable. A closed or externally filtered RDP port passes this check because there is no public RDP certificate to assess. When the port is open, the scanner sends an X.224 RDP Connection Request advertising TLS and CredSSP security protocols, then reads the server's RDP negotiation response.
- TLS selection: explicitly selecting legacy Standard RDP Security instead of TLS fails. A standards-defined response saying TLS is unavailable or no TLS certificate is configured also fails.
- Cryptographic self-signature: the leaf certificate is treated as self-signed only when its subject and issuer match and its signature verifies with its own public key. Matching names alone are not considered proof.
- Certificate chain: the leaf must build to a root trusted by the scanner's Windows trust store. Online revocation checking is deliberately excluded from this quick check so a temporarily unreachable CA endpoint does not create a false red result.
- Validity dates: expired and not-yet-valid certificates fail. Certificates expiring in fewer than 30 days produce a warning.
- Target name: Windows TLS hostname validation must match the domain or IP address the user asked PCIScan to test.
After collecting the certificate and completing the TLS handshake, the scanner stops. It does not perform CredSSP authentication, submit credentials, create a desktop session, or attempt to exploit the service.
If port 3389 accepts TCP but does not return a valid RDP response, or the RDP/TLS handshake ends before a certificate is available, the result is a warning rather than an invented vulnerability. Every red result is independently reproduced before PCIScan reports failure.
Why this matters for PCI DSS
An exposed RDP service is an externally reachable management surface. Encryption alone is not enough: the client also needs a trustworthy way to identify the server. A self-signed, expired, untrusted, or name-mismatched certificate cannot provide that identity assurance and leaves users vulnerable to certificate warnings and interception.
Microsoft's Remote Desktop certificate guidance explains that RDS certificates authenticate servers and help prevent man-in-the-middle attacks. It recommends a trusted certificate with Server Authentication usage whose subject or alternative name matches the server name used by clients.
This quick check assesses the externally presented RDP certificate, not every RDS role, gateway, patch, cipher, authentication, or account-control requirement that a complete vulnerability assessment may examine.
How to fix it
Do not expose RDP directly unless there is a documented need. Prefer a VPN, Remote Desktop Gateway, zero-trust access layer, or a tightly restricted firewall allowlist. Closing public port 3389 removes this particular external certificate exposure and reduces password-spraying and service-vulnerability risk.
Install a certificate from a trusted CA. Assign it to the RDP listener or relevant RDS role. The certificate should include Server Authentication usage and a subject alternative name matching the DNS name clients actually enter. Avoid training administrators to click through certificate warnings.
Use a stable public DNS name. If users connect by IP address, the certificate must contain that IP as an IP-address subject alternative name; an ordinary DNS name will not match an IP target. In most deployments, connecting through a managed DNS hostname is simpler.
Renew and deploy before expiry. Automate renewal where possible, confirm the renewed certificate is bound to the correct listener, and retest from outside the network. Replacing a certificate in a store does not necessarily update the active RDP binding.
Retest the exact public name. A certificate can be trusted for one hostname and invalid for an alias, raw IP address, or load-balanced endpoint. Scan the same address that administrators and clients use.