Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certificate generation, incompatible aliases #250

Open
jara001 opened this issue Aug 3, 2020 · 1 comment
Open

Certificate generation, incompatible aliases #250

jara001 opened this issue Aug 3, 2020 · 1 comment
Labels
5.0 Arrowhead 5.0 enhancement New feature or request

Comments

@jara001
Copy link

jara001 commented Aug 3, 2020

Hello,
certificate generation script (https://github.com/arrowhead-f/core-java-spring/blob/f899985e9b990bea3cc47d04300e9bf12d8d74ce/scripts/certificate_generation/lib_certs.sh) creates certificates with full name in its alias (e.g. event_handler.cloud.company.arrowhead.eu), instead of the "short name" (i.e. event_handler).

Default configuration script for Docker (e.g. https://github.com/arrowhead-f/core-java-spring/blob/f899985e9b990bea3cc47d04300e9bf12d8d74ce/docker/core_system_config/eventhandler.properties) expects this value to hold only the service name (i.e. event_handler).

Currently, there are two options:

  1. Edit the generation script to use only the short name.
  2. Edit the configuration scripts to expect full name in the alias.

I guess that the first one should be the right way, as the field should hold an "alias".

J.

@emanuelpalm
Copy link

@jara001 I believe you are touching on an important issue here, which is that there is currently no Arrowhead X.509 profile ("standard") for certificate specification.

However, if looking in the Certificate Section Markdown documentation and in the Keystore Explorer Certificate Creation Guide, you can tell that the full name should be specified as Common Name in the certificate. Also, while the Docker configuration files only specify the last part of the full name, the other parts are derived from their certificates when they start up.

@tsvetlin @jerkerdelsing There seems to me that there is some reluctance to standardize things within this project, as Arrowhead is being promoted as "not being a standard", if my understanding is correct. I believe this comes from the idea that there are enough standards already, and that Arrowhead should be the glue that brings them all together, rather than trying to compete with them. While I agree to the sentiment that we should not strive to compete with existing standards when possible, I think we are fooling ourselves if we think that no standardization will be needed at all. What we are creating is fundamentally new, and if there are no conventions, surrounding things such as X.509 certificate usage, interoperability is going to be difficult in practice.

As far as I can tell, we can go two routes when it comes to X.509 certificates:

  1. Write our own X.509 profile, which specifies what Distinguished Name fields to use, what extensions may be used, and so on (see here and here for two examples of such profiles).
  2. Never depend directly on the contents of a certificate, be it a X.509 certificate or otherwise. Instead, we associate system, service and device data with certificate hashes (a.k.a. certificate fingerprints). While this option might seem more attractive, it means less information of relevance is digitally signed by the system in question, which might have implications further down the line. What those implications would be are not clear to me, however.

@tsvetlin tsvetlin added 5.0 Arrowhead 5.0 enhancement New feature or request labels Mar 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
5.0 Arrowhead 5.0 enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants