Discussion:
Bug#934453: curl: SSL routines:tls12_check_peer_sigalg:wrong signature type
Add Reply
Johannes 'josch' Schauer
2019-08-11 07:50:01 UTC
Reply
Permalink
Package: curl
Version: 7.65.3-1
Severity: normal

Hi,

steps to reproduce:

$ sudo debootstrap --include=curl,ca-certificates unstable debian-unstable
[...]
$ sudo chroot debian-unstable curl -vvv https://www.daserste.de
* Trying 8.248.97.252:443...
* TCP_NODELAY set
* Connected to www.daserste.de (8.248.97.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (OUT), TLS alert, handshake failure (552):
* error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
* Closing connection 0
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type

This also happens with other domains. I hope this is actually a curl
issue and not my own stupidity but this problem only occurs with curl
and not wget or firefox and the domain from above has an A+ rating on
ssllabs.com, so I guess it is properly configured.

Thanks!

cheers, josch
Johannes Schauer
2019-08-12 08:10:02 UTC
Reply
Permalink
Control: reassign -1 openssl 1.1.1~~pre9-1
Control: tag -1 + buster
Post by Johannes 'josch' Schauer
$ sudo debootstrap --include=curl,ca-certificates unstable debian-unstable
[...]
$ sudo chroot debian-unstable curl -vvv https://www.daserste.de
* Trying 8.248.97.252:443...
* TCP_NODELAY set
* Connected to www.daserste.de (8.248.97.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: none
CApath: /etc/ssl/certs
* error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
* Closing connection 0
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
This also happens with other domains. I hope this is actually a curl
issue and not my own stupidity but this problem only occurs with curl
and not wget or firefox and the domain from above has an A+ rating on
ssllabs.com, so I guess it is properly configured.
I now figured out that this problem is actually due to openssl and not due to
curl. I bisected Debian unstable from snapshot.d.o to figure out that the last
working snapshot is 20180822T014239Z and the first that shows this problem is
20180822T060826Z. When I diff the output of `dpkg -l` on both chroots then I
get:

82c82
< ii libssl1.1:amd64 1.1.0h-4 amd64 Secure Sockets Layer toolkit - shared libraries
---
Post by Johannes 'josch' Schauer
ii libssl1.1:amd64 1.1.1~~pre9-1 amd64 Secure Sockets Layer toolkit - shared libraries
95c95
< ii openssl 1.1.0h-4 amd64 Secure Sockets Layer toolkit - cryptographic utility
---
Post by Johannes 'josch' Schauer
ii openssl 1.1.1~~pre9-1 amd64 Secure Sockets Layer toolkit - cryptographic utility
Thanks!

cheers, josch
Johannes Schauer
2019-08-12 08:50:02 UTC
Reply
Permalink
Hi,
Post by Johannes Schauer
Post by Johannes 'josch' Schauer
$ sudo debootstrap --include=curl,ca-certificates unstable debian-unstable
[...]
$ sudo chroot debian-unstable curl -vvv https://www.daserste.de
* Trying 8.248.97.252:443...
* TCP_NODELAY set
* Connected to www.daserste.de (8.248.97.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: none
CApath: /etc/ssl/certs
* error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
* Closing connection 0
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
This also happens with other domains. I hope this is actually a curl
issue and not my own stupidity but this problem only occurs with curl
and not wget or firefox and the domain from above has an A+ rating on
ssllabs.com, so I guess it is properly configured.
I now figured out that this problem is actually due to openssl and not due to
curl. I bisected Debian unstable from snapshot.d.o to figure out that the last
working snapshot is 20180822T014239Z and the first that shows this problem is
20180822T060826Z. When I diff the output of `dpkg -l` on both chroots then I
82c82
< ii libssl1.1:amd64 1.1.0h-4 amd64 Secure Sockets Layer toolkit - shared libraries
---
Post by Johannes 'josch' Schauer
ii libssl1.1:amd64 1.1.1~~pre9-1 amd64 Secure Sockets Layer toolkit - shared libraries
95c95
< ii openssl 1.1.0h-4 amd64 Secure Sockets Layer toolkit - cryptographic utility
---
Post by Johannes 'josch' Schauer
ii openssl 1.1.1~~pre9-1 amd64 Secure Sockets Layer toolkit - cryptographic utility
thanks to juliank on #debian-devel I found out that this issue seems to be a
duplicate of #912759?

If so, what should I write to the server admins of daserste.de? I'm not quite
knowledgable about the topic and with the Qualys SSL Labs Server test reporting
an A+ for the server, I don't know what argument to make that they are wrong.

Thanks!

cheers, josch

Loading...