Skip to content

Teeracle: SendWithCertificateVerification behaviour should be more roboust #1267

@OverOrion

Description

@OverOrion

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:

  1. Use the default trusted store of the http_req library, mimicking what a browser would do
  2. Add the option to specify a custom trusted store for SendWithCertificateVerification so it could handle a collection of certificates, instead of just one.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions