I've got a .env file with public/private multiline keys in it, but only some keys are parsing. While the PUBLIC_KEY variable parses correctly with the dotenv package, PRIVATE_KEY is parsed as '-----BEGIN RSA PRIVATE KEY-----.
We've tried swapping their positions in the file, swapping their values, but nothing we do changes the way the file parses--regardless of how we change the file, the PUBLIC_KEY alone parses correctly.
PUBLIC_KEY='-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAuEdNotdGbDKZO1o7oATA
...
BvnP5uVCRrHigT1b8kvpJ/ptVw3hy2yE9h6V0Lolqq8XJ4kydLrOym5fVCdQlGBV
a9R7j5Z/03IUU34BwHNy648CAwEAAQ==
-----END PUBLIC KEY-----
'
PRIVATE_KEY='-----BEGIN RSA PRIVATE KEY-----
MIIJKQIBAAKCAgEAuEdNotdGbDKZO1o7oATAn6PsIoN3DhVLAZBDjg2JZ54ZDVc/
...
jUId69Z3cNk9QM2q0y26qo8uhEZ+yHCkxC3tBfWJ45YrP+Mj3FsPR044rhmu
-----END RSA PRIVATE KEY-----
'
We've got a working solution to manually input line breaks into the remaining keys, but we're still curious if anyone knows what could be causing this.
Thank you!
Related
I have a next.js application where I have a local .pem file for JWT public/private key authentication. My host does not allow me to upload secret files, so I am trying to access the .pem from a muli-line string .env variable.
I have the contents of the .pem stored like this:
PUB_KEY="-----BEGIN RSA PUBLIC KEY----- [newline]
YTuFE/BOU+pF6T2nYuyYQugqJHUZ62b3LJAeZYyBIjW+LZLeHGkUOZfqHnwSbmd9[newline]
isMbGtdNN/wujOftX1GSDApHX0LyNb+covtN4X4mcFFqyKuotFftUjOLzvb2AeJe[newline]
s9285pXbhAKVcStyAn26pI5...[newline]
-----END RSA PUBLIC KEY-----"
I get the error: Error, secretOrPrivateKey must be an asymmetric key when using RS256
I have tried to convert the .env variable from a multi line string to a single line string, preserving the newlines with this function:
function makeSingleLineKey(key) {
return key.replace(/(\r\n|\n|\r)/gm, '\\n');
}
but I get the same error.
There is an issue with the formatting of the .pem key I think.
Any ideas what might be going wrong?
Thanks
I was able to fix this by storing the .pem files in .env variables where the multi line strings were converted to a single line with the \n line breaks preserved e.g.
`LOCAL_AUTH_PUB_KEY={"PUB_KEY":"-----BEGIN RSA PUBLIC KEY-----\nMIICCgKCAgEAyLKk4ldt/a9dItmU2GkCVUJ1nTIh137JLTGLVyfPHkBaEBpMSm0j\nYT...`
I then accessed the variables in my code like this:
const { PUB_KEY } = JSON.parse(process.env.LOCAL_AUTH_PUB_KEY)
https://dev.to/cfofiu/how-to-store-a-long-private-key-in-vercel-s-environment-variables-46f5
I am trying to solve the CTF challenges at overthewire and have completed up to 16 levels
To get from level 16 to 17 you have to send the password of the current level to the port supporting SSL on localhost after submitting the password an ssh private key is given to log to the next level
I have done up to here and have successfully got the ssh key save it in a text file changed permission to 600 but whenever I am trying to use this key to log in to the next level I am prompted to give the passphrase for the key I have been stuck here for a long time how I can provide the passphrase since while creating the key there was nothing to set the passphrase
When you send the correct password, you should get the following key:
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvmOkuifmMg6HL2YPIOjon6iWfbp7c3jx34YkYWqUH57SUdyJ
imZzeyGC0gtZPGujUSxiJSWI/oTqexh+cAMTSMlOJf7+BrJObArnxd9Y7YT2bRPQ
Ja6Lzb558YW3FZl87ORiO+rW4LCDCNd2lUvLE/GL2GWyuKN0K5iCd5TbtJzEkQTu
DSt2mcNn4rhAL+JFr56o4T6z8WWAW18BR6yGrMq7Q/kALHYW3OekePQAzL0VUYbW
JGTi65CxbCnzc/w4+mqQyvmzpWtMAzJTzAzQxNbkR2MBGySxDLrjg0LWN6sK7wNX
x0YVztz/zbIkPjfkU1jHS+9EbVNj+D1XFOJuaQIDAQABAoIBABagpxpM1aoLWfvD
KHcj10nqcoBc4oE11aFYQwik7xfW+24pRNuDE6SFthOar69jp5RlLwD1NhPx3iBl
J9nOM8OJ0VToum43UOS8YxF8WwhXriYGnc1sskbwpXOUDc9uX4+UESzH22P29ovd
d8WErY0gPxun8pbJLmxkAtWNhpMvfe0050vk9TL5wqbu9AlbssgTcCXkMQnPw9nC
YNN6DDP2lbcBrvgT9YCNL6C+ZKufD52yOQ9qOkwFTEQpjtF4uNtJom+asvlpmS8A
vLY9r60wYSvmZhNqBUrj7lyCtXMIu1kkd4w7F77k+DjHoAXyxcUp1DGL51sOmama
+TOWWgECgYEA8JtPxP0GRJ+IQkX262jM3dEIkza8ky5moIwUqYdsx0NxHgRRhORT
8c8hAuRBb2G82so8vUHk/fur85OEfc9TncnCY2crpoqsghifKLxrLgtT+qDpfZnx
SatLdt8GfQ85yA7hnWWJ2MxF3NaeSDm75Lsm+tBbAiyc9P2jGRNtMSkCgYEAypHd
HCctNi/FwjulhttFx/rHYKhLidZDFYeiE/v45bN4yFm8x7R/b0iE7KaszX+Exdvt
SghaTdcG0Knyw1bpJVyusavPzpaJMjdJ6tcFhVAbAjm7enCIvGCSx+X3l5SiWg0A
R57hJglezIiVjv3aGwHwvlZvtszK6zV6oXFAu0ECgYAbjo46T4hyP5tJi93V5HDi
Ttiek7xRVxUl+iU7rWkGAXFpMLFteQEsRr7PJ/lemmEY5eTDAFMLy9FL2m9oQWCg
R8VdwSk8r9FGLS+9aKcV5PI/WEKlwgXinB3OhYimtiG2Cg5JCqIZFHxD6MjEGOiu
L8ktHMPvodBwNsSBULpG0QKBgBAplTfC1HOnWiMGOU3KPwYWt0O6CdTkmJOmL8Ni
blh9elyZ9FsGxsgtRBXRsqXuz7wtsQAgLHxbdLq/ZJQ7YfzOKU4ZxEnabvXnvWkU
YOdjHdSOoKvDQNWu6ucyLRAWFuISeXw9a/9p7ftpxm0TSgyvmfLF2MIAEwyzRqaM
77pBAoGAMmjmIJdjp+Ez8duyn3ieo36yrttF5NSsJLAbxFpdlc1gvtGCWW+9Cq0b
dxviW8+TFVEBl1O4f7HVm6EpTscdDxU+bCXWkfjuRb7Dy9GOtt9JPsX8MBTakzh3
vBgsyi/sN3RqRBcGU40fOoZyfAMT8s1m/uYv52O6IgeuZ/ujbjY=
-----END RSA PRIVATE KEY-----
You should copy this to your local computer, and save it as a file called bandit.key (name doesn't really matter). Then you should chmod 600 bandit.key, then ssh with the keyfile with the command:
ssh -i bandit.key bandit17#bandit.labs.overthewire.org -p 2220
Which should log you in.
I almost lost it with this one, but just logged in, had the same problem as the author, tried changing it to chmod 400 then 600 still had the same problem. What worked was copying the the key from the comment above, I suspect the "<" symbol in front of every line when copying from the terminal was somehow interfering with this.
Using this library..
https://github.com/motdotla/dotenv
I've added a private RSA key to .env. Using it to sign a JWT.
When I sign the JWT, this error greats me.
error:0906D066:PEM routines:PEM_read_bio:bad end line
My RSA key is just a basic multi line, key.
-----BEGIN RSA PRIVATE KEY-----
MIIEpgIBAAKCAQE.......
........
The RSA key is multi-line.
DotEnv can only read one-liners, the unfortunate work around (AFIAK) are to add a \n to the end of every line. And then make this string a one liner. But this error keeps occuring..
Has anyone else experienced this and have solution?
Or perhaps know of another env file manager that can handle multi-lines?
Add surrounding double quotes to the value in the .env file and replace line breaks with \n like so:
KEY="-----BEGIN RSA PRIVATE KEY-----\nMIIE..."
I have created a PFX PDU using the java bouncycastle library. Inside the PFX PDU, there are two certificates and two encrypted private keys. All the contents are used as PKCS#7 data content (i.e. no encryption, stored as octet strings).I organised the elements according to the guidelines of PKCS#12 (RFC 7292 Section 5). Then I wrote the DER encoded byte array to a file.
I opened the file in a hex editor and saw that the object structure is OK. I have also read the file contents and built a bouncycastle PFX object from it. But when I try to open the .pfx file from my file system, the Certificate Import Wizard asks for the password for the private key. I did not use any password to create the PFX object. I have tried to use empty string and the password used for encrypting the private keys, but they didn't work. It shows "The password you entered is incorrect.".
Is there something I missed here? How can I get the password required to import certificates?
In RFC 7292, section 4.1, page 41, details of AuthenticatedSafe is described. AutthenticatedSafe is sequence OF ContentInfo which could one of three types.
AuthenticatedSafe ::= SEQUENCE OF ContentInfo
-- Data if unencrypted
-- EncryptedData if password-encrypted
-- EnvelopedData if public key-encrypted
Make your authenticatedSafe data as EncryptedData where you needs to encrypt the BERencoded value of AuthenticatedSafe with the SecretKey generated from password you will give using SecretKeyFactory and PBEParameterSpec.
Hope that, this will help you. Cheers !!!
I am using Botan to create public/private ECDSA keypairs. The public keys that are generated (even on different machines using this code) are very similar... too similar to consider safe I would think. Here is an example of two runs:
-----BEGIN PUBLIC KEY-----
MIIBEzCB7AYHKoZIzj0CATCB4AIBATAsBgcqhkjOPQEBAiEA////////////////
/////////////////////v///C8wRAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHBEEEeb5m
fvncu6xVoGKVzocLBwKb/NstzijZWfKBWxb4F5hIOtp3JqPEZV2k+/wOEQio/Re0
SKaFVBmcR9CP+xDUuAIhAP////////////////////66rtzmr0igO7/SXozQNkFB
AgEBAyIAAneDBKm4ubKbv0hxgzhkh0oAI8WKFTs1Hz/Qqyl6qxzD
-----END PUBLIC KEY-----
-----BEGIN PUBLIC KEY-----
MIIBEzCB7AYHKoZIzj0CATCB4AIBATAsBgcqhkjOPQEBAiEA////////////////
/////////////////////v///C8wRAQgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAEIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHBEEEeb5m
fvncu6xVoGKVzocLBwKb/NstzijZWfKBWxb4F5hIOtp3JqPEZV2k+/wOEQio/Re0
SKaFVBmcR9CP+xDUuAIhAP////////////////////66rtzmr0igO7/SXozQNkFB
AgEBAyIAAtQr5BPT04pk/Ror6uIGRqEKeB8dwIteR8p/r+Nl7hql
-----END PUBLIC KEY-----
I am using X509 encoding to encode the public key. Here's the code to generate the ECDSA keys:
LibraryInitializer init;
AutoSeeded_RNG rng;
EC_Group ecGroup("secp256k1");
ECDSA_PrivateKey key(rng, ecGroup);
Why am I generating such similar public keys? And am I right in assuming that isn't "safe" if multiple users were to use this code to generate their own keys?
UPDATE:
The answer below seems correct. I emailed the creator of XCA, Christian Hohnstaedt, to probe a little further into how XCA generates this public key and what it is. He replied that it is the EC_POINT and is obtained by using the command
openssl ec -pubin -noout -text
Plugging in the X509 PEM encoded public keys indeed reveals different public EC Points. It should be noted (for other newbs like me) that the public EC Points in the answer do no good for another party on their own - the other party needs to know which EC Group is being used, and that's why the X509 PEM encoding is much more helpful than just an EC Point.
The actual public keys from these are:
02:77:83:04:A9:B8:B9:B2:9B:BF:48:71:83:38:64:87
4A:00:23:C5:8A:15:3B:35:1F:3F:D0:AB:29:7A:AB:1C
C3
and
02:D4:2B:E4:13:D3:D3:8A:64:FD:1A:2B:EA:E2:06:46
A1:0A:78:1F:1D:C0:8B:5E:47:CA:7F:AF:E3:65:EE:1A
A5
These are not the same, so there is no apparent reason to worry on that front. The data that is the same is the key meta-data and encoding bumf (which you would expect to be the same for identical format keys).
Values obtained by importing into xca (linux). There are better tools for inspecting DER encoded data, but I couldn't find any easily.