License server has bad SSL cert?

This morning I'm getting license errors trying to look at Monday's trades:

jupyter:/codeload/moonshot $ quantrocket moonshot trade nr52 -o orders.csv
msg: '(''403 Client Error: FORBIDDEN for url: http://houston/master/main/securities.csv?fields=Currency&fields=Multiplier&fields=PriceMagnifier&fields=PrimaryExchange&fields=SecType&fields=Symbol&fields=Timezone'',
  {''status'': ''error'', ''error'': ''A license key is required (view license details
  if this is unexpected, see http://qrok.it/h/lkey for help)''})'
status: error
jupyter:/codeload/moonshot $ quantrocket license get
account: {}
concurrent_installs: 0
exchanges: []
licensekey: ... Eliding this ;) ...
plan: {}
jupyter:/codeload/moonshot $ quantrocket license get --force-refresh
error: 'HTTPSConnectionPool(host=''api.ipify.org'', port=443): Max retries exceeded
  with url: / (Caused by SSLError(SSLError("bad handshake: Error([(''SSL routines'',
  ''ssl3_get_server_certificate'', ''certificate verify failed'')],)",),))'
msg: an unhandled exception occurred, please check flightlog for the traceback and
  notify support if the problem persists as this might be a bug
status: error

When I hit https://api.ipify.org/ in Chrome, Chrome seems happy with it; when I try to curl it from QuantRocket Terminal, curl says the cert has expired:

jupyter:/codeload/moonshot $ curl -vv -o - https://api.ipify.org
* Rebuilt URL to: https://api.ipify.org/
*   Trying 54.243.162.249...
* TCP_NODELAY set
* Connected to api.ipify.org (54.243.162.249) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /opt/conda/ssl/cacert.pem
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, Server hello (2):
* SSL certificate problem: certificate has expired
* Closing connection 0
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
2 Likes

Getting the same problem! Not sure what's going on

Same problem here, since yesterday.

I'm digging into this a bit but not much to report.

When I do openssl s_client -connect api.ipify.org:443 -showcerts it shows a couple of the intermediate certificates in the chain were valid from May 30, 2000 until May 30, 2020 GMT and hence have just expired:

verify error:num=10:certificate has expired
notAfter=May 30 10:48:38 2020 GMT

Edit to add: Trying to fix or work around this has risks... You don't want to break SSL and end up sending your IB creds to J. Rando, Esq. Best thing would be if api.ipify.org can rotate its certificates and get rid of the chain with the expired intermediaries.

Paging @Brian

I see the issue has been logged at api.ipify.org: Root Certificate Expired May 30th · Issue #46 · rdegges/ipify-api · GitHub.

1 Like

We'll get a fix out today.

The license service is supposed to try this endpoint on a best efforts basis and ignore it if there are problems, but unfortunately the code is not catching a wide enough range of exceptions.

1 Like

A patch release is now available to resolve this issue.

I apologize for the inconvenience. The purpose of this API call is simply to associate each license key with an IP address as per the Privacy Policy, and we would never want the software to break if that process can't happen. That was the intention before and will now be the reality.

3 Likes

I just wanted to confirm (and help the less technical docker users like myself) it is necessary to deploy the cloud-based env prior.

  1. docker-machine env quantrocket
  2. eval $(docker-machine env quantrocket)
  3. docker compose -p quantrocket up -d

I had to active prior. The "how to update" link makes it seem like you can bypass:

Thank you for the quick fix!