It looks dyn.dns.he.net is not using valid SSL certification, at least not one signed using well known CA registers.
$ curl -v -6 "https://lkasldkasldk:kjaskdjakdj@dyn.dns.he.net/nic/update?hostname=laksdlksaldksad"
* Connected to dyn.dns.he.net (2001:470:0:193::3000) port 443 (#0)
* found 180 certificates in /etc/ssl/certs/ca-certificates.crt
* found 720 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / RSA_AES_128_GCM_SHA256
* server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
* Closing connection 0
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
Same for wget and when trying to open it in browser.
It has been like this since day 1 iirr. Since HE has a wildcard certificate for *.he.net, why not use the properly signed certificate for dyn.dns.he.net?
*.he.net will not apply to work for dyn.dns.he.net , as the * in dns is just one level
they would need to get a *.dns.he.net for that
it is probably easier to create a dyn.he.net for that
and this is not since day 1, as in the past i had ssl=yes in ddclient and it worked... i don't know when it stop working
higuita