Passwords for certificates and keys

[jackivanov]

Hi there,

I guess many people would like to set passwords to the certificates and keys. This is a base feature. Is there any particular reason why it's not implemented yet?

Thanks!

[SpencerBrown]

Passwords are used to encrypt TLS private keys, because private keys are security sensitive. TLS certificates are public, and are provided by a TLS peer during the TLS handshake protocol for validation. TLS certificates do not need keys.

For the TLS provider, we would need a password argument for:

• tls_public_key data source (to decrypt the provided private key)
• tls_private_key resource (to encrypt the generated private key)
• tls_self_signed_cert (to decrypt the provided private key)
• tls_locally_signed_cert (to decrypt the provided private key)
• tls_cert_request (to decrypt the provided private key)

The ability to secure sensitive data (such as passwords or unencrypted private keys) is planned for future releases of Terraform. In the meantime, the state (local or remote) needs to be secured by means external to Terraform itself.

Other providers typically allow the user to provide the password in an environment variable, to allow them to avoid hardcoding passwords in a .tf file. Our implementation in the TLS provider should do that also. See the comments on this PR for rationale as to why Terraform itself doesn't allow direct interpolation of environment variables.

As to why it's not implemented yet, the Terraform TLS Provider is a community provider and depends on the community to provide bug fixes and new features. For example, I am a contributor out of my own interest and on my own time. Consider becoming a contributor!

[jackivanov]

Thanks! In addition we need to consider not only destroying certificates, but creating a CRL as well.

[SpencerBrown]

1. Not sure what you mean by "destroying certificates". Can you amplify on this?
2. Supporting Certificate Revocation Lists (CRLs) is certainly possible but is a different topic from passwords. Do you have a specific need for CRLs? If so please open a separate issue, and help me understand the priority of this for you.

[jackivanov]

Moved the CRL question to #20

[jimsnab]

Due to lack of ability to specify the passphrase of a private key (!), the error will look something like

Error: failed to decode private_key_pem: asn1: structure error: tags don't match (16 vs {class:1 tag:14 length:113 isCompound:false}) {optional:false explicit:false application:false private:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false} pkcs1PrivateKey @2