Error decrypting credential: No secret key

Hi everybody , I open again this topic, since I am facing unrecoverable errors when I try to configure a scan for a single vulnerability, as described by ‘cfi’ right above.
So, my goal is : configure a scan for a single vulnerability, that would be fast and efficient, so as to be run over a very large number of targets.

Targetted vulnerability : Deprecated TLS v1.0 and v1.1 Protocol (NVT OID: 1.3.6.1.4.1.25623.1.0.117274)

GVM Environment
Host OS : Debian server 10.12
Kernel : uname -a : Linux scanner-ssi-intra 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 (2022-03-17) x86_64 GNU/Linux
Installation : VMware virtual machine, from Debian ISO

GVM Source Edition Version 21.4.3
gsa: gsad --version : Greenbone Security Assistant 21.4.3
gvmd: gvmd --version : Greenbone Vulnerability Manager 21.4.3 / Manager DB revision 242
openvas scanner: openvas --version : OpenVAS 21.4.4 gvm-libs 21.4.3

  1. I create a customized scan configuration, ‘Empty, static and fast’ (called ‘TestTLSScanConfig’)
  2. I add the two mandatory VTs, from the ‘Port scanners’ item :
    a) Nmap VT => OID: 1.3.6.1.4.1.25623.1.0.14259
    b) Ping host VT => OID: 1.3.6.1.4.1.25623.1.0.100315
    ( I don’t add ‘Host details VT’, I don’t need hostnames for now )
  3. I also add now the VT of interest, from the ‘Vulnerable Cipher’ item :
    Deprecated TLS v1.0 and v1.1 Protocol => OID: 1.3.6.1.4.1.25623.1.0.117274
    I save my ‘TestTLSScanConfig’ (without any error)
  4. I create a new target
    . just one (1) IP address ( it’s the GVM scanner itself as it were )
    . Port list : All IANA assigned TCP
    . Alive Test : Consider Alive
    . no credentials
    I save my ‘TestTLSScanTarget’ (without any error)
  5. I create a new task ‘TestTLSScanTask’
    . Scan targets : ‘TestTLSScanTarget’
    . Scanner : OpenVAS Default
    . Scan Config : ‘TestTLSScanConfig’
    . everything else to ‘default’
    I save my ‘TestTLSScanTask’ (without error)
  6. I manually run the new (unscheduled) scan task ‘TestTLSScanConfig’
    . it’s Requested, then Queued
    . and it’s IMMEDIATELY interrupted at 0 %
    . GSA interface messages : Scan process failure, Task interrupted unexpectedly
    ( thank you : doesn’t help … )
    . in ospd-openvas.log :
    OSPD[1515] 2023-01-24 14:28:57,123: INFO: (ospd.ospd) b197171a-d99b-4aa1-8bd9-0f362ca91437: Scan interrupted.
    OSPD[1515] 2023-01-24 14:28:58,158: INFO: (ospd.ospd) b197171a-d99b-4aa1-8bd9-0f362ca91437: Scan process is dead and its progress is 0
    . in gvmd.log :
    event task:MESSAGE:2023-01-24 14h28.45 CET:15514: Status of task TestTLSScanTask (6ce395ff-5bd3-439d-aed8-b3c41e220dd5) has changed to Queued
    event task:MESSAGE:2023-01-24 14h28.58 CET:15514: Status of task TestTLSScanTask (6ce395ff-5bd3-439d-aed8-b3c41e220dd5) has changed to Interrupted
    libgvm util:WARNING:2023-01-24 14h45.00 CET:18038: error decrypting credential: No secret key
    libgvm util: INFO:2023-01-24 14h45.00 CET:18038: encrypted to keyid 89258F9B1675842D, algo=1: No secret key
    libgvm util:WARNING:2023-01-24 14h45.00 CET:18038: error decrypting credential: No secret key
    libgvm util: INFO:2023-01-24 14h45.00 CET:18038: encrypted to keyid 89258F9B1675842D, algo=1: No secret key
    libgvm util:WARNING:2023-01-24 14h45.00 CET:18038: error decrypting credential: No secret key
    ( etc … )

Q 1 : what the h… is going on here … ??
Q 2 : to configure and run a focused (targetted) scan, DO I NEED ‘credentials’ … ??? !! (i.e, authenticated connection ?? )

At INRAe France (where I’m working), we have : 3 class B networks (yes: 3 class B …), and ~ 10 to 15 class C networks. So the goal is to run a fast, focused scan, on VERY large numbers of target systems, over which I do not and can’t have administrative authority (it has to be ‘external scans’, i.e non authenticated)

Many thanks for any contribution and hints that could be provided here,
best regards, Jean LE MOIGNE (jean.le-moigne@inrae.fr)

Hi,

I’ve moved your question to a new topic because it seems very unrelated to the previous one.

Your issue is caused by a defect setup of encrypting the credentials in the database. You either need to fix this setup (it seems the private GPG key for the encryption couldn’t be found in the keychain) or you can disable the encryption completely (check gvmd --disable-encrypted-credentials).

2 Likes