CA's for CURL - DynDNS Custom w/HTTPS Update URL
-
Dyn DNS Service type Custom does not work with SSL/TLS because there is not CA available and by default curl verifies peer.
The other service types such as DynDNS.org that use SSL turn off the curl verify peer option. So they will work without a valid CA. But the end point is not assured. There could be a “man in the middle”.
To enable the dyndns custom type to work with SSL/TLS. Either a CA has to be provided to curl or verify peer option has to be turned off.
The quick and easy is to turn of verify peer option.
Another way is to provide a valid CA. This can be done either by pointing curlopt cainfo to the CA file. Or adding curl.cainfo to the php ini and pointing it to the CA file.
Yet another way is to put the CA in pfSense CA cert manager and add config code to get it from there. Similar to OpenVPN.
And then there is also this from casper4242
http://forum.pfsense.org/index.php/topic,52853.0.html
pkg_add -r ca_root_nss
Jim’s last message indicates it was added to the build Aug 2012. But I don’t see it in my system.What would be the preferred method of enabling for both dyndns custom and the others that use an https update URL so that verify peer option can be left enabled.
-
We disable that in quite a few places, but perhaps the code path for that update was missed?
dyndns.class:196: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:222: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:235: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:246: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:258: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:270: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:271: curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, FALSE); dyndns.class:340: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:347: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:369: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:384: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:397: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, FALSE); dyndns.class:920: curl_setopt($ip_ch, CURLOPT_SSL_VERIFYPEER, FALSE); pfsense-utils.inc:1497: curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);That said, the file from ca_root_nss is in /usr/local/share/certs/ca-root-nss.crt - curl can probably be influenced to find it there.
-
Ah that is what I needed. Yes curl does find it there auto-magically. The trouble turns out not to be so much those trusted root ca bundle, but rather I needed to provide a self-signed ca for my DNS server.
Got it figured out. Thanks.
What is the reason for disabling the peer verification? Since the trusted root ca bundle is available wouldn't it be better to do peer verification? Or is there some reason not to for dynamic dns updates?
-
Legacy code, mostly. The ca_root_nss inclusion is very recent. Most likely, nobody has tried/tested that with peer verification since that happened.
-
Not an official nor comprehensive test but I did succeed with an update of DynDNS.org with peer verification enabled. And also custom type with a self-signed ca. That is only a single instance with one of many providers though. Only reason I can think of for not using peer verification is the possibility of an occasional update failure due to a cert issue.
-
That could always be a per-entry checkbox option:
"Ignore server's SSL certificate", defaulting to off (unchecked)
It is likely rare to have an actual legitimate certificate failure, aside from custom update servers or other similar situations. The benefit would outweigh the risk, IMO, but it's probably too late to sneak such a change into 2.1.
-
Maybe I'll work on that. Already have some similar code running for the custom type to select a specific ca (either file or from ca manager), for instance a self-signed ca that is not in the systems bundle, and enable/disable peer and host verification option.
