Hello Everyone,
I have a question how everyone is is remediating self-signed tls/ssl certificate port 3389 and X.509 cert vulnerability ?
4 Likes
We always just accept the low risk on this one. It’s a self-signed cert, it’s still secure just not trusted, when it expires the OS will generate another one. The amount of effort involved in replacing these with signed certs from a trusted CA - internal or external is not worth it IMO. Have your manager sign off on the risk which is basically nil and mark it as an accepted deviation.
AFAIK RDP uses kerberos and not this cert for encrypting a session, Domain to Domain. This cert only comes into play when you do a RDP session from hosts on different domain which then uses TLS/SSL and this cert.
2 Likes
You can import the root ca it into InsightVM.
https://docs.rapid7.com/insightvm/managing-certificates-for-scanning/
It’s not a bad idea to setup an internal CA using something like Microsoft server CA so you can access on who can sign certificates. Then you can import the root ca, sign all your internally hosted certificates, and this will eliminate the vulnerability.
https://learn.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/install-the-certification-authority
3 Likes
For all domain members, we have a GPO that uses the machine certificate (from enrollment in the internal AD CS service) and configure the cert to be used for RDP sessions.
After importing the internal root/intermediate cert in Rapid7, this solved the vulnerability. It is a more tedious process for non-domain members as it has to be done manually but essentially works the same. There is a lot of litterature online regarding how to configure your CA template and how to create your GPO.
As far as risk, there is no difference between this and TLS for a website. I highly doubt that anyone is verifying that the fingerprint of the certificate matches an expected result if it is not signed by a trusted (internal or external) CA.
3 Likes
Thank you everyone for great suggestion.