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

rename the TLS_CREDENTIAL_SERVER_CERTIFICATE enum to more appropriate name to indicate either Server or client public certificate in the TLS credential subsystem #87330

Closed
VivekUppunda opened this issue Mar 19, 2025 · 1 comment · Fixed by #87341
Assignees
Labels
area: Networking Enhancement Changes/Updates/Additions to existing features

Comments

@VivekUppunda
Copy link
Contributor

Currently the enum values defined for tls_credential_type mention TLS_CREDENTIAL_SERVER_CERTIFICATE for public server certificate.

Either an enum value for client certificate be added or rather make the current enum value TLS_CREDENTIAL_SERVER_CERTIFICATE be renamed to a more appropriate name to indicate public certificates in general.

@VivekUppunda VivekUppunda added the Enhancement Changes/Updates/Additions to existing features label Mar 19, 2025
@rlubos rlubos self-assigned this Mar 19, 2025
@rlubos
Copy link
Contributor

rlubos commented Mar 19, 2025

I agree TLS_CREDENTIAL_SERVER_CERTIFICATE name is unfortunate, it implies server however in reality it doesn't really make difference if the public ceriticate is registered for a client or server device. Even in current codebase we use this credential type to in fact store client certificate (like for example in LwM2M, cc @SeppoTakalo):

ret = load_tls_type(ctx, 3, TLS_CREDENTIAL_SERVER_CERTIFICATE);

I propose we deprecate this name, and rename it to TLS_CREDENTIAL_PUBLIC_CERTIFICATE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Networking Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants