You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Coingecko changed their certificate (authority) for their API endpoint from Let's encrypt #1162 and now it seems they changed it back, resulting in fetching failure.
Our current solution relies on that we pass a single root_cert not a collection of trusted root certificates, which in cases like this causes problems, because for a fix to be applied a rebuld / redeployment is needed.
I can see why it was implemented like this, but because this is a 3rd party we should not rely on the fact they will never change their certificate (authority).
Proposed solutions:
Use the default trusted store of the http_req library, mimicking what a browser would do
Add the option to specify a custom trusted store for SendWithCertificateVerification so it could handle a collection of certificates, instead of just one.
The text was updated successfully, but these errors were encountered:
Coingecko changed their certificate (authority) for their API endpoint from Let's encrypt #1162 and now it seems they changed it back, resulting in fetching failure.
Our current solution relies on that we pass a single
root_cert
not a collection of trusted root certificates, which in cases like this causes problems, because for a fix to be applied a rebuld / redeployment is needed.I can see why it was implemented like this, but because this is a 3rd party we should not rely on the fact they will never change their certificate (authority).
Proposed solutions:
http_req
library, mimicking what a browser would dotrusted store
forSendWithCertificateVerification
so it could handle a collection of certificates, instead of just one.The text was updated successfully, but these errors were encountered: