{"id":20713252,"url":"https://github.com/linaro/lite_bootstrap_server","last_synced_at":"2025-04-23T08:05:19.764Z","repository":{"id":38374220,"uuid":"274653614","full_name":"Linaro/lite_bootstrap_server","owner":"Linaro","description":"Proof of concept certificate authority and bootstrap server","archived":false,"fork":false,"pushed_at":"2023-01-05T13:32:40.000Z","size":206,"stargazers_count":10,"open_issues_count":6,"forks_count":6,"subscribers_count":5,"default_branch":"master","last_synced_at":"2025-04-23T08:05:11.394Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-3.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Linaro.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2020-06-24T11:37:23.000Z","updated_at":"2023-07-04T15:00:10.000Z","dependencies_parsed_at":"2022-07-12T01:47:32.948Z","dependency_job_id":null,"html_url":"https://github.com/Linaro/lite_bootstrap_server","commit_stats":null,"previous_names":["microbuilder/linaroca"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Linaro%2Flite_bootstrap_server","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Linaro%2Flite_bootstrap_server/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Linaro%2Flite_bootstrap_server/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Linaro%2Flite_bootstrap_server/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Linaro","download_url":"https://codeload.github.com/Linaro/lite_bootstrap_server/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":250395284,"owners_count":21423400,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-17T02:24:07.458Z","updated_at":"2025-04-23T08:05:19.745Z","avatar_url":"https://github.com/Linaro.png","language":"Go","readme":"# LITE Bootstrap Server\n\nA proof-of-concept certification authority (CA) and bootstrap server written\nin Go.\n\nThis utility provides an authenticated REST API that can be used to:\n\n- Validate and process certificate signing requests (CSRs)\n- Register devices on a 3rd party IoT device management service during certificate registration\n- Provision devices with basic connection details (e.g. MQTT broker domain/port)\n- List previously registered devices\n- Check certificate validity\n\nCertificate signing requests are logged to a local SQLite database (`CADB.db`).\n\nDevice registration hooks to an IoT device management service and returns connection\ndetails. Currently, the returned connection details are MQTT broker details\nbased on Azure IoT Hub. Support for other providers may be offered in the future.\n\nIt also enables a basic TCP/TLS server (`mTLS TCP server`) that requests a client\ncertificate during the TLS handshake, verifying that the certificate has been\nsigned by the CA. This is only used for testing and proof of concept purposes.\n\n\u003e The REST API will only accept requests from client devices with access to the\n  bootstrap certificate and private key generated by `setup-bootstrap.sh`\n  further below in this guide. It's assumed that this certificate and its \n  corresponding private key is provisioned to devices in the factory. \n\n## Prerequisites\n\nThis project requires a recent version of go to compile and debug the server.\n\nFor platform-specific details on installing go, see: https://go.dev/doc/install\n\n# Quick Setup\n\n## 0. Build the App\n\nIf you haven't already, the first step is to clone and build the app locally:\n\n```bash\n$ git clone https://github.com/Linaro/lite_bootstrap_server.git\n$ cd lite_bootstrap_server\n$ go build -o liteboot\n```\n\n\u003e The `-o liteboot` is optional, but will cause the compiled app to have the\n  shorter `liteboot` name instead of the cumbersome default of\n  `lite_bootstrap_server`.\n\n## 1. Add a Config File\n\nYou can override various config settings with a `.liteboot.toml` file in the\napplication root folder.\n\nThe `[server]` settings, which map to the command-line parameters shown with\n`liteboot server --help`, must be populated to set the ports used by the\nutility, as well as to provide a response to the `ccs` endpoint:\n\n```toml\n[server]\n# Azure IoT Hub Settings\nhubname = \"azure-hub-name\"\nresourcegroup = \"azure-resource-group\"\nmqttport = 8883\n\n# Set the server hostname explicitly\n# hostname = \"myhostname.local\"\n\n# CA port number (REST API)\nport = 1443\n\n# mTLS port number\nmport = 8443\n```\n\n## 2. Set the Hostname\n\nThe hostname is important since it will be included in the subject line of\ncertificates signed by liteboot, and be part of the SERVER certificate used to\nestablish a TLS connection to the server.\n\nThe **same hostname** must be used in the SERVER certificate or the\nTLS connection will be refused.\n\nThis application will attempt to determine the hostname to use for the\nserver(s) based on the following order of precedence:\n\n1. Via the `--hostname` parameter in the `server` command\n2. Via a `hostname` entry in the `.liteboot.toml` config file\n   (see step 1 above)\n3. Check for the `$CAHOSTNAME` environment variable\n4. Check the system hostname (same value as `hostname` in shell)\n5. Default to `localhost` as a last resort\n\nFor example, set the hostname before starting the server via:\n\n```bash\n$ export CAHOSTNAME='myhostname.local'\n````\n\nWhich could also be overridden via:\n\n```bash\n$ ./liteboot server start --hostname=\"localhost\"\n```\n\nFor local development, this can usually be set to `localhost`, but will need\nto be changed when working with multiple machines or containers.\n\n## 3. Run Setup Scripts\n\nFirst, create the HTTP and CA keys and certificates via `setup-ca.sh`.\n\nThis should only need to be **run once**, and, in fact, will require existing\ncerts to have to be removed manually before it can be run again:\n\n\u003e If you haven't set the hostname via the `CAHOSTNAME` environment variable,\n  and wish to use a hostname other than what the `hostname` command resolves\n  to, this script should be called with the hostname as the first parameter.\n  Run the script with `-h` for details.\n\n```bash\n$ ./setup-ca.sh\n```\n\nNext, setup the bootstrap key pair via `setup-bootstrap.sh`.\n\nThis key pair is required to authenticate with the CA server, and the data\nplaced in `bootstrap_crt.txt` and `bootstrap_key.txt` will need to be\nincluded in the client device, or included in any attempts to connect to the\nREST API using `curl`, `wget`, etc.\n\nThe script can be run multiple times (after removing the generated\nfiles), but only would need to be rerun after regenerating the CA\ncert.\n\n```bash\n$ ./setup-bootstrap.sh\n```\n\n## 4. Start the Server\n\nRun `run-server.sh` to start the CA server on port 1443, or whatever port you\nset in the config file:\n\n\u003e This script also accepts an optional hostname override as the first\n  parameter. Run the script with `-h` for details.\n\n```bash\n$ ./run-server.sh\n```\n\n## 5. Optional Steps\n\n### Generate Test Device(s)\n\nYou can optionally run `new-device.sh` to create a new device, and registers\nit with this CA.\n\nThe certificates for the device will be placed in the 'certs'\ndirectory, along with the certificates above.\n\n\u003e This certificate is only useful for testing the CA, and generally will not\n  be used in a production setting.\n\n\u003e This script also accepts an optional hostname override as the first\n  parameter. Run the script with `-h` for details.\n\n```bash\n$ ./new-device.sh\n```\n\n### Cleanup\n\nYou can remove all existing certificate artifacts via:\n\n```bash\n$ rm CADB.rb\n$ rm -rf certs\n```\n\n# REST API\n\nThe REST API is a **work in progress**, and may be changed in the future!\n\n## `/api/v1/cr` Certification Request: **POST**\n\nRequest a certificate for a new device, based on the provided certificate\nsigning request (CSR).\n\nThe CA will assign and record a unique serial number for this certificate,\nwhich can later be used to check the certificate status via the `cs/{serial}`\nendpoint.\n\n\u003e This API requires the `Content-Type` to be set on the post data, and must be\n  set to either `application/cbor` or `application/json`.  A request made in\n  cbor will have a cbor reply, json will reply with a json encoded response.\n\n### Request with `application/cbor`\n\nThe CSR payload should be wrapped in a single CBOR array:\n\n```cddl\n[ bstr ]\n```\n\n#### Example\n\nSee the `new-device.sh` script for an example of generating an appropriate\nrequest from the shell, and saving the response.\n\n#### Response\n\nReplies with a CBOR array containing the following fields:\n\n```cddl\n{\n   1 =\u003e int,   ; Status.\n   2 =\u003e bstr,  ; Certificate\n}\n```\n\n- `Status` is an error code where `0` indicates success, and non-zero values\nshould be treated as an error.\n- `Certificate` contains the BASE64-encoded DER format certificate.\n\n### Request with `application/json`\n\nTakes a **BASE64-encoded CSR payload in a JSON wrapper** as follows:\n\n```json\n{\n  \"CSR\":\"MIH9MIGlAgEAMEMxEjAQBgNVBAoMCWxvY2FsaG9zdDEtMCsGA1UEAwwkZThjNDdiNDItZjdmYy00ZGM4LWI1MzgtOTM0OTZiNjE5YTNjMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJ5aLGLJID8MVHCHEzQOlO63RvBaTy8lRbtkDODYPgDKBOuAHWXbytgjO32K8O282BK/Hl5eEKqcXcHerlxE2xKAAMAoGCCqGSM49BAMCA0cAMEQCIEFoH+NV9jXJA0PmctbCQ7FOBnE/aT9hmqBuvBq2kIhuAiAyKGAUIAzHDBZ+lY6WaJGh/56rzr4KprVtNYFGLHLs1g==\"\n}\n```\n\n\u003e :warning: The `CSR` field in the JSON request payload is a BASE64 encoded\n  byte array from a **DER file**. This paylaod doesn't include the text\n  headers present in the PEM files generated by\n  `openssl req -new -key UUID.key -out UUID.csr` in `new-device.sh`.\n\n#### Response\n\nReplies with a JSON array containing `Status`, and `Cert` fields:\n\n- `Status` is an error code where `0` indicates success, and non-zero values\nshould be treated as an error.\n- `Cert` contains the BASE64-encoded DER format certificate.\n\n```json\n{\n  \"Status\":0,\n  \"Cert\":\"MIIBtjCCAVugAwIBAgIIFrKA6WV+D5gwCgYIKoZIzj0EAwIwOjEUMBIGA1UEChMLTGluYXJvLCBMVEQxIjAgBgNVBAMTGUxpbmFyb0NBIFJvb3QgQ2VydCAtIDIwMjAwHhcNMjExMDI5MTI0MjM0WhcNMjIxMDI5MTI0MjM0WjBDMRIwEAYDVQQKEwlsb2NhbGhvc3QxLTArBgNVBAMTJGU4YzQ3YjQyLWY3ZmMtNGRjOC1iNTM4LTkzNDk2YjYxOWEzYzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABCeWixiySA/DFRwhxM0DpTut0bwWk8vJUW7ZAzg2D4AygTrgB1l28rYIzt9ivDtvNgSvx5eXhCqnF3B3q5cRNsSjQjBAMB0GA1UdDgQWBBSCv0wCNUXMXavfi15AbcCclDvfkzAfBgNVHSMEGDAWgBSxhUrvHyyKgHn5/FaoKd761df1tjAKBggqhkjOPQQDAgNJADBGAiEAjDVYvr1qBfvc0VFZcFLxwO/5XvnBh2jZFpL9ykKsCw8CIQDF3ne7yokRAHt0nn35CW/J3FclGYH9rBVCZr7FU+pzHg==\",\n}\n```\n\n## `/api/v1/p10cr` Certification Request from PKCS10: **POST**\n\nThis endpoint is used to request a certificate for a new device, posting a\nPKCS#10 CSR file in **PEM format**.\n\nThe CA will assign and record a unique serial number for this certificate,\nwhich can later be used to check the certificate status via the `cs/{serial}`\nendpoint.\n\nIt will reply with a certificate file in PEM format or a status error in JSON,\ndepending on the input CSR provided.\n\nTesting this endpoint with:\n\n\u003e The example belows assumes `MBP2021.lan` as the local hostname. This\n  value will vary from one machine to another.\n\n```bash\n$ curl -v --cacert certs/CA.crt  \\\n          --cert certs/BOOTSTRAP.crt \\\n          --key certs/BOOTSTRAP.key  \\\n          -F csrfile=@USER.csr       \\\n          --output USER.crt          \\\n          https://MBP2021.lan:1443/api/v1/p10cr\n```\n\nshould give you a `USER.crt` file in **PEM format**, which you can view via:\n\n```bash\n$ openssl x509 -in USER.crt -noout -text\n```\n\n## `api/v1/ds/{uuid}` Device Status Request: **GET**\n\nChecks if any valid certificates are associated with the specified device UUID.\nIf any valid certificates are found, their serial number will be returned in\nthe response payload.\n\nThis endpoint accepts requests in cbor (`application/cbor`) or json\n(`application/json`), defaulting to JSON responses if no Content-Type is\nprovided. The response Content-Type will match the request type used.\n\n### Request with `application/json`\n\n```bash\n$ curl -v --cacert certs/CA.crt  \\\n          --cert certs/BOOTSTRAP.crt \\\n          --key certs/BOOTSTRAP.key  \\\n          https://MBP2021.lan:1443/api/v1/ds/56d38f73-3f6f-4a59-86bc-d315a1ccc634\n```\n\n### Request with `application/cbor`\n\nYou can send a status request via:\n\n```bash\n$ curl -v --cacert certs/CA.crt  \\\n          --cert certs/BOOTSTRAP.crt \\\n          --key certs/BOOTSTRAP.key  \\\n          -H 'Content-Type: application/cbor' \\\n          https://MBP2021.lan:1443/api/v1/ds/56d38f73-3f6f-4a59-86bc-d315a1ccc634 \\\n          -o cbor_enc.raw\n```\n\n\u003e CBOR requests receive binary responses, which curl will print as an unknown \n  symbol on the console. Pass the `-o \u003cfilename\u003e` argument to store the binary \n  output in a file, and execute `go run cbor_decoder.go -i cbor_enc.raw -r ds`\n  to decode  the binary output response and print in the JSON format.\n\n### Responses\n\nThis endpoint will return the following responses, in JSON or CBOR encoding\ndepening on the `Content-Type` used:\n\n- HTTP response code **200**\n  - `{\"Status\":0,\"Serials\":null}`: No valid certs found for UUID\n  - `{\"Status\":1,\"Serials\":[1649073924922206000]}`: Valid cert(s) found for UUID\n- HTTP response code **400** + `{\"error\": \"\u003cerror msg\u003e\"}`, where error msg is:\n  - `need a valid UUID`: Invalid or improperly formatted UUID was provided\n  - `unable to query db for UUID`: error querying for database UUID (fatal)\n  - `bad request: Content-Type must be ...`: Invalid Content-Type provided\n\n## `api/v1/cs/{serial}` Certificate Status Request: **GET**\n\nRequests the certificate status based on the supplied certificate serial number.\n\nThe serial number is generated by the CA during the certificate generation\nprocess (`/ap1/v1/cr`), and is a unique timestamp-based 64-bit integer (ex.\n`1635511354607407000`) that is added to the certificate before sending it back\nto the requesting device.\n\nIt can be retrieved using the `/api/v1/ds/{uuid}` endpoint, or from a\ncertificate file directly via the serial number field, for example:\n\n\u003e The example belows assumes a specific device UUID, and `MBP2021.lan` as\n  the local hostname. These values will vary from one machine to another.\n\n```bash\n$ openssl x509 -in certs/a8c6f808-b659-4f88-affb-40498834c572.crt -noout -text\nCertificate:\n    Data:\n        Version: 3 (0x2)\n        Serial Number: 1648935985023194000 (0x16e2328abcaa9390)\n    Signature Algorithm: ecdsa-with-SHA256\n        Issuer: O=Linaro, LTD, CN=LRC - 20220330062226\n        Validity\n            Not Before: Apr  2 21:46:25 2022 GMT\n            Not After : Apr  2 21:46:25 2023 GMT\n        Subject: O=MBP2021.lan, OU=LinaroCA Device Cert - Signing, CN=a8c6f808-b659-4f88-affb-40498834c572\n        ...\n```\n\nOnce you have the serial number, you can send a status request via:\n\n### Request with `application/json` (default)\n\nYou can send a status request via:\n\n```bash\n$ curl -v --cacert certs/CA.crt  \\\n          --cert certs/BOOTSTRAP.crt \\\n          --key certs/BOOTSTRAP.key  \\\n          https://MBP2021.lan:1443/api/v1/cs/1648935985023194000\n```\n\n### Request with `application/cbor`\n\nYou can send a status request via:\n\n```bash\n$ curl -v --cacert certs/CA.crt  \\\n          --cert certs/BOOTSTRAP.crt \\\n          --key certs/BOOTSTRAP.key  \\\n          -H 'Content-Type: application/cbor' \\\n          https://MBP2021.lan:1443/api/v1/cs/1648935985023194000 \\\n          -o cbor_enc.raw\n```\n\n\u003e CBOR requests receive binary responses, which curl will print as an unknown \n  symbol on the console. Pass the `-o \u003cfilename\u003e` argument to store the binary \n  output in a file, and execute `go run cbor_decoder.go -i cbor_enc.raw -r cs`\n  to decode  the binary output response and print in the JSON format.\n\n### Responses\n\nThis endpoint will return the following responses, in JSON or CBOR depending\non the `Content-Type` used:\n\n- HTTP response code **200**\n  - `{\"status\": \"1\"}`: Indicates that the serial number exists, and that the\n    certificate is marked as **valid** in the CA database.\n  - `{\"status\": \"0\"}`: Indicates that the serial number exists, but that the\n    certificate is marked as **invalid** in the CA database (i.e., it has been\n    **revoked**).\n- HTTP response code **400** + `{\"error\": \"\u003cerror msg\u003e\"}`, where error msg is:\n  - `invalid request`: Poorly formatted serial number was provided\n  - `invalid serial number`: No certificate matching supplied serial found\n  - `bad request: Content-Type must be ...`: Invalid Content-Type provided\n\n## `api/v1/cc/{serial}` X509 Certificate Copy Request: **GET**\n\nRequests a copy of the x509 certificate associated with the supplied serial\nnumber. If found, the certificate data is returned in **PEM format** (BASE64\nASCII).\n\n\u003e See the `cs` endpoint for details on retrieving a certificate serial number.\n\n### Request with `application/json` (default)\n\nYou can send the x509 certificate copy request via:\n\n```bash\n$ curl -v --cacert certs/CA.crt  \\\n          --cert certs/BOOTSTRAP.crt \\\n          --key certs/BOOTSTRAP.key  \\\n          https://MBP2021.lan:1443/api/v1/cc/1664276589086394391\n```\n\n### Request with `application/cbor`\n\nYou can send the x509 certificate copy request via:\n\n```bash\n$ curl -v --cacert certs/CA.crt  \\          \n          --cert certs/BOOTSTRAP.crt \\\n          --key certs/BOOTSTRAP.key  \\\n          -H 'Content-Type: application/cbor' \\\n          https://MBP2021.lan:1443/api/v1/cc/1664276589086394391 \\\n          -o cbor_enc.raw\n```\n\n\u003e CBOR requests receive binary responses, which curl will print as an unknown \n  symbol on the console. Pass the `-o \u003cfilename\u003e` argument to store the binary \n  output in a file, and execute `go run cbor_decoder.go -i cbor_enc.raw -r cc`\n  to decode  the binary output response and print in the JSON format.\n\n### Response\n\nReplies with a JSON or CBOR array containing `Status`, and `Cert` fields:\n\n- `Status` is an error code where `0` indicates success, and non-zero values\nshould be treated as an error.\n- `Cert` contains the string type x509 pem format certificate.\n\nFor example, if the `Content-Type` is set to the default `application/json`:\n\n```json\n{\n  \"Status\":0,\n  \"Cert\":\"-----BEGIN CERTIFICATE-----\\nMIIB6TCCAY+gAwIBAgIIFxiyvXR+SBcwCgYIKoZIzj0EAwIwNTEUMBIGA1UEChML\\nTGluYXJvLCBMVEQxHTAbBgNVBAMTFExSQyAtIDIwMjIwOTI3MTEwMjE3MB4XDTIy\\nMDkyNzExMDMwOVoXDTIzMDkyNzExMDMwOVowfDEiMCAGA1UEChMZYXJtLXZpcnR1\\nYWwtbWFjaGluZS5sb2NhbDEnMCUGA1UECxMeTGluYXJvQ0EgRGV2aWNlIENlcnQg\\nLSBTaWduaW5nMS0wKwYDVQQDEyRjNTJmN2Y4NS04ZmYwLTQzOGQtOGEwNi05Mzlj\\nOWJlNTlhNGYwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAARrMDR1HgkP/ET4yNqG\\nM5km89r2DFAAKZDyL2lVg3C8sjNVrxoR73G7nhC8EyCFMwrIMK99O92tGFWOWqaM\\nb2r9o0IwQDAdBgNVHQ4EFgQUDBH9jc9zvi3un83TFPI/tHhMF8YwHwYDVR0jBBgw\\nFoAU+m+L2p3gV7JPexhVX6PFWMFy9cowCgYIKoZIzj0EAwIDSAAwRQIgM5zSdrUY\\n7f0QG3cq+5MVL/rAb4k4Ok6vQIE63zRwQt8CIQCsQ7NQV9Sk8y3YU0R3HGUlOOMI\\nKKmII4ZjIWrZs7Qr/A==\\n-----END CERTIFICATE-----\\n\"\n}\n```\n\n## `api/v1/ccs` Cloud Connectvity Settings: **GET**\n\nRequests the cloud connectivity details for the MQTT broker associated with\nyour cloud infrastructure.\n\nThis endpoint allows device to retrieve details about the MQTT broker, etc.,\nthat they should connect to, and is usually retrieved during the provisioning\nprocess, or when an alert is received by the client device that the cloud\nconnectivity settings have changed.\n\n### Request with `application/cbor`\n\nYou can send a status request via:\n\n```bash\n$ curl -v --cacert certs/CA.crt  \\\n          --cert certs/BOOTSTRAP.crt \\\n          --key certs/BOOTSTRAP.key  \\\n          -H 'Content-Type: application/cbor' \\\n          -H 'Accept: application/cbor' \\\n          https://MBP2021.lan:1443/api/v1/ccs \\\n          -o cbor_enc.raw\n```\n\n\u003e CBOR requests receive binary responses, which curl will print as an unknown \n  symbol on the console. Pass the `-o \u003cfilename\u003e` argument to store the binary \n  output in a file, and execute `go run cbor_decoder.go -i cbor_enc.raw -r ccs`\n  to decode  the binary output response and print in the JSON format.\n\n### Request with `application/json` (default)\n\nYou can send a status request via:\n\n```bash\n$ curl -v --cacert certs/CA.crt  \\\n          --cert certs/BOOTSTRAP.crt \\\n          --key certs/BOOTSTRAP.key  \\\n          https://MBP2021.lan:1443/api/v1/ccs\n```\n\n### Response\n\nReplies with a JSON array containing the following fields:\n\n```json\n{\n  \"Hubname\":\"azure_hubname\",\n  \"Port\":8883\n}\n```\n\n- `Hubname` contains the Azure IoT Hub hubname string.\n- `Port` contains the Azure IoT Hub MQTT port number.\n\n## `api/v1/kur` Key Update Request: **POST** (TODO)\n\nRequest an update to an existing (non-revoked and non-expired) certificate. An\nupdate is a replacement certificate containing either a new subject public\nkey or the current subject public key.\n\n## `api/v1/krr` Key Revocation Request: **POST** (TODO)\n\nRequests the revocation of an existing certificate registration.\n\n# Mutual TLS Test Server\n\nA secondary TCP server is started up along with the main CA server to test\nmutual TLS authentication using client certificates.\n\nmutual TLS authentication requests a certificate from the connecting client\ndevice that has been signed with the CA, adding an additional level of trust\non behalf of the server concerning the client device.\n\n### Using a CA-signed client certificate\n\nOnce a user certificate has been generated (via `new-device.sh`), you can test\nmTLS connections via:\n\n\u003e The example belows assumes a specific device UUID, and `MBP2021.lan` as\n  the local hostname. These values will vary from one machine to another.\n\n```bash\n$ openssl s_client \\\n  -cert certs/f269528d-ff66-4fb0-83d8-e449e0038010.crt \\\n  -key certs/f269528d-ff66-4fb0-83d8-e449e0038010.key \\\n  -CAfile certs/CA.crt \\\n  -connect MBP2021.lan:8443\n```\n\n- The `cert` and `key` fields indicate the client certificate and key\n- The `CAfile` field is the CA certificate\n\nIf the connection is successful, you should get the following response\nat the end of the outptut:\n\n```\nVerify return code: 0 (ok)\n```\n\nAnd liteboot will display details about the client cert in the log output:\n\n```bash\n$ ./liteboot server start\nStarting mTLS TCP server on MBP2021.lan:8443\nStarting CA server on port https://MBP2021.lan:1443\nConnection accepted from 127.0.0.1:60510\n[Certificate 0]\n  - Subject: CN=f269528d-ff66-4fb0-83d8-e449e0038010,OU=Signing,O=Linaro\\, LTD\n  - Serial:  1671014018808547000\n[Certificate 1]\n  - Subject: CN=LRC - 20221129052020,O=Linaro\\, LTD\n  - Serial:  2022001129172020\n```\n\n- `Certificate 0` is the device certificate\n- `Certificate 1` is the CA certificate used to sign certificate 0.\n\n### Using an invalid client certificate\n\nTo test with an **invalid user certificate**, generate a new cert:\n\n```bash\n$ openssl ecparam -name prime256v1 -genkey -out USERBAD.key\n$ openssl req -new -x509 -sha256 -days 365 \\\n  -key USERBAD.key -out USERBAD.crt \\\n  -subj \"/O=Linaro, LTD/CN=MBP2021.lan\"\n```\n\nThen try the request again:\n\n```bash\n$ openssl s_client \\\n  -cert USERBAD.crt -key USERBAD.key \\\n  -CAfile certs/CA.crt \\\n  -connect MBP2021.lan:8443\n```\n\nYou should get the following error from liteboot, since the device certificate\nhas not been signed by our CA:\n\n```\nConnection accepted from 127.0.0.1:50443\nClient handshake error: tls: failed to verify client certificate: x509: certificate signed by unknown authority\n```\n\n# Troubleshooting\n\n## FAQs\n\n### `setup-bootstrap.sh` causes `Can't load /home/user/.rnd into RNG`\n\nRun `openssl rand -writerand .rnd` to generate the missing .rnd file.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flinaro%2Flite_bootstrap_server","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flinaro%2Flite_bootstrap_server","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flinaro%2Flite_bootstrap_server/lists"}