“The only secrets are the secrets that keep themselves”- George Bernard Shaw

Leveraging a service like AWS Secrets Manager, to outsource secured storage and life-cycle management of secrets (like passwords, API keys, tokens, encryption keys, etc.) is becoming quite commonplace. Essentially, this practice keeps the application code clean and devoid of any sensitive information that might get leaked otherwise. The idea is to either use DevOps pipeline to fetch secrets and inject them at the time of deployment (primarily as environment variables) or use AWS SDK to retrieve secrets during application runtime and use them.

Normally, creation and retrieval of sensitive values from Secrets Manager is pretty straightforward. AWS has done a really good job in creating multiple ways to do so- AWS console, SDK, CLI & REST APIs. However, when it comes to storing/retrieving encryption keys (symmetric or asymmetric), one has to be a tad careful.

For instance, a very common error (in Node.js applications) resulting due to an incorrectly stored PEM encoded encryption key in AWS Secrets Manager, is shown below. Any character translation corrupts the key and following error is directly thrown from PEM libraries when we attempt to use the incorrectly stored key in a scenario like mutual TLS authentication (mTLS) or otherwise.

{ 
   “library”: “PEM routines”, 
   “function”: “get_name”, 
   “reason”: “no start line”, 
   “code”: “ERR_OSSL_PEM_NO_START_LINE”
}

#secrets #aws-cli #aws-sdk #aws-secrets-manager #binarysecret