Documentation update

Fixes eclipse#659

Also clarifies jwt token naming for server and
need to specify servername for tls

data/vss-core/README.md

@@ -39,7 +39,7 @@ This is the process for introducing support for a new VSS version:
 * If needed, adapt or extend test cases to use the new version instead of previous version
 * Remember to also integrate new version in [KUKSA Feeder](https://github.com/eclipse/kuksa.val.feeders) repository
     * Needed for [dbc2val](https://github.com/eclipse/kuksa.val.feeders/blob/main/dbc2val/mapping/mapping.md)
-    * Needed for [dds2val](https://github.com/eclipse/kuksa.val.feeders/blob/main/dds2val/ddsproviderlib/idls/generate_py_dataclass.sh) 
+    * Needed for [dds2val](https://github.com/eclipse/kuksa.val.feeders/blob/main/dds2val/ddsproviderlib/idls/generate_py_dataclass.sh)
 
 ### Release Candidate Handling
 
@@ -108,12 +108,12 @@ Test Client> getValue Vehicle.CurrentLocation.Longitude
 
 ### Kuksa-val-server and dbc2val smoke test
 
-Run dbc2val as described in [documentation](https://github.com/eclipse/kuksa.val.feeders/blob/main/dbc2val/Readme.md) using example [dump file](https://github.com/eclipse/kuksa.val.feeders/blob/main/dbc2val/candump.log). Verify that no errors appear in kuksa-val-server log. Not all signals in the [mapping files](https://github.com/eclipse/kuksa.val.feeders/blob/main/dbc2val/mapping/) are used by the example dump file, but it can be verified using Kuksa Client that e.g. `Vehicle.Speed` has been given a value.
+Run dbc2val as described in [documentation](https://github.com/eclipse/kuksa.val.feeders/blob/main/dbc2val/README.md) using example [dump file](https://github.com/eclipse/kuksa.val.feeders/blob/main/dbc2val/candump.log). Verify that no errors appear in kuksa-val-server log. Not all signals in the [mapping files](https://github.com/eclipse/kuksa.val.feeders/blob/main/dbc2val/mapping/) are used by the example dump file, but it can be verified using Kuksa Client that e.g. `Vehicle.Speed` has been given a value.
 
 
 ### Kuksa-val-server and gps2val smoke test
 
-Run gps2val as described in [documentation](https://github.com/eclipse/kuksa.val.feeders/blob/main/gps2val/readme.md) using example log. If gpsd already is running at port 2947 a different port like 2949 may be used. Then [gps2val config file](https://github.com/eclipse/kuksa.val.feeders/blob/main/gps2val/config/gpsd_feeder.ini) must also be updated to use that port. If device handling does not work on test platform `-t` can be used to uss TCP instead.
+Run gps2val as described in [documentation](https://github.com/eclipse/kuksa.val.feeders/blob/main/gps2val/README.md) using example log. If gpsd already is running at port 2947 a different port like 2949 may be used. Then [gps2val config file](https://github.com/eclipse/kuksa.val.feeders/blob/main/gps2val/config/gpsd_feeder.ini) must also be updated to use that port. If device handling does not work on test platform `-t` can be used to uss TCP instead.
 
 ```
 gpsfake -t -P 2949 simplelog_example.nmea
@@ -164,4 +164,3 @@ Run dbc2val as described in [documentation](https://github.com/eclipse/kuksa.val
 ./dbcfeeder.py --usecase databroker --address=127.0.0.1:55555
 ```
 Verify that no errors appear in kuksa-val-server log. Not all signals in the [mapping files](https://github.com/eclipse/kuksa.val.feeders/blob/main/dbc2val/mapping) are used by the example dump file, but it can be verified using Kuksa Client that e.g. `Vehicle.Speed` has been given a value.
-

kuksa_certificates/README.md

@@ -10,7 +10,7 @@ This directory contain a set of example certificates, used by the KUKSA-project
 They may or may not be useful for your test environment.
 If needed you can customize `genCerts.sh` and generate keys and certificates that fits your environment.
 
-See the [KUKSA.val TLS documentation](../tls.md) for general information on the KUKSA.val TLS concept.
+See the [KUKSA.val TLS documentation](../doc/tls.md) for general information on the KUKSA.val TLS concept.
 
 This directory contains the following files with cryptographical information.
 
@@ -20,7 +20,7 @@ This directory contains the following files with cryptographical information.
 | `CA.pem` | Root certificate, valid for 3650 days ( 10 years). |
 | `Server.key` | Server key, needed by KUKSA.val Databroker/Server for TLS. |
 | `Server.pem` | Server certificate chain, valid for 365 days, needed by KUKSA.val Databroker/Server for TLS. |
-| `CLient.key` | Client key, currently not needed as mutual authentication is not supported. |
+| `Client.key` | Client key, currently not needed as mutual authentication is not supported. |
 | `Server.pem` | Client certificate chain, valid for 365 days, currently not needed as mutual authentication is not supported. |
 
 If the certificates have expired or you by any other reason need to regenerate keys or certificates you can use

kuksa_certificates/jwt/README.md

@@ -0,0 +1,21 @@
+# KUKSA Server JWT Tokens
+
+This directory contains example tokens for communication with the KUKSA Server.
+Corresponding tokens for Databroker can be found [here](../../jwt).
+
+The script [createToken.py](createToken.py) can be used to generate new tokens if needed.
+
+For historical reasons KUKSA Server tokens use a different pattern for token names.
+If you generate new tokens for KUKSA Server you must first run the script and then rename the generated token.
+
+## Example: Re-generate token with new expiry date
+
+The current example tokens expire at 2025-12-31. To generate new ones you must first add a new expiry date in
+the corresponding `*.json files. Then do:
+
+```
+./createToken.py single-read.json
+mv single-read.token single-read.json.token
+```
+
+*Note: The renaming is only needed for KUKSA Server tokens, not for KUKSA Databroker tokens!*