issue-228: resolved default 1024 bit length on certificate #236
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Per Optic issue 228 the proxy currently fails on Debian latest. The issue is the certificate: the self-signed CA is 2048 bits, but the site certificate is 1024 (RSA). The CA key length was specified, but not the host certificate, and it appears that the underlying library assumes 1024 if nothing is passed.
I set the key length equal to both with a new variable. It may not be idiomatic, feedback welcome. Tested locally with
apidev, rantestssl.shto document results as well. Made the change in the Node packages on a test Debian latest VM as well (conceit: a single line key set instead of adding the variable and refactoring the CA specification as well) and now the proxy runs and can pass traffic.I used a variable to make sure that in the future a single key length update will be sufficient for both certificates. NIST says 2048's good through 2030, and it's taken 5-10 years after 1024 was deprecated before software started rejecting it, but I'm feeling optimistic.