Signature hash algorithm SHA256 (Certificate) vs Peer signing digest: SHA1

Question

As client I am using an API of a company. To be able to connect I have to decrease the security level to CipherString = DEFAULT@SECLEVEL = 1 in /etc/ssl/openssl.cnf using OpenSSL 1.1.1d.

Then if I do openssl s_client -connect <servername>:443 I get:

...
No client certificate CA names sent
Peer signing digest: SHA1
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4499 bytes and written 443 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: XXXXXXX
    Session-ID-ctx:
    Master-Key: XXXXXXXX
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1579345646
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no

Google Chrome in security panel says:

Connection - obsolete connection settings
The connection to this site is encrypted and authenticated using TLS 1.2, ECDHE_RSA with P-256, and AES_256_GCM.
The server signature uses SHA-1, which is obsolete. Enable a SHA-2 signature algorithm instead. (Note this is different from the signature in the certificate.)

Questions:

What is the relation of Peer signing digest with Signature hash algorithm (Certificate)?
Why it is connected with SHA1 when in https://www.ssllabs.com/ssltest/ gets A.
Can I do something as client?
If no what should they change in their servers?

Added more info:

openssl s_client -connect <servername>:443 -sigalgs <algorithm>+<hash>

(For OpenSSL 1.1.1d:  SECLEVEL=2)
ECDSA+SHA512  sslv3 alert handshake failure
ECDSA+SHA384  sslv3 alert handshake failure
ECDSA+SHA256  sslv3 alert handshake failure
ECDSA+SHA1    sslv3 alert handshake failure
RSA+SHA512    sslv3 alert handshake failure
RSA+SHA384    wrong signature type
RSA+SHA256    wrong signature type
RSA+SHA1      no suitable signature algorithm


(For OpenSSL 1.1.1d: SECLEVEL=1)
ECDSA+SHA512  sslv3 alert handshake failure
ECDSA+SHA384  sslv3 alert handshake failure
ECDSA+SHA256  sslv3 alert handshake failure
ECDSA+SHA1    sslv3 alert handshake failure
RSA+SHA512    sslv3 alert handshake failure
RSA+SHA384    connects with peer signing digest SHA1 type RSA
RSA+SHA256    connects with peer signing digest SHA1 type RSA
RSA+SHA1      connects with peer signing digest SHA1 type RSA

(For OpenSSL 1.0.2k)
ECDSA+SHA512  sslv3 alert handshake failure
ECDSA+SHA384  sslv3 alert handshake failure
ECDSA+SHA256  sslv3 alert handshake failure
ECDSA+SHA1    sslv3 alert handshake failure
RSA+SHA512    connects with peer signing digest SHA1 type RSA
RSA+SHA384    connects with peer signing digest SHA1 type RSA
RSA+SHA256    connects with peer signing digest SHA1 type RSA
RSA+SHA1      connects with peer signing digest SHA1 type RSA

Steffen Ullrich · Accepted Answer · 2020-01-18T16:20:30.423

What is the relation of Peer signing digest with Signature hash algorithm (Certificate)?

Peer signing digest is the algorithm used by the peer when signing things during the TLS handshake - see What is the Peer Signing digest on an OpenSSL s_client connection?. This is independent of the certificate. Signature hash algorithm (Certificate) is instead the digest algorithm used by the issuer of the certificate to sign the certificate.

Why it is connected with SHA1 when in https://www.ssllabs.com/ssltest/ gets A.

The security requirements for both cases differ. The Peer signing digest must be strong enough to not be breakable during the TLS handshake which takes at most a few seconds. The Signature hash algorithm (Certificate) should not be breakable as long as the key of the issuer certificate is valid, which is usually several years. This means for now SHA-1 is probably sufficient for protecting the TLS handshake but not for a certificate signature.

Can I do something as client?

In TLS 1.2 the client can send which digest algorithms are supported for the handshake. If the client does not offer SHA-1 the server should not use SHA-1, which means that it might use other algorithms offered by the client or that the connection fails. See the -sigalgs option for openssl s_client. Note that the server might simply ignore the information from the client about the supported algorithms - which seems to be the case in your setup. In this case there is nothing you can do as a client.

If no what should they change in their servers?

Nothing is known about the server so no recommendations can be done here. Depending on the server there might be an option to setup the signature algorithms for the TLS handshake or there might be no such option.

I added more details. Do you see something interesting to comment? — TicJit, Jan 18 '20 at 14:21
@TicJit: It looks like the server is ignoring the TLS extension where the client is providing the supported signature algorithms and will instead always use SHA1. The client does not accept this with SECLEVEL=2. In this case there is no way to influence the behavior of the server from the client since the server simply does not care what the client wants. — Steffen Ullrich, Jan 18 '20 at 16:19

Signature hash algorithm SHA256 (Certificate) vs Peer signing digest: SHA1

1 Answers1