I’m guessing this is the cause of our curl 35 errors.
This is an issue as our services are protected through cloudflare and their certs are SHA256withECDSA/EC 256 bits. Apparently a curl upgrade will fix this. I have no option for a different certificate type without paying $5k a month to upload a custom certificate.
Can you PM me with more information? (URL being used etc). We disable known weak ciphers but I doubt cloudflare are offering those.
The fix for this has been prototyped and verified to work; still working on when it can be deployed to production. Stay tuned.
Just waiting for the next deploy, I hope this is going to be next week.
This should be live for you now. Give it a try?
Hmmm, is an agent OS change required for this? I see that a subset (33) of our agents have updated this morning, but none that we can test the ssl certs with.
I jumped the gun a bit. Pretty much everything but the developer servers have migrated; the cleanup is scheduled to be in the maintenance interval in about 12 hours- try again then?
This is now live.
There seems to be an unintended consequence of the ssl fix. We have used httprequest.setvalidation(VALIDATE_USING_SYSTEM_CA_CERTS) on all our httprequests (with the exception of the cloudflare ones).
This was even the case where the connection was http. Even though it wasn’t best practice, it worked just fine. But, no longer. HTTP requests will now fail. It has required a swift production fix for us. Not sure if it will catch anyone else out too.
Thanks for the heads up, we’ll replicate and see what may need fixing. There’s a later libcurl & a newer gnutls now deployed, but obviously our system tests doesn’t check setting validation and then doing an HTTP request.
The behaviour of httprequest.setvalidation() on HTTP was deliberately changed recently - to generate an error - but we didn’t document it. Sorry. This has now been corrected at https://electricimp.com/docs/api/httprequest/setvalidation/