The target of a CNAME must be a domain that the Pi-hole already has in its cache or is authoritative for. This is a universal limitation of CNAME records.
...
Additionally, you can't CNAME external domains (bing.com to google.com ) successfully as this could result in invalid SSL certificate errors when the target server does not serve content for the requested domain.
That's just an example of trying to direct one external site to another.
Edit - try using only an upstream server that doesn't have DNSSEC, for example Level 3 and Comodo appear to not have it based on the list in Settings > DNS. If Google promotes that CNAME redirection it stands to reason that they are supporting it with the correct SSL, and it might just be the DNSSEC element which is making it fail.
See this post for why it fails in your browser and a possible script-based workaround.
Regarding the general idea, the CNAME disclaimers are correct but I'd expect Google to have sorted the SSL aspect if they're promoting this as a way to force safe search. When I try it with Unbound it returns BOGUS results, meaning the domain info doesn't match what I requested, which I'd imagine is correct. I suggested using a non-DNSSEC upstream and disabling DNSSEC in Pi-hole as a possible way to avoid that, but I don't know if it's relevant.
Wow.. that sucks haha.. The way I am forcing safe search now is using DNS records, but hopefully the IPs never change.
I just wanted to try the CNAME option, but I guess that's not working. I did notice duckduckgo works fine using the CNAME..it's only bing and google the ones with the issue.