Description of the problem

https://syslog-ng.github.io/admin-guide/100_TLS-encrypted_message_transfer/004_TLS_options#trusted-keys says it uses SHA-1, and if I understand the code correctly, that's the only hash algorithm it supports. From https://en.wikipedia.org/wiki/SHA-1:

Since 2005, SHA-1 has not been considered secure against well-funded opponents;[11] as of 2010 many organizations have recommended its replacement.[12][10][13] NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013, and declared that it should be phased out by 2030.[14] As of 2020, chosen-prefix attacks against SHA-1 are practical.[6][8] As such, it is recommended to remove SHA-1 from products as soon as possible and instead use SHA-2 or SHA-3. Replacing SHA-1 is urgent where it is used for digital signatures.

Proposed solution

Add at least one other hash algorithm that's still considered secure. SHA-256 seems like a good candidate, but there are other good options.

Alternatives

I guess it could work to support including the entire certificate in trusted-keys, instead of just the hash.

Additional context

I'd guess that a practical attack would still be infeasible, assuming the attacker's goal is to create a second preimage certificate that they control the corresponding private key of. I think they'd have to find a second preimage that is both a valid certificate and that they can get to include the public key corresponding to their private key. I'm not an expert at hash cryptanalysis, but that seems significantly more difficult to me than just a plain second preimage attack. I'm also not sure if sha-1's second preimage resistance has been successfully attacked at all yet. So this doesn't seem like a vulnerability to me, just a good idea to use hash algorithms that are generally considered secure.