9

I'm trying to construct an RS256 JWT token using only bash and openSSL (I have limited development tools at my disposal).

I've devised a script which takes the header and payload from txt files (stripping out newlines etc), base-64URL encodes them and concatenates them together with a '.' separator.

I'm then attempting to sign the output, which I also base-64URL encode and append to the end (with another '.' separator). I believe this accurately reflects the JWT model.

My private key and certificate were generated using openSSL:

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout ./privateKey2.key -out ./certificate2.crt

My public key was generated from the private key using:

openssl rsa  -pubout -in ./privateKey2.key > ./publicKey2.key

I then have the following bash script that process the job:

cat header.txt | tr -d '\n' | tr -d '\r' | openssl base64 | tr +/ -_ | tr -d '=' > header.b64
cat payload.txt | tr -d '\n' | tr -d '\r' | openssl base64 | tr +/ -_ |tr -d '=' > payload.b64
printf "%s" "$(<header.b64)" "." "$(<payload.b64)" > unsigned.b64
rm header.b64
rm payload.b64
openssl rsautl -sign -inkey privateKey2.key -in unsigned.b64 -out sig.txt
cat sig.txt | openssl base64 | tr +/ -_ | tr -d '=' > sig.b64
printf "%s" "$(<unsigned.b64)" "." "$(<sig.b64)" > jwt.txt
rm unsigned.b64
rm sig.b64
rm sig.txt

I believe the script itself is working, but whenever I upload the final output into jwt.io's testing tool, it tells me the signature is invalid (it can read the content and header and payload are correct).

Is my use of openssl rsautl incorrect?

Happy to include keys / sample data if they'd help

Example output:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2
MjM5MDIyfQ.fE-btiyskyDrO1mQXcICP0udbCkdV9D_50CYNbpRVgod6EPjKmbOJK-EA7vn7s5l
TtkvKw0m1r45poGApBT4SA_ChmEgsPzhGwxd2xpInesRon-mWTzsUqqz0C1CcegT
n9Z19JzGJ7wUjomg7viKI1OP7Ei6TptINE8hPqEBPPpeO2PfT5IevMb1XytaCuTO
R1JMurgwsIa0Kq3LaFoAk1stUnTtJRI8-NHzWqmUiQpq-K1eteBtT9ZvKXJ_6ReY
_AetoeqmEDVQO_UV2ae_dKd4QHSV8D-ryJFc-OEYWzgwGeqXSBMNVMzsXKSUIR8C
sfvZ2hvwbQI2f0J6gZQw0w

Corresponding public key

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1YbvZ3CPPr3X47J/pqCD
ciE0AhRbiBrybu4T3GbbHfGYROaPSKx2LfXCwAlayln5zNaZ14cvlDHEpCIQviPk
Qv5Ux16R2QouhF0ZugyMHLQkusVXG6Va14eFVKkcO2g1c25bOMAk4V3vSsVnMMQS
fTPunpGVrBUBo2We5P+cKldBNXKBlXEAIRGc4/fTcTB4F8opP+x5ACIZ04SWKafJ
MSvujIfpBxs476bvxA5xlPQiOhbOIo/bhPMJI6AlaDTJ03pGTOYjR5jZlB03j4YD
EF/2hhidvvFnLHdPkewzDsn0aZi+fqBNvQhS0hutnvp6F8hGL9e5hh8G7a2AXy9F
2QIDAQAB
-----END PUBLIC KEY-----
David Fulton
  • 737
  • 7
  • 16

2 Answers2

11

I combined David Fulton's Answer with documentation from github and some jwt-with-bash and rsa-sign-and-verify links.

Refactoring the base64-ification was tricky because of trailing newlines (I think). Instead, just keep all the commands inline.

PEM=$( cat my/pem/file )
GITHUB_APP_ID=4 # Whatever your github app id is

NOW=$( date +%s )
IAT="${NOW}"
# expire 9 minutes in the future. 10 minutes is the max for github
EXP=$((${NOW} + 540))
HEADER_RAW='{"alg":"RS256"}'
HEADER=$( echo -n "${HEADER_RAW}" | openssl base64 | tr -d '=' | tr '/+' '_-' | tr -d '\n' )
PAYLOAD_RAW='{"iat":'"${IAT}"',"exp":'"${EXP}"',"iss":'"${GITHUB_APP_ID}"'}'
PAYLOAD=$( echo -n "${PAYLOAD_RAW}" | openssl base64 | tr -d '=' | tr '/+' '_-' | tr -d '\n' )
HEADER_PAYLOAD="${HEADER}"."${PAYLOAD}"
SIGNATURE=$( openssl dgst -sha256 -sign <(echo -n "${PEM}") <(echo -n "${HEADER_PAYLOAD}") | openssl base64 | tr -d '=' | tr '/+' '_-' | tr -d '\n' )
JWT="${HEADER_PAYLOAD}"."${SIGNATURE}"

#${JWT} now has our token
Heath Borders
  • 30,998
  • 16
  • 147
  • 256
  • Related answer: https://stackoverflow.com/a/62646801/9636 – Heath Borders Jun 29 '20 at 21:18
  • Related answer: https://stackoverflow.com/a/62646831/9636 – Heath Borders Jun 29 '20 at 21:20
  • This looks promising, instead of a PEM file can a json file be used instead? or better yet just the private key as a string? – bscott Jun 08 '21 at 13:16
  • I don't know of any private key formats that accept a json file, and I don't know what you mean by "private key as a string". – Heath Borders Jun 09 '21 at 03:47
  • 1
    As an aside -- all-caps variable names are defined by the POSIX specification to be used for variables that reflect or modify behavior of POSIX-specified utilities, whereas lowercase names are reserved for application use and guaranteed not to have unintended effects on the shell itself. See https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html laying out this convention. – Charles Duffy Nov 27 '21 at 16:49
  • Thanks! Even though I've been doing `bash` forever, I've always felt like I've been doing little things like this wrong because it's always noobs leading noobs. :) – Heath Borders Nov 28 '21 at 00:01
9

Successfully resolved this. It was caused by a couple of issues:

  1. openssl base64 inserts carriage returns every 70-odd characters by default. I believe you can override this, but just using the base64 command instead solved that.

  2. My signing step was wrong. I replaced rsautl with dgst as follows:

    openssl dgst -sha256 -sign private.key -out sig.txt unsigned.b64

RS256 signatures now pass validation in jwt.io

Complete working code (for posterity):

cat header.txt | tr -d '\n' | tr -d '\r' | base64 | tr +/ -_ | tr -d '=' > header.b64
cat payload.txt | tr -d '\n' | tr -d '\r' | base64 | tr +/ -_ |tr -d '=' > payload.b64
printf "%s" "$(<header.b64)" "." "$(<payload.b64)" > unsigned.b64
rm header.b64
rm payload.b64
openssl dgst -sha256 -sign -privateKey2.key -out sig.txt unsigned.b64
cat sig.txt | base64 | tr +/ -_ | tr -d '=' > sig.b64
printf "%s" "$(<unsigned.b64)" "." "$(<sig.b64)" > jwt.txt
rm unsigned.b64
rm sig.b64
rm sig.txt
David Fulton
  • 737
  • 7
  • 16