Your message dated Sun, 14 Jul 2024 06:49:46 +0200
with message-id <9cf2360a-bf8d-44cc-b98b-ddae835bd...@debian.org>
and subject line Re: stenographer provides certificates in /etc/stenographer
for 127.0.0.1 without subjectAltName
has caused the Debian Bug report #1075859,
regarding stenographer provides certificates in /etc/stenographer for 127.0.0.1
without subjectAltName
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1075859: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1075859
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: stenographer
Severity: normal
Dear Maintainer, hi.
The curl maintainers (I'm one of them) made an upload, 8.8.0-2,
switching curl to use gnutls as backend and this apparently broke
stenographer tests [1]. These last couple days sergiodj helped me debug
the issue and we pinned down to stenoread calling stenocurl in
run-example line 62:
61 su testuser -c "stenoread 'after 5m ago'"
It uses curl to query localhost (127.0.0.1) using tls and here our
problems begin. It used to work previously (pre 8.8.0-2, or with
openssl), but now it has stopped working with gnutls. We have the
following error:
> root@curl:/tmp/autopkgtest.vuqnBT/build.cBe/src# su testuser -c "stenoread
> 'after 5m ago'"
> Running stenographer query 'after 5m ago', piping to 'tcpdump '
> * Trying 127.0.0.1:1234...
> * Connected to 127.0.0.1 (127.0.0.1) port 1234
> * GnuTLS ciphers: NORMAL:-ARCFOUR-128:-CTYPE-ALL:+CTYPE-X509:-VERS-SSL3.0
> * found 1 certificates in /etc/stenographer/certs/ca_cert.pem
> * found 438 certificates in /etc/ssl/certs
> * SSL connection using TLS1.3 / ECDHE_RSA_AES_128_GCM_SHA256
> * server certificate verification OK
> * server certificate status verification SKIPPED
> * SSL: certificate subject name (127.0.0.1) does not match target host name
> '127.0.0.1'
> * Closing connection
> curl: (60) SSL: certificate subject name (127.0.0.1) does not match target
> host name '127.0.0.1'
> More details here: https://curl.se/docs/sslcerts.html
>
> curl failed to verify the legitimacy of the server and therefore could not
> establish a secure connection to it. To learn more about this situation and
> how to fix it, please visit the web page mentioned above.
> tcpdump: truncated dump file; tried to read 4 file header bytes, only got 0
Turns out gnutls only checks subjectAltName for matching an IP in the
hostname, but stenographer's certs doesn't have it, only subject name.
I'm don't know a lot about it, but after a few ours of research and
reading more RFCs than I'd like, I found RFC 2818 with the following:
> If a subjectAltName extension of type dNSName is present, that MUST
> be used as the identity. Otherwise, the (most specific) Common Name
> field in the Subject field of the certificate MUST be used. Although
> the use of the Common Name is existing practice, it is deprecated and
> Certification Authorities are encouraged to use the dNSName instead.
>
> Matching is performed using the matching rules specified by
> [RFC2459]. If more than one identity of a given type is present in
> the certificate (e.g., more than one dNSName name, a match in any one
> of the set is considered acceptable.) Names may contain the wildcard
> character * which is considered to match any single domain name
> component or component fragment. E.g., *.a.com matches foo.a.com but
> not bar.foo.a.com. f*.com matches foo.com but not bar.com.
>
> In some cases, the URI is specified as an IP address rather than a
> hostname. In this case, the iPAddress subjectAltName must be present
> in the certificate and must exactly match the IP in the URI.
In the end of the day, gnutls is just following the RFC, but it breaks
the tests and blocks curl's migration. Our first thought was to report
upstream, but we saw the repo on github is archived. So, here we are.
I'd say the best solution is to regenerate the certificates with
subjectAltName containing 127.0.0.1. Telling curl to ignore it also
works, but I think it wouldn't be ideal.
Cheers,
Charles
[1] https://ci.debian.net/packages/s/stenographer/testing/arm64/48709812/
signature.asc
Description: PGP signature
--- End Message ---
--- Begin Message ---
Looks like the upload fixed the issue:
https://ci.debian.net/packages/s/stenographer/unstable/arm64/ (1.0.1-4
-> 1.0.1-6)
Closing this bugticket.
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
