Please do not report security vulnerabilities here. The Responsible Disclosure Program details the procedure for disclosing security issues.
Thank you in advance for helping us to improve this library! Please read through the template below and answer all relevant questions. Your additional work here is greatly appreciated and will help us respond as quickly as possible. For general support or usage questions, use the Auth0 Community or Auth0 Support. Finally, to avoid duplicates, please search existing Issues before submitting one here.
By submitting an Issue to this repository, you agree to the terms within the Auth0 Code of Conduct.
Provide a clear and concise description of the issue, including what you expected to happen.
Detail the steps taken to reproduce this error, what was expected, and whether this issue can be reproduced consistently or if it is intermittent.
Where applicable, please include:
- Code sample to reproduce the issue
- Log files (redact/remove sensitive information)
- Application settings (redact/remove sensitive information)
- Screenshots
Please provide the following:
I have the same issue.
please give me solution if you have
I have the same issue. you must use default algorithm (HS256) for now.
@taylankarakas
I've hidden your suggestion. The point behind using an RS private key is so that noone but you can produce the signatures but everyone with the knowledge of your public key can verify it. HS256 is an HMAC based symmetric key (secret) algorithm and you'd be using the octets of malformed private key as the shared symmetric secret. DON'T DO THAT.
error:0909006C:PEM routines:get_name:no start line
How to fix it? Provide a properly formatted pkcs8, pkcs1, or sec1 PEM private key. That's really it.
Create JWT Token using the command shown here. This most probably will fix the issue.
Also don't miss the openssl command, it's important, else you might get an error - https://github.com/auth0/node-jsonwebtoken/issues/68#issuecomment-128114527
For us we had this issue while loading a private key from ENV instead of files (because of automated deployment in aws).
We fixed it by replacing \n in the env var with real line breaks
process.env.JWT_PRIVATE_KEY.replace(/\\n/gm, '\n')
Hope this helps someone
Continuing with @derN3rd 's answer, I had to approach this slightly differently.
For me, I was storing my private rsa key in a Gitlab CI/CD environment variable, which I was then reading into a file (this file was then read by the code I was testing).
touch priv_key.pem
echo "$MY_PRIV_KEY_ENV_VARIABLE" > priv_key.pem
Where I was going wrong was in the echo statement. As you see above, I am surrounding the environment variable with double-quotes. This is significant because by surrounding the variable with double-quotes, it preserves the \n character in the private key.
When I was just using the statement echo $MY_PRIV_KEY_ENV_VARIABLE > priv_key.pem, it was adding spaces where the \n character was and causing the error mentioned in this issue error:0909006C:PEM
For us we had this issue while loading a private key from ENV instead of files (because of automated deployment in aws).
We fixed it by replacing \n in the env var with real line breaks
process.env.JWT_PRIVATE_KEY.replace(/\\n/gm, '\n')Hope this helps someone
Very useful, tks.
Just to add a bit of clarification to @derN3rd 's solution, which is great btw, adding \ns to the env variable is a necessary step, prior to replacing them on the client side.
I also did not use quotes to surround the value.
Something like this:
-----BEGIN PRIVATE KEY-----\nLONG_STRING_HERE\n-----END PRIVATE KEY-----
i mean if we validate the file's contents with openssl then there must be some other problem going on?
For Windows users with PowerShell and OpenSSL.Light installed who needs to extract everything between ----BEGIN CERTIFICATE----- and ----END CERTIFICATE-----:
openssl s_client -showcerts -connect YourWebsite:port | Select-String -Pattern '-----BEGIN' -Context 0,21 | Foreach { $_ -replace " ", ""} | Foreach { $_ -replace "> ", ""} | Foreach { $_ -replace "/\\n/gm", "\n" } | Set-Content 'OutputFile.crt'
I got this because I was accidentally signing with my public key 🤦♀️
For us we had this issue while loading a private key from ENV instead of files (because of automated deployment in aws).
We fixed it by replacing \n in the env var with real line breaks
process.env.JWT_PRIVATE_KEY.replace(/\\n/gm, '\n')Hope this helps someone
I selected every reaction. This helped me so so so much. THANK YOU @derN3rd
Just to add a bit of clarification to @derN3rd 's solution, which is great btw, adding
\ns to the env variable is a necessary step, prior to replacing them on the client side.I also did not use quotes to surround the value.
Something like this:
-----BEGIN PRIVATE KEY-----\nLONG_STRING_HERE\n-----END PRIVATE KEY-----
Right, thank you, that clarification helped.
In our case I saved it this way in a Bitbucket repo variable and then was able to create the file in a Bitbucket pipeline since echo -e will interpret the \n, i.e.
- echo -e $JWT_KEY > build/keys/server.key
For us we had this issue while loading a private key from ENV instead of files (because of automated deployment in aws).
We fixed it by replacing \n in the env var with real line breaks
process.env.JWT_PRIVATE_KEY.replace(/\\n/gm, '\n')Hope this helps someone
For me it did not work in Google Cloud Platform Cloud Functions. Deploy works but function crashes with the error code.
I got tired of the error so I use a javascript string litteral and copy pasted my private key there instead of the process.env variable
Try this:
iconv -c -f UTF8 -t ASCII myprivate.key >> myprivate.key
Converting from utf-8 to ASCII made it work for me 😄
ref: https://stackoverflow.com/questions/43729770/nginx-godaddy-ssl
I was placing the key and crt interchangeably. So placing it rightly solve mine.
I accidentally exchanged private key and certificate.
Most helpful comment
For us we had this issue while loading a private key from ENV instead of files (because of automated deployment in aws).
We fixed it by replacing \n in the env var with real line breaks
process.env.JWT_PRIVATE_KEY.replace(/\\n/gm, '\n')Hope this helps someone