This bug is tricky to be solved and most probably won't. If I remember correctly, versions of TLS prior to 1.2 could use a running hash (e.g., SHA1) throughout the handshake, and will use the output of this hash for any signatures that need to be generated. Starting with TLS 1.2 the hash is negotiated, but a client will not know the hash to be used for client-cert signatures up until the point the server asks for one. At this point this gnutls client has two hashes running sha1 + sha256. Thus if the server asks for anything else it wouldn't work.

As such the preferred action is to mark the gnutls client as capable of handling sha1+sha256 hashes only, and treat it as a known bug.
(Note that it doesn't make sense for the client to restrict its supported signature hashes to sha1+sha256 only, because the client can handle more signature hashes when the signature come from the server side).

Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

(In reply to Nikos Mavrogiannopoulos from comment #1)
> This bug is tricky to be solved and most probably won't. If I remember
> correctly, versions of TLS prior to 1.2 could use a running hash (e.g.,
> SHA1) throughout the handshake, and will use the output of this hash for any
> signatures that need to be generated. Starting with TLS 1.2 the hash is
> negotiated, but a client will not know the hash to be used for client-cert
> signatures up until the point the server asks for one. At this point this
> gnutls client has two hashes running sha1 + sha256. Thus if the server asks
> for anything else it wouldn't work.
> 
> As such the preferred action is to mark the gnutls client as capable of
> handling sha1+sha256 hashes only, and treat it as a known bug.
> (Note that it doesn't make sense for the client to restrict its supported
> signature hashes to sha1+sha256 only, because the client can handle more
> signature hashes when the signature come from the server side).

Then it means that it's the exact same bug as the one we have in NSS, bug 1238369, with the same interoperability issues: Windows clients with certificates signed with anything but SHA-256 or SHA-1 will not work.

Given the scope of this change, rsyslog (or cups), and the fact that there is no web server using gnutls in rhel, I don't that this is any serious limitation.

If we don't add support for SHA-384 and SHA-512 signatures in Certificate Verify, the second issue still remains:

> - Could not find a suitable certificate to send to server
> *** Fatal error: GnuTLS internal error.

In other words, if client has only certificate signed with SHA-384 and the server is asking only for SHA-256 or SHA-1 signatures, it should still send the certificate to server but sign the Certificate Verify with SHA-256.

That restricted scope can be addressed in RHEL-6.9. Adding high priority.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2017-0574.html