FTL.log; WARNING SSL/TLS certificate <FILE> does not match domain <DOMAIN>!

[Eddict]

Versions

• Pi-hole: Core version is v6.0.1 (Latest: v6.0.1)
• AdminLTE: Web version is v6.0 (Latest: v6.0)
• FTL: FTL version is v6.0 (Latest: v6.0)

Platform

• OS and version: Debian GNU/Linux 12 (bookworm)
• Platform: Proxmox container

Expected behavior

I would not expect this warning as my certificate is a wildcard SSL certificate

Actual behavior / bug

webserver.webserver.tls points to a valid TLS (SSL) certificate file, which is a wildcard certifcate.
CN = domain.com
subject alt names contains "domain.com", ".domain.com" and ".sub.domain.com"

webserver.domain is set to "sub.domain.com"

Steps to reproduce

Steps to reproduce the behavior:

test above with a wildcard certificate containing "domain.com", ".domain.com" and ".sub.domain.com" and set webserver.domain to "sub.domain.com". restart pihole-FTL service

Debug Token

• URL:
  [✓] Your debug token is: https://tricorder.pi-hole.net/N1Pc1r8T/

Screenshots

Additional context

[DL6ER]

FTL should check the extra SAN domains. Could you please run

pihole-FTL --read-x509 /etc/pihole/tls.pem | pihole tricorder

and provide the uploaded token? You should first run it without the "| pihole tricorder" to see there is nothing bad uploaded. If you don't want this, you can also post it here in sanitized form. I somehow have the feeling there my be no exact match somewhere as you said "wildcard". This may be confusing FTL.

[Eddict]

i ran the command, but pointing to another file (the /etc/pihole/tls.pem is still the default pi.hole certificate).
i used the same file as in toml setting [webserver.tls].cert

https://tricorder.pi-hole.net/aQ2BTQC6/

[RyeNCode]

I posted what appears to be a duplicate issue as #2277 (sorry)!

However, I do think I found the cause (wrong strncasecmp compare length used) in a flow that is only used when checking against a wildcard certificate.
Oddly testing the domain *.yourdomain.tld would match a cert with a SAN *.yourdomain.tld

[iShark5060]

Got the same issue, also with a wildcard cert.
https://tricorder.pi-hole.net/WoHnNgnE/

at least chrome doesn't complain (duh, the cert is valid)

[RyeNCode]

Yes, pihole-FTL still seems to use the cert, but produces the warning message every startup of the process from my limited testing. -- Ryan ***@***.***

…

On February 25, 2025 3:03:15 p.m. MST, Lutz Schwemer Panchez ***@***.***> wrote: iShark5060 left a comment (pi-hole/FTL#2227) Got the same issue, also with a wildcard cert. https://tricorder.pi-hole.net/WoHnNgnE/ at least chrome doesn't complain (duh, the cert is valid)  -- Reply to this email directly or view it on GitHub: #2227 (comment) You are receiving this because you commented. Message ID: ***@***.***>

[DL6ER]

Sorry for the long delay... Seems you are right with assuming there is a length check issue in strcasecmp(). In some cases, it still works (when the next byte after the SAN happens to be nul) but that is not guaranteed. Could you please verify

sudo pihole checkout ftl fix/san_wildcard

fixes this for you? The certificate is always used, even when FTL finds a mismatch as the error message in your browser (that the domain is incorrect) is probably more helpful for you to debug than us simply rejecting the certificate and you first have to look for and then read the log files.

[RyeNCode]

@DL6ER I have just tested that, first locally with the branch and confirmed that the --read-x509 with a check domain command now behaves as expected. I performed the on-system pihole checkout operation successfully and it also no longer produces the previous warning and validates the wildcard correctly.
(The code change is precisely what I came up with when doing my diagnosis too /toot-my-own-horn 👍 )

I say the fix/san_wildcard fix addresses the issue.