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

EST ID and Device ID certificates default to using different key types #403

Open
AlexN-SFV opened this issue Apr 29, 2022 · 2 comments · May be fixed by #447
Open

EST ID and Device ID certificates default to using different key types #403

AlexN-SFV opened this issue Apr 29, 2022 · 2 comments · May be fixed by #447
Labels
bug Something isn't working

Comments

@AlexN-SFV
Copy link

I'm setting up my service to use dps provisioning using x509 certificates from an est server using an est bootstrap certificate.
I noticed that the est id certificate keys are hard coded to use 256 bit EC keys by default, but the device id certificate is set to use 2048 bit RSA keys.

Some("ec-p256:rsa-4096:*"),

.create_key_pair_if_not_exists(identity_pk, Some("rsa-2048:*"))

It would be nice if they were consistent so I didn't have to configure my EST server to handle both types of certificate signing requests, or even better if there was somewhere in the configuration where the preferred algorithms for these keys could be set.

@arsing
Copy link
Member

arsing commented Apr 29, 2022

Hmm, both of those are wrong, actually. They should both be ec-p256:rsa-2048:*

@arsing arsing added the bug Something isn't working label Apr 29, 2022
@AlexN-SFV
Copy link
Author

Now in the latest version, since the EST ID keys are summarily deleted before attempting to get an EST certificate, I can't even choose the algorithm by pre-generating the EST ID keys, as I was doing before.
This is very frustrating.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants