Contact to localhost TLD broken in Debian Bookworm, curl: (60) SSL: no alternative certificate subject name

[stasadev]

Is there an existing issue for this?

• I have searched the existing issues

Output of ddev debug test

Expand `ddev debug test` diagnostic information

[COPY-PASTE HERE THE OUTPUT OF `ddev debug test`]

Expected Behavior

It should be working as before, in DDEV v1.22.7, I tracked in down to Debian Bookworm change in:

• build: bump ddev-php-base and ddev-webserver to base on Debian 12 bookworm, replaces #5278 #5579

The closest issues about this error in Ubuntu (fixed):

• curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it curl/curl#11475
• https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2028170
• https://askubuntu.com/q/1478616
• https://askubuntu.com/q/1493777

Actual Behavior

Communication between DDEV project doesn't work if the target site uses localhost TLD.

To reproduce I created two projects, test-project-1 with localhost TLD and test-project-2 with ddev.site TLD.

docker-compose.communicate.yaml in test-project-1:

services:
  web:
    external_links:
      - "ddev-router:test-project-2.ddev.site"

docker-compose.communicate.yaml in test-project-2:

services:
  web:
    external_links:
      - "ddev-router:test-project-1.localhost"

Use curl inside the ddev-test-project-2-web container:

$ curl https://test-project-1.localhost
curl: (60) SSL: no alternative certificate subject name matches target host name 'test-project-1.localhost'
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.
Failed to execute command curl https://test-project-1.localhost: exit status 60

Steps To Reproduce

Create two projects with index.php and .ddev/docker-compose.communicate.yaml:

mkdir test-project-1 && cd test-project-1 && ddev config --auto --omit-containers=db --project-tld=localhost && printf "services:\n  web:\n    external_links:\n      - \"ddev-router:test-project-2.ddev.site\"\n" > .ddev/docker-compose.communicate.yaml && printf "<?php\necho 'received answer from test-project-1.localhost'.PHP_EOL;\n" > index.php && cd .. && mkdir test-project-2 && cd test-project-2 && ddev config --auto --omit-containers=db && printf "services:\n  web:\n    external_links:\n      - \"ddev-router:test-project-1.localhost\"\n" > .ddev/docker-compose.communicate.yaml && printf "<?php\necho 'received answer from test-project-2.ddev.site'.PHP_EOL;\n" > index.php && cd ..

Allow sudo access to edit the hosts file for test-project-1.localhost:

ddev start test-project-1 test-project-2

curl works with *.ddev.site:

cd test-project-1 && ddev exec curl https://test-project-2.ddev.site; cd ..
received answer from test-project-2.ddev.site

curl doesn't work with *.localhost:

cd test-project-2 && ddev exec curl https://test-project-1.localhost; cd ..
curl: (60) SSL: no alternative certificate subject name matches target host name 'test-project-1.localhost'
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.
Failed to execute command curl https://test-project-1.localhost: exit status 60

Check if alternative certificate subject name 'test-project-1.localhost' exists

cd test-project-2 && ddev exec openssl s_client -connect test-project-1.localhost:443 </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName; cd ..
Warning: Reading certificate from stdin since no -in or -new option is given
X509v3 Subject Alternative Name:
    DNS:*.ddev.site, DNS:localhost, DNS:*.ddev.local, DNS:ddev-router, DNS:ddev-router.ddev, DNS:ddev-router.ddev_default, DNS:test-project-1.localhost, DNS:*.localhost, IP Address:127.0.0.1

curl by name works both ways:

cd test-project-1 && ddev exec curl ddev-test-project-2-web; cd ..
received answer from test-project-2.ddev.site

cd test-project-2 && ddev exec curl ddev-test-project-1-web; cd ..
received answer from test-project-1.localhost

And cleanup:

ddev delete test-project-1 test-project-2 -Oy
# rm -rf test-project-1 test-project-2
# sudo ddev hostname -r test-project-1.localhost 127.0.0.1

Anything else?

It's working with DDEV v1.22.7:

$ ddev --version && ddev exec lsb_release -a && ddev exec curl --version
ddev version v1.22.7
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye
curl 7.74.0 (x86_64-pc-linux-gnu) libcurl/7.74.0 OpenSSL/1.1.1w zlib/1.2.11 brotli/1.0.9 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3
Release-Date: 2020-12-09, security patched: 7.74.0-1.3+deb11u11
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets

But it doesn't work with DDEV HEAD:

$ ddev --version && ddev exec lsb_release -a && ddev exec curl --version
ddev version v1.23.0-alpha1-7-g2334386db
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:        12
Codename:       bookworm
curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.11 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13
Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u5
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

[stasadev]

A usage of localhost TLD is covered in RFC 6761.

I tested this on Arch-based Linux and macOS arm64, so I assume this is related to curl / OpenSSL.

A workaround is to simply not use the localhost TLD (should be added to the release notes if no solution is found).

[rfay]

You probably already know about this, but the other thing about "localhost" is it typically resolves to both an IPV4 and an IPV6 address. In the Docker world, we have only IPV4.

[Schwepsi]

Oh, I have the same problem. But often (everytime?) you can interconnect with the project-Container urls:
https://ddev-{project-name}-web/ for the web Container, and this should work for the db container in the same way.
I am currently using the inter-web-container connection on tuxedo, 22.04 a debian or most likely an ubuntu derivate

Hope this helps

EDIT: I am currently using it to connect two symfony projects through a rest api

[rfay]

@Schwepsi are you using current HEAD or the v1.23.0-alpha1 release? This issue is about the new ddev-webserver based on Debian Bookworm, and those are its first appearance.

[stasadev]

You probably already know about this, but the other thing about "localhost" is it typically resolves to both an IPV4 and an IPV6 address. In the Docker world, we have only IPV4.

@rfay, yes, I know 👍, I have a setting to prefer IPv4 over IPv6 in my system https://wiki.archlinux.org/title/IPv6#Prefer_IPv4_over_IPv6

But often (everytime?) you can interconnect with the project-Container urls: ddev-{project-name}-web

@Schwepsi, yes, thanks, I mentioned this workaround in the OP, it's just not always suitable (when you need to access the "real" URL in another project).

[stasadev]

I'm closing this as not planned, but I'm happy to reopen it if a workaround is found.

Current workarounds:

• use connections by container name only, e.g. ddev exec curl https://ddev-<project-name>-web.
• use a different TLD.