Recently my servers with LetsEncrypt SSL encryption are being flagged for having 256-bit keys, less than the recommendation of 2048-bit keys.
I don’t know why this started being flagged, and ironically running the scanner against GOOGLE.COM shows the SAME vulnerability. Could Google.com be oblivious to this security flaw, or is the vulnerability rule making a mistake?
I am using version 2.1 of the community edition.
Thanks a lot for making us aware of this…
There seems to be indeed a problem on scanner side which extracts a wrong algorithm-name from the certificate. In this case you probably see something like sha256WithRSAEncryption for algorithm in the output of the VT “SSL/TLS: Collect and Report Certificate Details” (OID: 1.3.6.1.4.1.25623.1.0.103692) while key-size (bits) is something like 384?
The VT “SSL/TLS: Server Certificate / Certificate in Chain with RSA keys less than 2048 bits” (OID: 1.3.6.1.4.1.25623.1.0.150710) in question fully relies on the correct algorithm used for a certificate returned by the scanner. An internal issue has been raised to research why the wrong algorithm is returned from scanner side.
Here is the detection method for the size<2048-bit issue:
Details: SSL/TLS: Server Certificate / Certificate in Chain with RSA keys less …OID: 1.3.6.1.4.1.25623.1.0.150710
Version used: 2021-11-24T06:31:19Z
This scan was done against Google.com, but the results are similar against our dokku-letsencrypt servers.
Thank you for validating this problem!
So it turned out that the scanner itself is working as expected but is returning the “Signature Algorithm” which was used to sign the certificate while the VT in question is expecting the Algorithm of the Public Key instead. If all certificates in the chain have been signed by a RSA based algorithm this isn’t a problem but as soon as there are different algorithms in use a false positive or false negative might occur.
The scanner will be extended now to return both, the Signature Algorithm and the Public Key Algorithm. Stay tuned for some more info in the next few weeks.
Hello,
I extended the nasl function to get also the public key algorithm
Best regards.
This fix is great - its the only thing flagging ATM so was rather annoying!
To get the fix - do I just update the community feed?
Is it in yet?
Cheers
I have only the free version of Greenbone – but I think there is an error in one of the checks…
We have some ECDSA SSL certs that are being reported as “too short RSA certs” triggering both the 1024 and 2048 length checks
I cannot detect any issue with these ECDSA certs (they are generally less short than RSA keys)
It’s as if the engine is not checking if the certs are RSA before checking the length?
Summary
The remote SSL/TLS server certificate and/or any of the certificates in the certificate chain is using a RSA key with less than 1024 bits.
Detection Result
The remote SSL/TLS server is using the following certificate(s) with a RSA key with less than 1024 bits (key-size:serial:issuer):
256:049384DB30346A3287BB39C578B020AF641D:CN=R3,O=Let’s Encrypt,C=US (Server certificate)
Hi @merlian and welcome to the forum 
please take a look here 256-bit SSL keys flagged Thanks!
Hi DeeAnn - that sounds like the issue to me! TY!
Glad to hear it and you’re welcome! I moved these posts into the linked topic to put it all together (might help anyone searching later with the same issue).
The VT in question got updated in the meantime to make use of the following new functionality:
This extended functionality is already included in the recent Greenbone OS 21.04.11 and will be shipped with the next openvas-scanner release (probably 21.4.4 but i have no insights into the release management of GVM) for the GSE.
As the VT in question is now using this extended functionality it won’t report in general as long as the scanner host hasn’t been updated to Greenbone OS 21.04.11 / openvas-scanner 21.4.4.
The problem has been resolved in the latest pull from the community feed. THANK YOU CFI!!!