For certificates generated by my own CA (the CA is not signed by any trusted well-known CA) or generated by some vendor’s CA (TrueNAS) I get the following:
The service is using an SSL/TLS certificate from a known
untrusted and/or dangerous certificate authority (CA).
I understand why I get this result.
I would like to know whether I may somehow trust a CA for OpenVAS (even if the CA is not signed by an officially trusted CA) so that the result is not generated any more.
I know that I may use an override. This is not what I am asking.
Just to check what you are asking, you meant that when you scan your own assets which are using a self-signed certificate, the scan results include an item:
The service is using an SSL/TLS certificate from a known
untrusted and/or dangerous certificate authority (CA).
You want to know if you can explicitly add your own certificates to Greenbone so that they are not considered untrusted instead of adding an override for that VT / host combination?
As far as I know, that is not possible. There is a credential type named “Client Certificate”, but I’m not sure what that credential type is used for.
Actually I wouldn’t want to add each certificate to make it trusted. It would be more elegant to just add the certificate of my own CA, which would then make all certificates trusted that have been signed by the CA.
But if that is not possible, adding each certificate to make it trusted would be acceptable.
I guess this is used for authenticated scans, where the login would be using a certificate, such as for some web services. However this is very probably not what I am looking for (and I saw it before I wrote my post).
Please note that the named VT doesn’t work with anything like “trusted CA” and thus adding one wouldn’t prevent it from reporting.
Instead it works on a fixed list of issuer names of a certificate defined in the if( check_for == "untrusted_ca" ) { part of ssl_func.inc and reports accordingly.
The reason is if one of such issue names are in use there is usually something really “fishy” going on on the target / connection which requires a closer look.
this needs clarification. the descriptions says: “untrusted and/or dangerous CA” the part “untrusted” doesn’t necessarily sound like a blacklisted CA, just one that is not signed by a known trusted CA.
the concrete CA looks like it is just a unregistered CA generated on the fly by the TrueNAS system.
Ah, the focus should be more on the “dangerous” part. The “untrusted” is only a side-effect of the check.
Where may I look into the inner working of this NVT to check if this CA actually was really blacklisted?
An answer to this has been given previously. The named ssl_func.inc can be found on the file system (location varies depending on each installation) of the scanner host in question.
OK the test is kind of prone for false positives because one pattern it loks for is “localhost”. That can be something bad, but does not have to be. In this case the TrueNAS application has a local CA that is able to create certificates. the local CA is also dynamically created. This is why it has CN=localhost. They probably shoul dbetter be using the actual hostname, but in any way this is not a dangerous or malicious CA. Of course one needs to know what to do and not to do with these certificates.
Nevertheless, it would make sense to have a user definable whitelist of certificates that have been checked to be non-malicious.
This is my take on this, your opinion might be different. Thats OK.
