pfSense

Hello,

• Windows client / server with VALID certificate -> Connection OK (expected behavior)
• Windows client / server with SELF-SIGNED certificate -> Connection OK with a security warning (expected behavior)

• pfSense DynDNS, NO patch, verify certificate CHECKED / server with VALID certificate -> Connection OK (expected behavior)
• pfSense DynDNS, NO patch, verify certificate UNCHECKED / server with VALID certificate -> Connection OK (expected behavior)
• pfSense DynDNS, NO patch, verify certificate CHECKED / server with SELF-SIGNED certificate -> Connection failed with a security error (expected behavior)
• pfSense DynDNS, NO patch, verify certificate UNCHECKED / server with SELF-SIGNED certificate -> Connection failed with a security error (bug behavior)

• pfSense DynDNS, WITH patch, verify certificate CHECKED / server with VALID certificate -> Connection OK (expected behavior)
• pfSense DynDNS, WITH patch, verify certificate UNCHECKED / server with VALID certificate -> Connection OK (expected behavior)
• pfSense DynDNS, WITH patch, verify certificate CHECKED / server with SELF-SIGNED certificate -> Connection failed with a security error (expected behavior)
• pfSense DynDNS, WITH patch, verify certificate UNCHECKED / server with SELF-SIGNED certificate -> Connection happens but does nothing without any error (???)

Unfortunately I don't have much info on this strange last result. I can't see what the pfSense DynDNS service sends and receives. And on the server side: I can see that a connection with TLS 1.2 was successfully established (so I guess the patch fixed that), but after that the server just closes the connection without doing anything... Maybe pfSense closes the connection immediately without sending the HTTP request?

So I think this patch is incomplete.

I hope this helps.

If you're on 25.11.1 make sure to apply the recommended patches from the System Patches package then restart the syslogd service. Then test again with "Enable verbose logging" checked on the DDNS config.

So that's why I saw nothing in the logs! I didn't know the logs needed a patch too. I applied it and tested again the Dynamic DNS service with a server using a self-signed certificate.

Here are the system logs (with some values redacted, those values were correct by the way):

Feb 11 09:13:28    php-fpm    40507    /services_dyndns_edit.php: Dynamic DNS custom (): _update() ending.
Feb 11 09:13:28    php-fpm    40507    /services_dyndns_edit.php: Curl error occurred: SSL: no alternative certificate subject name matches target hostname 'XXX.SERV_DOMAIN.XXX'
Feb 11 09:13:28    php-fpm    40507    /services_dyndns_edit.php: Dynamic DNS custom (): _checkStatus() starting.
Feb 11 09:13:28    php-fpm    40507    /services_dyndns_edit.php: Response Data:
Feb 11 09:13:28    php-fpm    40507    /services_dyndns_edit.php: Response Header:
Feb 11 09:13:28    php-fpm    40507    /services_dyndns_edit.php: Sending request to: https://XXX.SERV_DOMAIN.XXX:8081/dyndns?ipv4=XX.XX.XX.XX
Feb 11 09:13:28    php-fpm    40507    /services_dyndns_edit.php: Dynamic DNS custom (): _update() starting.
Feb 11 09:13:27    php-fpm    40507    /services_dyndns_edit.php: Dynamic DNS: updatedns() starting
Feb 11 09:13:27    check_reload_status    676    Syncing firewall
Feb 11 09:13:27    php-fpm    40507    /services_dyndns_edit.php: Configuration Change: admin@10.0.2.4 (Local Database): Dynamic DNS client configured.

• pfSense connects to the configured DynDNS URL (the server logs says the connection is successfully established with TLS 1.2)
• pfSense tries to read a response and gets nothing (the server logs don't mention any HTTP request being received to begin with)
• pfSense checks the status of the DNS update and discovers that "curl" failed with "SSL: no alternative certificate subject name matches target hostname 'XXX.SERV_DOMAIN.XXX'"

This last part is correct, the certificate is for "localhost" only while pfSense is configured with the DNS of the server. I made another self-signed certificate with the DNS added as a Subject Alternative Name, and then the Dynamic DNS service started working properly:

Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Dynamic DNS custom (): _update() ending.
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Dynamic DNS custom (): _checkStatus() ending.
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: phpDynDNS (): (Success) IP Address Updated Successfully!
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_GRP_WAN_LTE_V4custom''4.cache: XX.XX.XX.XX
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Dynamic DNS custom (): _checkStatus() starting.
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Response Data: {"IPv4":"XX.XX.XX.XX"}
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Response Header:
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Response Header:
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Response Header: server: Kestrel
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Response Header: date: Wed, 11 Feb 2026 09:46:14 GMT
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Response Header: content-type: application/json; charset=utf-8
Feb 11 10:46:13    php-fpm    46037    /services_dyndns_edit.php: Response Header: HTTP/2 200
Feb 11 10:46:10    php-fpm    46037    /services_dyndns_edit.php: Sending request to: https://XXX.SERV_DOMAIN.XXX:8081/dyndns?ipv4=XX.XX.XX.XX
Feb 11 10:46:10    php-fpm    46037    /services_dyndns_edit.php: Dynamic DNS custom (): _update() starting.
Feb 11 10:46:10    php-fpm    46037    /services_dyndns_edit.php: Dynamic DNS: updatedns() starting

So the current patch does work in the sense that it removes the CA validation, and technically this is what this bug was about. But the certificate is still being partially validated for the domain name. I don't know if this is intended or not. Personally I think either you can make a valid certificate, or you can't and just want TLS encryption. And unless you want to add an additional checkbox option to let the user choose, I think forcing that an invalid certificate matches the URL adds nothing but configuration problems. But it's your call.

Patch for this is in the latest System Patches package as a recommended patch entry.

I see that you won't change the current behavior I commented on, so I am curious.

Could you tell me why do you want to validate the subject name of an invalid certificate? Is it because of a technical reason or does it have important security implications even when the certificate is invalid?

Skipping verification already removes any guarantee of a secure connection. However the option can be useful e.g. when testing. Additionally removing the hostname check promotes bad practice in every situation and is best left unsupported.

Oh I see! It's a policy that sacrifices convenience a little to force users doing at least the bare minimum. It probably avoids supporting silly edges cases all over pfSense in the long run too I suppose. Thank you for answering back!