Also, be sure to check the Codesys Security Screen package, as it can also generate certificates for various purposes.
I don't know if they can be utilised for MQTT certificates though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The security screen cannot, but the security agent can (they sound so similar!) https://store.codesys.com/codesys-security-agent.html
For me though, logging in to 50 controllers and remembering what all the buttons are for your particular server is too slow.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
--- old+++ new@@ -1,2 +1,45 @@-The user should be able to give their own certificate (hCert) if they wish.-And as an alternative, they should also have a helper function, to self generate a certificate suitable for use for a particular MQTT broker type.+TODO: How to get trusted certificates in there? i.e. AWS's public certificates+TODO: Update with pictures of UI+TODO: renew certificate when it expires+# Three CODESYS applications:+On three seperate devices:+* EoN Node+* SCADA / IIoT Host+* Authenticator++### EoN Node+check if he has a private key yet. If not, generate a private key and CSR. +check if he has a Certificate yet. If not check if he has a CSR yet. If notgenerate a CSR.+The CSR is not a secret, so publish the text of the CSR on a visualization.+have a text entry field on the visu to receive the signed certificate and install it for use.++CODESYS Lib: CmpX509Cert+CODESYS Example project: CryptoCertDemo++### SCADA / IIoT Host +check if he has a private key yet. If not, generate a private key and CSR. +check if he has a Certificate yet. If not check if he has a CSR yet. If notgenerate a CSR.+The CSR is not a secret, so publish the text of the CSR on a visualization.+have a text entry field on the visu to receive the signed certificate and install it for use.++### Authenticator+Authenticator's only job is to take Certificate Signing Requests, and send them to AWS to register the device.+Interface: +3 text fields, same for all nodes / hosts:+* copy and paste your super secret amazon API key (from AWS)+* copy and paste the AWS arn (copy it from AWS)+* copy and paste the sparkplugB group_id++then for each MQTT Client:+* copy and paste the text of the csr+* copy and paste the EoN Node name or SCADA / IIoT Host name (user's responsibility to assign unique names. AWS will probably give an error, if you assign a duplicate name)+* select wether EoN Node or SCADA / IIoT Host (OR BOTH!)+* Hit "register"+* This info is then sent via this API, which returns the signed public certificate:+https://docs.aws.amazon.com/iot/latest/apireference/API_RegisterThing.html+https://docs.aws.amazon.com/iot/latest/developerguide/provision-template.html#bulk-template-example+* will display the response from AWS (eg. SUCCESS)++Note: it would be trivial to add application node, (same as SCADA / IIoT, but accept a list of allowed Nodes to read from, allowed nodes to write from, and whether it is allowed to publish its state)++Note: I am not a security expert, so this implementation will need to be risk assessed for suitability in what the user wants to run it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
--- old+++ new@@ -1,3 +1,5 @@+**Initial implementation will be suitable for an AWS IoT Core MQTT, but can be expanded as needed.**+
TODO: How to get trusted certificates in there? i.e. AWS's public certificates
TODO: Update with pictures of UI
TODO: renew certificate when it expires
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think we have two options to provide user certificates;
1) Let the user embed a certificate into the compiled application itself (so enclosed as WSTRING variable "blob" )
2) Let the application search for the correct files on a drive (a path with a filename).
Both scenario's have their specific pro's and con's so maybe we should offer the user BOTH options as a choice?
PS I'd recommend only to read these certificates and not provide tooling to generate them. There are hundreds of alternatives out there to generate private key/public key pairs and CA root / private / public certificates.
Once generated via the preffered method of choice the user can either embed the file into the project as variables (a WSTRING should do via C/P) or we pick it up via a file open/read.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
https://store.codesys.com/crypto-example.html
Also, be sure to check the Codesys Security Screen package, as it can also generate certificates for various purposes.
I don't know if they can be utilised for MQTT certificates though.
The security screen cannot, but the security agent can (they sound so similar!) https://store.codesys.com/codesys-security-agent.html
For me though, logging in to 50 controllers and remembering what all the buttons are for your particular server is too slow.
Diff:
Diff:
I think we have two options to provide user certificates;
1) Let the user embed a certificate into the compiled application itself (so enclosed as WSTRING variable "blob" )
2) Let the application search for the correct files on a drive (a path with a filename).
Both scenario's have their specific pro's and con's so maybe we should offer the user BOTH options as a choice?
PS I'd recommend only to read these certificates and not provide tooling to generate them. There are hundreds of alternatives out there to generate private key/public key pairs and CA root / private / public certificates.
Once generated via the preffered method of choice the user can either embed the file into the project as variables (a WSTRING should do via C/P) or we pick it up via a file open/read.
Implemented, but "Authenticator" functionality will be moved to new project.