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

Server Side Keygen Endpoint returns a private key that is incorrectly encoded #89

Open
JamesGibo opened this issue Sep 28, 2020 · 2 comments

Comments

@JamesGibo
Copy link

When requesting a certificate using the Server Side Key Generation API, the certificate returned in the multipart request is correct and can be decoded to a PEM certificate, however the private key is unable to be decoded.

After some debugging I have been unable to find the issue, before the private key is PKCS8 encoded it is correct, but after the encoding I am unable to decode the certificate using openssl.

@rpb5bnc
Copy link
Contributor

rpb5bnc commented Sep 28, 2020

Hi James,

The SSKG processing within libest's client function performs a validation of the key pair as a sanity test upon receiving it from the server. When we run our internal tests we do not see this sanity test failing. I'm not saying there isn't a possible problem in the code, but it would seem that this sanity test passing would seem to indicate that the keypair can be parsed and processed by OpenSSL. An example of this would be in test/UT/US4752/us4752.c:us4752_test1(). This test performs a SSKG and at the end of the processing within the library there is a call to est_client_verify_key_and_cert() . I believe the call to SSL_CTX_check_private_key() would fail if the private key and cert could not be properly parsed. Consider looking at this code for comparison to what your code is doing in preparation for calling into OpenSSL.

Regards,
Pete

@JamesGibo
Copy link
Author

Thanks for the pointers, I will look into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants