Following the Debian install instructions, curl-ing the archive keyring from geti2p.net/_static/i2p-archive-keyring.gpg returns a 301 redirect to https://i2p.net/i2p-archive-keyring.gpg. Connecting to that redirect target fails TLS verification — the server presents a self-signed certificate, and wget additionally reports that the certificate's owner does not match the hostname i2p.net.
Because the keyring is security-critical (it's the root of trust for all subsequently installed I2P packages), I stopped rather than bypass cert checks with -k / --no-check-certificate.
Steps to reproduce
curl -v https://geti2p.net/_static/i2p-archive-keyring.gpg -o /tmp/key.gpg
- TLS to
geti2p.net succeeds (valid Let's Encrypt cert, CN=geti2p.net, issued by R13).
- Response:
HTTP/1.1 301 MOVED PERMANENTLY, Location: https://i2p.net/i2p-archive-keyring.gpg.
curl -fL https://geti2p.net/_static/i2p-archive-keyring.gpg -o /tmp/key.gpg
- Fails:
curl: (60) SSL certificate problem: self-signed certificate.
wget https://i2p.net/idk.key.asc
- Fails:
ERROR: The certificate of 'i2p.net' is not trusted. / doesn't have a known issuer. / owner does not match hostname 'i2p.net'.
Server details from curl -v on geti2p.net
- Server:
Werkzeug/3.1.5 Python/3.12.3
- Redirect issued to
https://i2p.net/i2p-archive-keyring.gpg
- HSTS header set
Resolved IPs seen from my host
geti2p.net → 81.7.7.63 (valid cert)
i2p.net → 109.0.66.29, 2a02:8400::5757:444e:0 (self-signed cert, hostname mismatch)
Environment
- Debian VM (fresh install)
curl 7.88.1
ca-certificates package up to date
Impact
The documented curl command in the Debian install instructions cannot complete successfully without disabling certificate verification, which defeats the purpose of fetching a signing key over TLS. New users following the docs will either hit a wall or — worse — be tempted to use -k and import whatever key the endpoint serves.
Following the Debian install instructions,
curl-ing the archive keyring fromgeti2p.net/_static/i2p-archive-keyring.gpgreturns a 301 redirect tohttps://i2p.net/i2p-archive-keyring.gpg. Connecting to that redirect target fails TLS verification — the server presents a self-signed certificate, andwgetadditionally reports that the certificate's owner does not match the hostnamei2p.net.Because the keyring is security-critical (it's the root of trust for all subsequently installed I2P packages), I stopped rather than bypass cert checks with
-k/--no-check-certificate.Steps to reproduce
curl -v https://geti2p.net/_static/i2p-archive-keyring.gpg -o /tmp/key.gpggeti2p.netsucceeds (valid Let's Encrypt cert, CN=geti2p.net, issued by R13).HTTP/1.1 301 MOVED PERMANENTLY,Location: https://i2p.net/i2p-archive-keyring.gpg.curl -fL https://geti2p.net/_static/i2p-archive-keyring.gpg -o /tmp/key.gpgcurl: (60) SSL certificate problem: self-signed certificate.wget https://i2p.net/idk.key.ascERROR: The certificate of 'i2p.net' is not trusted./doesn't have a known issuer./owner does not match hostname 'i2p.net'.Server details from curl -v on geti2p.net
Werkzeug/3.1.5 Python/3.12.3https://i2p.net/i2p-archive-keyring.gpgResolved IPs seen from my host
geti2p.net→ 81.7.7.63 (valid cert)i2p.net→ 109.0.66.29, 2a02:8400::5757:444e:0 (self-signed cert, hostname mismatch)Environment
curl 7.88.1ca-certificatespackage up to dateImpact
The documented
curlcommand in the Debian install instructions cannot complete successfully without disabling certificate verification, which defeats the purpose of fetching a signing key over TLS. New users following the docs will either hit a wall or — worse — be tempted to use-kand import whatever key the endpoint serves.