Skip to main content

Key generation

You need an RSA key pair. Your private key signs requests and never leaves your infrastructure. Your certificate (public key) goes to Cheggout so they can verify your signatures.

You do this once per environment. Keep UAT and production keys separate.

Requirements​

ParameterValue
AlgorithmRSA
Key size2048-bit
SignatureSHA256withRSA (PKCS#1 v1.5)
Exchange formatX.509 certificate (PEM)

Generate the pair​

Step 1 — Private key​

openssl genrsa -des3 -out server.key 2048

Generates a 2048-bit RSA private key. -des3 encrypts it with Triple DES and prompts for a passphrase — keep that passphrase in your secret manager alongside the key.

Produces: server.key (encrypted PEM private key).

Step 2 — Convert to unencrypted DER​

openssl pkcs8 -topk8 -inform PEM -outform DER -in server.key -out server.der -nocrypt

Converts the PEM private key to PKCS#8 in DER encoding. -nocrypt strips the passphrase — some runtimes require an unencrypted DER key to load it.

Produces: server.der (unencrypted DER private key). This is a format conversion, not a new key.

server.der is unencrypted

This file is your signing identity in the clear. Store it in a secret manager with tight access control; never commit it, never bake it into an artifact, never email it.

Step 3 — Certificate signing request​

openssl req -new -key server.key -sha256 -out pub.csr

Creates a CSR from your private key. Add -config /path/to/openssl.cnf if your platform needs an explicit OpenSSL configuration (common on macOS with Homebrew OpenSSL).

Produces: pub.csr (PEM).

Step 4 — Self-signed certificate​

openssl x509 -req -days 3650 -in pub.csr -signkey server.key -out pub.crt

Produces: pub.crt — an X.509 certificate valid for 10 years. This is the file you send to Cheggout.

What to exchange​

FileKeep or sendPurpose
server.keyKeep — secretSigning, passphrase-protected
server.derKeep — secretSigning, if your runtime needs DER
pub.csrDiscard after step 4Intermediate
pub.crtSend to CheggoutVerifying your signatures

In return, Cheggout sends their public certificate, which you use to verify Cheggout's response signatures. Store it as configuration — it is not a secret, but treat replacing it as a controlled change.

Verify your setup​

Before contacting Cheggout, prove the round trip locally.

# 1. Build a BDATA string
echo -n '{"bName":"YOURCHANNEL"}' | openssl base64 -A > bdata.txt

# 2. Sign it with your private key
openssl dgst -sha256 -sign server.key -out sig.bin bdata.txt
openssl base64 -A -in sig.bin -out sign.txt

# 3. Verify with your own certificate
openssl x509 -pubkey -noout -in pub.crt > pub.pem
openssl dgst -sha256 -verify pub.pem -signature sig.bin bdata.txt

Verified OK means your signing implementation matches what Cheggout will do. If this passes but Cheggout still returns Signature Mismatch!, the problem is in your application code — most often signing the decoded JSON instead of the Base64 string. See the signed envelope.

Sign the exact bytes you send

openssl dgst above signs the contents of bdata.txt. In your application, sign the same string you place in the BDATA field — do not re-serialise the payload between signing and sending.

Storing keys​

  • Use a managed secret store (cloud KMS, HashiCorp Vault, or your platform's equivalent).
  • Grant access to the signing service only, not to CI or developer machines.
  • Keep separate key pairs for UAT and production.
  • Log signing failures, never the key or the signature material.

Never place a private key in a mobile app, in JavaScript, in a container image layer, in environment variables checked into source control, or in a support ticket.

Rotation​

TBD There is no published key-rotation procedure. Rotation requires coordination with Cheggout so both sides swap at the same time; there is currently no documented overlap window or self-service upload.

If you need to rotate — particularly after any suspected exposure — contact Cheggout immediately via Support. A documented rotation process is tracked in Open Items.

Next​