Strange certificate issue arised using curl

[Slagroom]

Yesterday my wife started complaining that her Private Relay setting on her apple devices stopped resolving the webmail domain of my server, it resolved to the root domain name with an error, i.e. the name of the hestiacp. At the same time, I started seeing curl errors from cron;

*   Trying ip6:c206:2107:5636::1:443...
* Connected to somesite.nl (ip6:c206:2107:5636::1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: CN=my.hestiacpadmin.tld
*  start date: Jan 28 09:56:33 2023 GMT
*  expire date: Apr 28 09:56:32 2023 GMT
*  subjectAltName does not match somesite.nl
* SSL: no alternative certificate subject name matches target host name 'somesite.nl'
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name 'somesite.nl'
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.

These errors are related, and I have no idea what caused this, but it seems that all the hestia created letsencrypt certs are somehow not known to the localhost certs?
I’ve looked at why the curl crons stopped working on curl’s expain url, but it is mainly unclear to me how nginx has somehow changed to not resolve proper domain name queries the way it did up to yesterday.
This is beyond my scope of crypto experience. Can someone help out here? Where do I start looking?

[Slagroom]

Oh wait, it’s the IPv6 ! Please, hestia, can you enable ipv6 for your panel as a first new option?
The certs aren’t valid for ipv6.

[eris]

We are working on it but it takes a lot of time

Donate to Hestia Control Panel

If you would like to support the development

[Slagroom]

The only part that misses is just the fact that letsencrypt has not created the certs for the ipv6 address, next to the ipv4 one. This should not be too hard to solve. I can look at the code and see if I can expand on it.

The main admin domain does have valid ipv6 certification, probably because it runs prior to hestia generating letsencrypt certs. This causes Private Relay to go to that valid domain, and makes the curl commands expect a cert for the ipv6 address for the new/extra/other domains hestia helped create.

Turns out I got complaints from users since I’ve enabled ipv6 in nginx, they get cert errors on their domains. Apparently many ISPs now do run ipv6 all the way, which I did not expect. Annoying.
I will disable ipv6 for the entire server, that’s the safest solution for now…