Accessing endpoints

[martijnlammers]

So far I've managed to run a Javascript bundle in an enclave, but I now am running into the issue with accessing these. I am using the test bundle js-app-bundle to see whether I can manage to send requests over TLS using curl, following the documentation.

I've run started one single node using
$ /opt/ccf/bin/sandbox.sh --js-app-bundle ./js-app-bundle/ --enclave-type release

. . .
[12:21:30.599] Node [0] = https://127.0.0.1:8000
[12:21:30.599] You can now issue business transactions to the libjs_generic application
[12:21:30.599] Loaded JS application: ./js-app-bundle/
. . .

In a second terminal, I attempted to access the /compute endpoint using
$ curl https://127.0.0.1:8000/app/compute -X POST --cacert networkcert.pem --cert user0_cert.pem --key user0_privk.pem -H "Content-Type: application/json" --data-binary '{"op": "add", "left": 5, "right": 5}'

This however ended up giving me a SSL certificate error. I wasn't exactly sure what could have possibly caused this, so I ended up shutting the node down, emptying the auth_policies field in app.json hopes I could invoke the endpoint regardless, unfortunately this resulted in thesame issue.

curl: (60) SSL certificate problem: unable to get local issuer certificate
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.

I'd figure that this is what the scurl.sh wrapper is used for, this however gives me exactly thesame issue running
$ scurl.sh https://127.0.0.1:8000/app/compute -X POST --cacert networkcert.pem --signing-cert user0_cert.pem --signing-key user0_privk.pem -H "Content-Type: application/json" --data-binary '{"op": "add", "left": 5, "right": 5}'

What have I done wrong here?

[eddyashton]

@mAlyanak: An unable to get local issuer certificate error suggests curl is using a networkcert.pem file, but not the correct one for the current service. Are you in the correct workspace directory for the newly started service, or have you copied those certs to the current working directory?

The common folder populated by the sandbox.sh script is listed in the output:

10:07:39.854 | INFO     | __main__:run:85 - Loaded JS application: ../tests/js-app-bundle/
10:07:39.854 | INFO     | __main__:run:86 - Keys and certificates have been copied to the common folder: /data/src/CCF/build/workspace/sandbox_common

So you will need to use those certs to communicate, either by passing the full path:

$ curl https://127.0.0.1:8000/app/compute -X POST --cacert /data/src/CCF/build/workspace/sandbox_common/networkcert.pem --key /data/src/CCF/build/workspace/sandbox_common/user0_privk.pem --cert /data/src/CCF/build/workspace/sandbox_common/user0_cert.pem -H "Content-Type: application/json" --data-binary '{"op": "add", "left": 5, "right": 5}'
{"result":10}

or changing the working directory:

$ cd /data/src/CCF/build/workspace/sandbox_common/
$ curl https://127.0.0.1:8000/app/compute -X POST --cacert networkcert.pem --cert user0_cert.pem --key user0_privk.pem -H "Content-Type: application/json" --data-binary '{"op": "add", "left": 5, "right": 5}'{"result":10}

or copying those files elsewhere, and using the appropriate path.

If you pass a -v (verbose) argument to sandbox.sh, it will print a lot more detail as it starts up, including sample curl commands it is running:

$ sandbox.sh ... -v
...
10:07:39.764 | SUCCESS  | infra.network:start_and_join:445 - ***** Network is now open *****
10:07:39.765 | DEBUG    | ccf.clients:request:366 - Running: curl https://127.0.0.1:8000/app/commit -X GET -i -m 10 -L --cacert /data/src/CCF/build/workspace/sandbox_common/networkcert.pem --key /data/src/CCF/build/workspace/sandbox_common/user0_privk.pem --cert /data/src/CCF/build/workspace/sandbox_common/user0_cert.pem
10:07:39.854 | INFO     | __main__:run:65 - [0|user0|] GET /app/commit
10:07:39.854 | INFO     | __main__:run:65 - 200 @2.10 {"transaction_id":"2.10"}
10:07:39.854 | INFO     | __main__:run:73 - Started CCF network with the following nodes:
10:07:39.854 | INFO     | __main__:run:75 -   Node [0] = https://127.0.0.1:8000
...

scurl.sh is not needed here. It adds a HTTP signature header to the request, which is necessary for member governance commands (whose authentication policy requires member signatures), but not for the compute endpoint here (whose authentication policy just requires a known user certificate).

[eddyashton]

If the authn_policies in app.json is an empty list, or no_auth, then (as documented here) there is no authentication policy and anybody can call this endpoint. In that case, you could remove the --cert and --key arguments to curl which provide a client identity. However, generally clients should still be checking the identity of the server when initiating a TLS connection. That's what the --cacert option to curl is doing. If you wish to turn that off, you can tell curl to ignore that check (and communicate with any server, regardless of the cert it presents), with the -k option:

 -k, --insecure      Allow insecure server connections when using SSL

[martijnlammers]

@eddyashton You're right, I did use the incorrect certificates, thank you Eddy. I initially copied them out of the wrong directory.