Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

Terraform Version

$ terraform -v
Terraform v0.12.23
+ provider.azurerm v2.4.0
+ provider.tls v2.1.1

Affected Resource(s)

provider.tls v2.1.1

Terraform Configuration Files

data "tls_public_key" "ppk" {
  private_key_pem = "${file("my.pem")}"
}

output "ppk" {
  value = data.tls_public_key.ppk.private_key_pem
}

output "pk" {
  value = data.tls_public_key.ppk.public_key_pem
}

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://www.terraform.io/docs/internals/debugging.html. Please do NOT paste the debug output in the issue; just paste a link to the Gist.

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

We want to use certificate generated with azurerm_key_vault_certificate to provision azurerm_linux_virtual_machine.
Currently, it's not possible to get the public key from azurerm_key_vault_certificate in Terraform (because azure REST API does not have that functionality), therefore we are trying to use public_key_openssh from data tls_public_key.

Of course we can use tls_private_key to generate a SSH key pair, but then we are not taking advantage of the azure certificate to rotate he key for example.

Actual Behavior

Error: failed to decode PEM block containing private key of type "PRIVATE KEY"

  on tls.tf line 7, in data "tls_public_key" "ppk":
   7: data "tls_public_key" "ppk" {

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs?

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

• GH-1234

It seems that using an AES-128-CBC private key, will cause the public key generation to fail.
key format:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,C844B3C5E74D8CEB17B9541A319CC151

.....
-----END RSA PRIVATE KEY-----

This is key is generally created via openssl:
openssl genrsa -aes128 -out <newkey>
See: https://superuser.com/a/965464

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

data.tls_public_key.test: Refreshing state...

Error: Error refreshing state: 1 error(s) occurred:

* data.tls_public_key.test: 1 error(s) occurred:
* data.tls_public_key.test: data.tls_public_key.test: error converting key to algo: RSA - failed to decode private_key_pem: asn1: structure error: length too large

This is more of a reminder for myself to fix the issue 😝

I'm trying to import a key created with tls_private_key (with the private_key_pem attribute) into the azurerm_key_vault_certificate resource. azurerm_key_vault_certificate rejects the private key created with tks_private_key as it in in pkcs#1 format and not the pkcs#8 format that Azure Key Vault wants.

tls_private_key.private_key_pem attrtibute outputs a PEM with '-----BEGIN RSA PRIVATE KEY-----' header which is PKCS#1, azurerm_key_vault_certificate expects a cert package with a private key that has a pkcs#8 header '-----BEGIN PRIVATE KEY-----'

If I convert the output of tls_private_key.private_key_pem with openssl (openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in ca-key.pem -out test-key.pem) then I can import the certificate fine.

The snippet of code that is of interest:

resource tls_private_key ca_key {
   algorithm = "RSA"
   rsa_bits  = 4096
}

This relates to #3017 on azurerm provider. In that issue it was closed due to Azure Issue. Azure has fixed their backend, so current state is when I try to import the private
key into azurerm_key_vault_certificate I get the following error:
The specified PEM X.509 certificate content is in an unexpected format. Please check if certificate is in valid PEM format.

Terraform Version

Terraform version 0.13.5
TLS provider version 3.0

Affected Resource(s)

• tls_private_key
• azurerm_key_vault_certificate

Terraform Configuration Files

variable private_key_size {
    default = 4096
}
variable private_key_algorithim {
    default = "RSA"
}
resource tls_private_key ca_key {
   algorithm = var.private_key_algorithim
   rsa_bits  = var.private_key_size
}


resource tls_self_signed_cert ca_cert {
   private_key_pem = tls_private_key.ca_key.private_key_pem
   key_algorithm = "RSA"
   subject {
     common_name         = var.common_name
     organization        = var.issuer_organization.organization
     organizational_unit = var.issuer_organization.organizational_unit
     street_address      = var.issuer_organization.street_address
     locality            = var.issuer_organization.locality
     province            = var.issuer_organization.province
     country             = var.issuer_organization.country
     postal_code         = var.issuer_organization.postal_code

   }
   # 175200 = 20 years
   validity_period_hours = 175200
   allowed_uses = [
     "cert_signing",
     "crl_signing"
   ]
   is_ca_certificate = true 

}
resource local_file private_key {
    sensitive_content = tls_private_key.ca_key.private_key_pem
    filename = "${var.output_cert_path}/ca-key.pem"
    file_permission = "0600"
}
resource local_file ca_file {
    sensitive_content = tls_self_signed_cert.ca_cert.cert_pem
    filename = "${var.output_cert_path}/ca-cert.pem"
    file_permission = "0600"
}
resource local_file ca_pem_bundle {
    sensitive_content = "${tls_private_key.ca_key.private_key_pem}${tls_self_signed_cert.ca_cert.cert_pem}"
    filename = "${var.output_cert_path}/ca-bundle.pem"
    file_permission = "0600"
}

resource azurerm_key_vault_certificate ca_cert {
  name          = var.service_settings.cert_name
  key_vault_id  = var.service_settings.key_vault_resource_id

  certificate {
    contents = "${tls_private_key.ca_key.private_key_pem}${tls_self_signed_cert.ca_cert.cert_pem}"
    #contents = file("./secrets/test.pem")
    password = ""
  }
  certificate_policy {
    key_properties {
      exportable = "true"
      key_size   = var.private_key_size 
      key_type   = var.private_key_algorithim
      reuse_key  = "true"
    }
    issuer_parameters {
      name = "Self"
    }
    secret_properties {
      content_type = "application/x-pem-file"
    }
  }



}

Debug Output

https://gist.github.com/stvdilln/b1bf0ae3b68b64b5ad7ddf3ec1e44b9b

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

I should be able to take key from tls_self_signed_cert and import into azurerm_key_vault_certificate.

Actual Behavior

Error about cert package:

 The specified PEM X.509 certificate content is in an unexpected format. Please check if certificate is in valid PEM format.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

References

AzureRM provider issue 3017.
Microsoft Docs
Microsoft docs snippet:

Azure Key Vault supports .pem and .pfx certificate files for importing Certificates into Key vault. We support the following type of Import for PEM file format. A single PEM encoded certificate along with a PKCS#8 encoded, unencrypted key which has the following

Terraform Version

v0.10.8

Affected Resource(s)

Please list the resources as a list, for example:

• tls_private_key

Terraform Configuration Files

terraform {
  required_version = ">= 0.10.1"
}

provider "tls" {}

resource "tls_private_key" "main" {
  algorithm = "RSA"
}

variable "private_key_filename" {
  default     = "private_key.pem"
  description = "Name of the SSH private key in PEM format"
}

variable "public_key_pem_filename" {
  default     = "public_key.pem"
  description = "Name of the SSH public key in PEM format"
}

variable "public_key_openssh_filename" {
  default     = "public_key_openssh"
  description = "Name of the SSH public key in OpenSSH format"
}

resource "null_resource" "main" {
  provisioner "local-exec" {
    command = "echo \"${tls_private_key.main.private_key_pem}\" > ${var.private_key_filename}"
  }

  provisioner "local-exec" {
    command = "chmod 600 ${var.private_key_filename}"
  }

  provisioner "local-exec" {
    command = "echo \"${tls_private_key.main.public_key_pem}\" > ${var.public_key_pem_filename}"
  }

  provisioner "local-exec" {
    command = "chmod 600 ${var.public_key_pem_filename}"
  }

  provisioner "local-exec" {
    command = "echo \"${tls_private_key.main.public_key_openssh}\" > ${var.public_key_openssh_filename}"
  }

  provisioner "local-exec" {
    command = "chmod 600 ${var.public_key_openssh_filename}"
  }
}

Expected Behavior

Newlines should not be added at the end of the keys

Actual Behavior

Here is log from terraform apply. You can see extra \n at end of each key in this or in the generated files if you recreate with my main.tf.

$ terraform apply
tls_private_key.main: Creating...
algorithm: "" => "RSA"
ecdsa_curve: "" => "P224"
private_key_pem: "" => ""
public_key_openssh: "" => ""
public_key_pem: "" => ""
rsa_bits: "" => "2048"
tls_private_key.main: Creation complete after 0s (ID: 6cd041060b6acf22676f7d331e320a2e99a6d8a0)
null_resource.main: Creating...
null_resource.main: Provisioning with 'local-exec'...
null_resource.main (local-exec): Executing: ["/bin/sh" "-c" "echo "-----BEGIN RSA PRIVATE KEY-----\nMIIEpAIBAAKCAQEAu0JwN/VkTgogMn/ln3UnqcUebukYSeG7auGX/L3T0sgtspcN\nf7h7PPvgOAPkzP70M0ZGJ8HrF5FhUVQx0BHaLOvEPCjXJknoAjAF4LMTZvcGVKNG\nCkE4CpGpNTCNDIqGDJNU5VNQj9130mQA70v4HgvyJvAAIwNNtX7lgQPAi5LGgob7\nRtstwiaTM+ZGAN0c2V7X5HDsR6cFtFNCuqE9UM8e7l8hXngrPkN/lN7VwrGOlHdQ\nBGO3R0tvbSnfZWREMUwWkSyYHwqTaDh1/tWCaGSpviebSnQCKlgVTHc+T1XPvQHT\neS8suu7tm/Exn5I4bv9wsG8tdkIPduiKP+or/QIDAQABAoIBADP4AETHaYru7HiX\nXhae4N8QwZ1uOztl1imXaiLOW9cHjwcdPLXRcQI/tL5W9kyeBQ+l1Rp7is8DncqA\nX0Krca090TwQ6YTKxgS1ZywxBpVwwOUEWw/FgdQNELSeQMbWOtWKnej28ki64eIV\nttyybK2KCy4bNS6CYDKagP8JF4qkOuZ6k1iw9g3lbjaiSrhpfyVwDYhCSkqT46TC\nYmXbzhg/oyqyTDr1sdN5X9kOXkNsTicWXLjtVSJXMbA5Ps5Zzsyn8GW1yrtwm3Kk\nLKhPjGjEkNb1PS6SGguiCC/8npslPJTn+PAjg/5Q2alAjHj2rD+CBovE43bODsBp\n4txDaYECgYEA9q+tFwBn2z+OeZHmflZrnD9uCUBi5hj90zFh0i68k3uLGaQAWNLr\nz9osaxqaAVe+tdZ5zr3hN7ZHr+oe+1GP3NTkWyIdmneXJ4q4F/MzrwUIaIwi7lr5\nNhpii4FdvaGMdFPpnoXkkoIOBuGvcZBS6gtUqo8Yl5vzJIZrhum+QakCgYEAwlRg\n7ohDCKjUZZTuI4K/iqNMQRiZnUgUBms2QEsPVxHvA7zPLMya3x5YOsjHAcVjUEcE\n8HrIygA0R24rgLZOKpPhGhvQqNkBQkT828IoF9hz0nVTKC5D5SXqVj/pnEUDS2QT\nc5yU6u6MrO7sX7UfJDB1JYjwlDlvcA5gBz9WdDUCgYBS3bqYUnOQy+3RWriB0gf+\nCbSt+On//38sdZc1oquII2UbrOLM87VxMgnfxKTdNJuEu9JZJ6HDNEEqj8vugnyA\nIye+kVw+alPlXYzvxqui7F7ht8l4Jik3Cm/2CvPxYpYq8ZE1xiZ9LKEHoMJttJyV\nsE61qLILI8DukRUH0fcuWQKBgQCrDw14Szf+smasuIlbdudWiWJBVv85pM4DzHIn\n7CqnsWCdAKG5xK17Q8HUlRIgq/k9HBbr/JksvztFuWPP3Co4bo3SprNpPgROql2O\nsH0MaHujwaUelIMtfc+mdoIUDefVgFVjCm1H1A6+11347X1pJMKp9L4ZK+m9UNoU\n5xsaFQKBgQDTBFqW99qid8qAw5pgJDdMvWev/u1VTZmv658D0dCTETIWGkzZ1j/H\n0RVju57VyHK8l5qnQUMyg1PU4keGGHvEA84Y/Zi3euKz3LRQvvVHXE3Bx2qHVZ2x\n2uYncnwlc3yr8zI3ZOcOifOHzX6+7M+rn4UM7FmjgucMZaMG0+cswA==\n-----END RSA PRIVATE KEY-----\n" > private_key.pem"]
null_resource.main: Provisioning with 'local-exec'...
null_resource.main (local-exec): Executing: ["/bin/sh" "-c" "chmod 600 private_key.pem"]
null_resource.main: Provisioning with 'local-exec'...
null_resource.main (local-exec): Executing: ["/bin/sh" "-c" "echo "-----BEGIN PUBLIC KEY-----\nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu0JwN/VkTgogMn/ln3Un\nqcUebukYSeG7auGX/L3T0sgtspcNf7h7PPvgOAPkzP70M0ZGJ8HrF5FhUVQx0BHa\nLOvEPCjXJknoAjAF4LMTZvcGVKNGCkE4CpGpNTCNDIqGDJNU5VNQj9130mQA70v4\nHgvyJvAAIwNNtX7lgQPAi5LGgob7RtstwiaTM+ZGAN0c2V7X5HDsR6cFtFNCuqE9\nUM8e7l8hXngrPkN/lN7VwrGOlHdQBGO3R0tvbSnfZWREMUwWkSyYHwqTaDh1/tWC\naGSpviebSnQCKlgVTHc+T1XPvQHTeS8suu7tm/Exn5I4bv9wsG8tdkIPduiKP+or\n/QIDAQAB\n-----END PUBLIC KEY-----\n" > public_key.pem"]
null_resource.main: Provisioning with 'local-exec'...
null_resource.main (local-exec): Executing: ["/bin/sh" "-c" "chmod 600 public_key.pem"]
null_resource.main: Provisioning with 'local-exec'...
null_resource.main (local-exec): Executing: ["/bin/sh" "-c" "echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC7QnA39WROCiAyf+WfdSepxR5u6RhJ4btq4Zf8vdPSyC2ylw1/uHs8++A4A+TM/vQzRkYnwesXkWFRVDHQEdos68Q8KNcmSegCMAXgsxNm9wZUo0YKQTgKkak1MI0MioYMk1TlU1CP3XfSZADvS/geC/Im8AAjA021fuWBA8CLksaChvtG2y3CJpMz5kYA3RzZXtfkcOxHpwW0U0K6oT1Qzx7uXyFeeCs+Q3+U3tXCsY6Ud1AEY7dHS29tKd9lZEQxTBaRLJgfCpNoOHX+1YJoZKm+J5tKdAIqWBVMdz5PVc+9AdN5Lyy67u2b8TGfkjhu/3Cwby12Qg926Io/6iv9\n" > public_key_openssh"]
null_resource.main: Provisioning with 'local-exec'...
null_resource.main (local-exec): Executing: ["/bin/sh" "-c" "chmod 600 public_key_openssh"]
null_resource.main: Creation complete after 0s (ID: 5056070395537356698)

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform init
2. terraform plan
3. terraform apply

Important Factoids

In many cases, having the extra newline at the end of the keys might not matter. But when I tried to pass the public_key_openssh output into an Azure resource manger template for use with acs-engine, my invocation of az group deployment create with the local-exec provisioner in a null_resource resource failed with parsing errors. specifically, I was passing it into the ssh.publicKeys.keyData field of the linuxProfile of the ACS Engine Cluster template. That document has a link to instructions for generating a public/private key pair which in turn links to instructions from GitHub on generating keys with ssh-keygen. When I generated a pair following those instructions, there were no newlines at the end of the generated files. Note that I am using MacOS Sierra 10.12.6.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

To configure the Application Gateway Resource with a TLS certificate, a pkcs12 file format is required. Unfortunately, all other native terraform resources (outside azure) work with traditional PEM format.

We currently try to provision an AG with a certificate that has been generated using the ACME terraform provider in conjunction with its Azure DNS provider (https://www.terraform.io/docs/providers/acme/dns_providers/azure.html).

The ACME certificate resource (https://www.terraform.io/docs/providers/acme/r/certificate.html) creates a Lets Encrypt certificate successfully and returns its public and private key as PEM.

Do get this into the AG we currently use an external datasource that calls openssl:

Terraform

data "external" "certificate-pfx" {
  program = ["bash", "${path.module}/data-sources/generate-pfx.sh"]

  query = {
    certificate_pem = "${acme_certificate.certificate.certificate_pem}"
    private_key_pem = "${acme_certificate.certificate.private_key_pem}"
  }
}

resource "azurerm_application_gateway" "ag" {
  # [...]

  http_listener {
    # [...]
    ssl_certificate_name = "ag-ssl-certificate"
  }

  ssl_certificate {
    name     = "ag-ssl-certificate"
    data     = "${data.external.certificate-pfx.result["pfx"]}"
    password = ""
  }

Data Source

#!/bin/bash
set -eu -o pipefail

export certificate_pem
export private_key_pem

eval "$(jq -r '@sh "certificate_pem=\(.certificate_pem) private_key_pem=\(.private_key_pem)"')"

cert_file="$(mktemp -p .)"
trap 'rm -f $cert_file' EXIT

echo "${certificate_pem}${private_key_pem}" >"$cert_file"

pfx="$(openssl pkcs12 \
  -in "$cert_file" \
  -export \
  -password "pass:" \
  |base64 -)"

jq -n --arg pfx "$pfx" '{"pfx":$pfx}'

Actual Issue

While this works from a technical perspective, it is far from optimal. The Data Source is executed on every terraform apply and the resulting pkcs12 archive is different on every execution, at least on the binary level - even though the inner PEM files stay the same

That means, for every apply the AG "changes" it's certificate which takes roughly 10 minutes.

Do you have any smart ideas on how to make this work better?

Ideally, the azure resources should use the same certificate formats as all other TF resources, that would be PEM.

New or Affected Resource(s)

• azurerm_application_gateway

Thank you very much :)

Terraform Version

➜ terraform -v
Terraform v0.11.14
+ provider.tls v2.1.1

Affected Resource(s)

• tls_self_signed_cert

Terraform Configuration Files

resource "tls_self_signed_cert" "foo" {
  key_algorithm   = "RSA"
  private_key_pem = "${file("private-key-pkcs8.pem")}"

  subject {
    common_name  = "foo"
  }

  validity_period_hours = 24

  allowed_uses = [
    "digital_signature",
    "key_encipherment",
    "server_auth",
  ]
}

Private key in PKCS#8 format:

-----BEGIN PRIVATE KEY-----
MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDurPIlDU3hwSMC
FwmlgaMpHC4J0ZPmiEgNczFhNfZ8OS3WfVbMuVfNaOexkxB7ZBREH1S8H4TiWXpZ
cctcpT8TLa1YmHRJdsJoD8+35pQSD4tFZH1gRsCaDkaZsto1iGH5AnNPAQ7sLJiN
B45zu9XDOx3IrpsN9Ol7HH1vErp9IDQ5Akt+Lj69Y0oftTsSmJL5YeE6Lh5yHMn9
scTSFMK65wzSqxW+K/H/DQt4120+5bidPdQmayW/0+sUr10ddKPz97ZfChfc6pwG
FxCnVVaSZIsX6wK5HZMe0m5jZODNCNr6aNs6XQgaBxUuabuWlP7PPv3c37QLThYe
s2tywsC9AgMBAAECggEBANpwFj2q63iOFsg25XFAMF/Tlp8N3FrEp40HvE3H4YrX
mggQNnyvtJgeRs7SVedYNOQT+K0j+65dTgjGiOSFqDCZQWkwPl1t/4bV0bnxodrV
txUPX1/Z4TQdlKfedK9B3sjTYU0RHuMv/X41SD7LzlwboqqkguxHFdjCvloFvf/8
0L7KeF59sSKaaF88pwjVzooel5jyli5kaCyrqVCpMnbOYsfyYB5SfR7Hw3mySOUv
Z4ckVeUEvFgu09kp0UPZRoI9qZUdkTERdD0hZfUGxPnYE0HRGx4WnV3VVj2usiLh
QHsGdAsB5ggJP/dQNRwhBlXjh6RtXPVSjQkdeve4sQECgYEA/H8PpIw1m97Sy/r1
TjbnRZAR7395WQ2nZ+oQzMLtQCM1TerFVnX9psyWcBWBL56ErxjxZeApugyZLD/a
Sc7lsJcQ+S6xClwprv3NR1NJhUQqhLZG+kOjwO0YQnSucFE9u7dJVieuNEpQMmff
plfhUDh58qQBEGPSGf9gzCvfHRECgYEA8fzKG96i857RdRryIBYCF2ltTSdcxEus
7PSpBMbXmSDIHu2LIHjPEQaz/VNvXDSQ2pLyfTlazS3qO2iNZTIjn60fpFYzbrgB
a3Ew3VxkNbA8DUVD04m7vWGRy5At08Cqe4UhIOuYk+JcSGemhhMfxg0OXPKc1iSO
+fBCtdvHWO0CgYAe996NSf0RPwUPq5oGm8lFyOPKQhI6D+imYBjrZEUBBtB03ASU
FCimGpWg7aJImuKfLyn8WsADZ6QpvzMgtlWJkR2t0kI4iRE7uzlANEDiLXghitGt
xDoDYZEGJZV3hR9TNKmz/W3qT+sCI6dUmZay5hpe3iqbPgL42U+f+wmEYQKBgCP6
gdJC99dg9aODrhw3KXhxpF6kS5aj6cIRXk/ngIaz6Q0wJE9fpunRJVG05gm/hwn4
bzVPIcD/4qOSl/ND0SgchWfZqSv9D7j5y1oeMogI++S9N6hsAg3WQ+cQOMATFUXo
NVS/sp/KOA5L2uZ0UXUQ2+HV8JumM9vVbRW855bBAoGBAJZ4WSbfNeD3uAZ+v+QN
X/qtt4o1QA/zdPdc9vS3EX+rMxBv8+A6XOUuNiJdkUB+obvv6fJ+pqhtWoat+Z+/
aN4hIrQe4saMBLSyVTrd5GXwevJs9qfpgXJZ4an7ociJJw+dxPDV4hFC19ulgmL5
3A+IiDkw+6uGS+6oL30qxPwh
-----END PRIVATE KEY-----

Output

Error: Error applying plan:

1 error occurred:
	* tls_self_signed_cert.foo: 1 error occurred:
	* tls_self_signed_cert.foo: failed to decode private_key_pem: asn1: structure error: tags don't match (2 vs {class:0 tag:16 length:13 isCompound:true}) {optional:false explicit:false application:false private:false defaultValue:<nil> tag:<nil> stringType:0 timeType:0 set:false omitEmpty:false}  @5

Expected Behavior

This resource must accepts both PKCS#1 and PKCS#8 formats for private_key_pem argument.

Workaround

Convert PKCS#8 format to PKCS#1 (thanks to coreos/tectonic-forum#153 (comment)):

openssl rsa -in private-key-pkcs8.pem -out private-key-pkcs1.pem

The "standard library" Terraform Providers should implement nascent provider development tooling to encourage consistency, foster automation where possible, and discover bugs/enhancements to that tooling. To that end, this provider's release process should be switched to goreleaser to match the documented Terraform Registry publishing recommendations. This includes:

• Creating necessary .goreleaser.yml and .github/workflows/release.yml configurations for tag-based releases (see also: TF-279 RFC)
• Ensuring necessary GitHub or Vault tokens are in place to fetch release secrets
• Ensuring provider and internal release process documentation is updated

I am not a huge fan of having private keys persisted in my state and both the tls_private_key resource and the tls_public_key data result in the private key being stored in the state file. In most cases this can be avoided by simply pre-generating the key pair and passing them in as variables but there is one case in which this is insufficient.

Namely, when attempting to use the acme_registration resource the key used to register becomes invalid after a terraform destroy thus it is especially helpful to have the key dynamically generated and stored in state for this use case.

My proposal would be to modify tls_private_key and tls_public_key to support RSA encrypted values for the private key attributes. Thus the use would be something like:

resource "tls_private_key" "private" {
  algorithm = "RSA"
  rsa_bits  = "4096"
  encryption_key = "${var.rsa_public_key}"
}

resource "tls_public_key" "public" {
  private_key_pem = "${rsadecrypt(tls_private_key.platform.private_key_pem, var.rsa_private_key}"
  encryption_key = "${var.rsa_public_key}"
}

If the encryption key is not provided then the state would contain the uncrypted keys thus maintaining backwards compatibility.

Terraform Version

$ terraform -v
Terraform v0.12.24
+ provider.azurerm v2.3.0
+ provider.local v1.4.0
+ provider.null v2.1.2
+ provider.tls v2.0.1

Affected Resource(s)

• tls_cert_request
• tls_locally_signed_cert
• https://github.com/hashicorp/terraform-provider-tls/blob/master/tls/resource_certificate.go

Terraform Configuration Files

[ need to create a minimal reproducible configuration ]

Debug Output

2020/04/02 16:00:23 [DEBUG] ReferenceTransformer: "tls_cert_request.int_ca" references: []
2020/04/02 16:00:23 [DEBUG] ReferenceTransformer: "module.REDACTED.tls_cert_request.this" references: []
2020/04/02 16:00:23 [DEBUG] ReferenceTransformer: "tls_self_signed_cert.root_ca" references: []
2020/04/02 16:00:23 [ERROR] <root>: eval: *terraform.EvalReadState, err: unsupported attribute "uris"
2020/04/02 16:00:23 [ERROR] <root>: eval: *terraform.EvalSequence, err: unsupported attribute "uris"
2020/04/02 16:00:23 [ERROR] <root>: eval: *terraform.EvalReadState, err: unsupported attribute "ready_for_renewal"
2020/04/02 16:00:23 [ERROR] <root>: eval: *terraform.EvalSequence, err: unsupported attribute "ready_for_renewal"
module.REDACTED.tls_cert_request.this: Refreshing state... [id=dced9383cfe02c4c488ad3464e70fc5eebce3838]

Error: unsupported attribute "ready_for_renewal"



Error: unsupported attribute "uris"

Panic Output

N/A

Expected Behavior

The SSL certificate should have been generated.

Actual Behavior

The following errors were returned:

Error: unsupported attribute "ready_for_renewal"
Error: unsupported attribute "uris"

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply -target=module.REDACTED.tls_locally_signed_cert.this

Important Factoids

Terraform state stored remotely in Azure Storage.

References

N/A

Hi there,
I am using tls_private_key resource to create aws key pairs on the fly. But the private keys are not masked in the terraform plan/apply output.
Could we have an attribute like sensitive = true if we want to mask the values in the plan/apply workflows.

This issue was originally opened by @apparentlymart as hashicorp/terraform#8766. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform Version

v0.7.4

Affected Resource(s)

• tls_cert_request

Terraform Configuration Files

Having no content in the subject block seems to cause a crash:

data "tls_cert_request" "foo" {
    subject {
    }
    key_algorithm = "RSA"
    private_key_pem = "${tls_private_key.foo.private_key_pem}"
}

Panic Output

panic: interface conversion: interface {} is nil, not map[string]interface {}
2016/09/10 09:51:34 [DEBUG] plugin: terraform: 
2016/09/10 09:51:34 [DEBUG] plugin: terraform: goroutine 85 [running]:
2016/09/10 09:51:34 [DEBUG] plugin: terraform: panic(0x3604820, 0xc820455440)
2016/09/10 09:51:34 [DEBUG] plugin: terraform:  /usr/lib/go-1.6/src/runtime/panic.go:481 +0x3e6
2016/09/10 09:51:34 [DEBUG] plugin: terraform: github.com/hashicorp/terraform/builtin/providers/tls.ReadCertRequest(0xc82011eba0, 0x0, 0x0, 0x0, 0x0)
2016/09/10 09:51:34 [DEBUG] plugin: terraform:  /.../src/github.com/hashicorp/terraform/builtin/providers/tls/data_source_cert_request.go:78 +0xd49
2016/09/10 09:51:34 [DEBUG] plugin: terraform: github.com/hashicorp/terraform/helper/schema.(*Resource).ReadDataApply(0xc820019b00, 0xc8203925e0, 0x0, 0x0, 0xc8200cbf68, 0x0, 0x0)
2016/09/10 09:51:34 [DEBUG] plugin: terraform:  /.../src/github.com/hashicorp/terraform/helper/schema/resource.go:207 +0x158
2016/09/10 09:51:34 [DEBUG] plugin: terraform: github.com/hashicorp/terraform/helper/schema.(*Provider).ReadDataApply(0xc82045c270, 0xc8202285c0, 0xc8203925e0, 0x1, 0x0, 0x0)
2016/09/10 09:51:34 [DEBUG] plugin: terraform:  /.../src/github.com/hashicorp/terraform/helper/schema/provider.go:315 +0x1da
2016/09/10 09:51:34 [DEBUG] plugin: terraform: github.com/hashicorp/terraform/plugin.(*ResourceProviderServer).ReadDataApply(0xc82014f580, 0xc82031cf70, 0xc82031d0a0, 0x0, 0x0)
2016/09/10 09:51:34 [DEBUG] plugin: terraform:  /.../src/github.com/hashicorp/terraform/plugin/resource_provider.go:537 +0x6a
2016/09/10 09:51:34 [DEBUG] plugin: terraform: reflect.Value.call(0x31e6620, 0x3c0dd58, 0x13, 0x3d89d90, 0x4, 0xc820127ed8, 0x3, 0x3, 0x0, 0x0, ...)
2016/09/10 09:51:34 [DEBUG] plugin: terraform:  /usr/lib/go-1.6/src/reflect/value.go:435 +0x120d
2016/09/10 09:51:34 [DEBUG] plugin: terraform: reflect.Value.Call(0x31e6620, 0x3c0dd58, 0x13, 0xc820127ed8, 0x3, 0x3, 0x0, 0x0, 0x0)
2016/09/10 09:51:34 [DEBUG] plugin: terraform:  /usr/lib/go-1.6/src/reflect/value.go:303 +0xb1
2016/09/10 09:51:34 [DEBUG] plugin: terraform: net/rpc.(*service).call(0xc820227f40, 0xc820227f00, 0xc82031dfa0, 0xc820338b80, 0xc82014fd40, 0x2a8b2c0, 0xc82031cf70, 0x16, 0x2a8b320, 0xc82031d0a0, ...)
2016/09/10 09:51:34 [DEBUG] plugin: terraform:  /usr/lib/go-1.6/src/net/rpc/server.go:383 +0x1c2
2016/09/10 09:51:34 [DEBUG] plugin: terraform: created by net/rpc.(*Server).ServeCodec
2016/09/10 09:51:34 [DEBUG] plugin: terraform:  /usr/lib/go-1.6/src/net/rpc/server.go:477 +0x49d

Expected Behavior

Terraform produces a user-friendly validation error, or perhaps just accepts the empty block because all of the subject attributes are documented as being optional.

Actual Behavior

Terraform crashed on an invalid type assertion.

Terraform Version

Latest master of both terraform and provider as of Feb 20 2018

Affected Resource(s)

tls_private_key

Terraform Configuration Files

resource tls_private_key "test" {
  algorithm = "RSA"
}

Output

Spencer-Brown:t12 spencer$ terraform apply

Error: Provider produced invalid plan

Provider "tls" planned an invalid value for tls_private_key.test.rsa_bits:
planned value cty.NumberIntVal(2048) does not match config value
cty.NullVal(cty.Number).

This is a bug in the provider, which should be reported in the provider's own
issue tracker.


Error: Provider produced invalid plan

Provider "tls" planned an invalid value for tls_private_key.test.ecdsa_curve:
planned value cty.StringVal("P224") does not match config value
cty.NullVal(cty.String).

This is a bug in the provider, which should be reported in the provider's own
issue tracker.

I'd like a new data source that would fetch remote TLS certificate information from a specified address and optional hostname (for SNI if the domain is an IP). It would include all the fields from #4, but also the certificate authority chain, and the fingerprint for the cert (and fingerprint on all certs in the CA chain).

Terraform Version

All versions

Affected Resource(s)

Relates to terraform-provider-aws for resources

• aws_iam_openid_connect_provider
• aws_eks_cluster and the OIDC issuer

Terraform Configuration Files

Example of desired configuration

data "aws_eks_cluster" "example" {
  name = "example"
}

# New Data Source
data "tls_remote_cert" "cluster_issuer" {
  address = "${data.aws_eks_cluster.example.identity.0.oidc.0.issuer}"
  # optional, for SNI if the endpoint is an IP
  hostname = "${data.aws_eks_cluster.example.identity.0.oidc.0.issuer}" 
  # optional
  port = 443
}

resource "aws_iam_openid_connect_provider" "example_cluster_issuer" {
  url = "${data.aws_eks_cluster.example.identity.0.oidc.0.issuer}"

  client_id_list = [
    "sts.amazonaws.com",
  ]

  thumbprint_list = [
    "${data.tls_remote_cert.cluster_issuer.authority_chain.0.fingerprint}"
  ]
}

Expected Behavior

I'd want all the fields from #4, plus a field fingerprint which would automate the process described in the AWS IAM docs to get the SHA1 Fingerprint of the certificate.

I would also want the authority_chain which is a list of the CAs in the chain, with item 0 being the root of the chain.

References

• #4

This issue was originally opened by @automaticgiant as hashicorp/terraform#13578. It was migrated here as part of the provider split. The original body of the issue is below.

Terraform Version

v0.9.2

Affected Resource(s)

Please list the resources as a list, for example:

• tls_cert_request

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "tls_private_key" "client" {
  algorithm = "RSA"
}
resource "tls_cert_request" "client" {
  key_algorithm   = "RSA"
  private_key_pem = "${tls_private_key.client.private_key_pem}"

  subject = {
    common_name         = "aCN"
    organizational_unit = ["OU1", "OU2", "OU3"]
  }
}

Expected Behavior

generate a csr with a subject with multiple OUs (consistent with an AD directory entry i want a cert for)

Actual Behavior

* tls_cert_request.client: subject.0.organizational_unit must be a single value, not a list

Steps to Reproduce

1. terraform apply

Important Factoids

idk, unless there's something non-standard about AD (haha what isn't, but i digress)

Hi !

By reviewing the code, I found a little mistake when creating a a CA self-signed certificate.
Resource: tls_self_signed_cert

https://github.com/terraform-providers/terraform-provider-tls/blob/cb21e556b00b4d8d5fc4073b941ddd5a9c2c0395/tls/resource_certificate.go#L169
Should AuthorityKeyId be set instead of SubjectKeyId when using is_ca_certificate?

This issue was originally opened by @trajano as hashicorp/terraform#20729. It was migrated here as a result of the provider split. The original body of the issue is below.

Current Terraform Version

$ terraform -v
Terraform v0.11.11

Use-cases

I want to use Terraform as a replacement for XCA to manage the certificates, but I don't want to generate new keys. I do not want to use data as it refers to existing data files for the keys instead I want them to be managed within Terraform state itself.

Attempted Solutions

$ terraform import module.certificate-authority.tls_private_key.ca CA_key.pem
module.certificate-authority.tls_private_key.ca: Importing from ID "CA_key.pem"...

Error: module.certificate-authority.tls_private_key.ca (import id: CA_key.pem): import module.certificate-authority.tls_private_key.ca (id: CA_key.pem): resource tls_private_key doesn't support import

Proposal

References

Terraform Version

Terraform v0.12.6

Affected Resource(s)

• tls_private_key
• Maybe other attributes as well

Terraform Configuration Files

resource "tls_private_key" "abc" {
  algorithm = "RSA"
  rsa_bits  = 2048
}

Expected Behavior

tls_private_key.abc.private_key_pem should not appear in the logs.

Actual Behavior

tls_private_key.abc.private_key_pem appears in the logs (e.g. when deleting the resource).

Steps to Reproduce

1. terraform apply
2. terraform destroy

Implementation

Never implemented a resource, but probably just as simple as setting Sensitive to true?

This issue was originally opened by @dtonnesen as hashicorp/terraform#16171. It was migrated here as a result of the provider split. The original body of the issue is below.

Hi there,

Thank you for opening an issue. Please note that we try to keep the Terraform issue tracker reserved for bug reports and feature requests. For general usage questions, please see: https://www.terraform.io/community.html.

If your issue relates to a specific Terraform provider, please open it in the provider's own repository. The index of providers is at https://github.com/terraform-providers .

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please try upgrading because your issue may have already been fixed.

Terraform v0.9.4 (built with kubernetes-anywhere don't know if upgrade is possible)

Terraform Configuration Files

Copy-paste your Terraform configurations here.

As this is kubernetes-anywhere I am not sure what config files are required.

For large Terraform configs, please use a service like Dropbox and

share a link to the ZIP file. For security, you can also encrypt the

files using our GPG public key.

### Debug Output
Full debug output can be obtained by running Terraform with the environment variable `TF_LOG=trace`. Please create a GitHub Gist containing the debug output. Please do _not_ paste the debug output in the issue, since debug output is long.

Debug output may contain sensitive information. Please review it before posting publicly, and if you are concerned feel free to encrypt the files using the HashiCorp security public key.

### Crash Output
If the console output indicates that Terraform crashed, please share a link to a GitHub Gist containing the output of the `crash.log` file.

https://gist.github.com/dtonnesen/23303cae480b917f3b7344d1b5cecb38#file-crash-log

### Expected Behavior
What should have happened?

Complete successfully

### Actual Behavior
What actually happened?

Crashed

### Steps to Reproduce
Please list the full steps required to reproduce the issue, for example:

1. Run **make deploy**

### Important Factoids
Are there anything atypical about your situation that we should know? For example: is Terraform running in a wrapper script or in a CI system? Are you passing any unusual command line options or environment variables to opt-in to non-default behavior?

Yes it runs in kubernetes-anywhere

### References
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

terraform version 0.11.4
provider version 1.1.0

will provide a repro later

Hi there,

I would be nice to have curve25519 supported

https://godoc.org/golang.org/x/crypto/curve25519

edit:

I have published a custom provider for now https://registry.terraform.io/providers/jackivanov/x25519/latest/docs

I would like existing SKI support to be extended to non-CA certificates. For RFC see https://tools.ietf.org/html/rfc5280#section-4.2.1.2. While the RFC says it is mandatory for CA's the way I read it they suggest using SKI with end entity certificates as well.

I came across this with etcd & OpenShift Origin combination where the etcd keys have SKI in the non-CA certificate.

Terraform Version

Terraform v0.11.3

• provider.tls v1.0.1

Terraform Version

Terraform 0.11.3
TLS provider 1.1.0

Affected Resource(s)

• tls_cert_request

Terraform Configuration Files

resource "tls_private_key" "ssl_private" {
  algorithm = "RSA"
  rsa_bits  = "2048"
}

resource "tls_cert_request" "ssl_request" {
  key_algorithm   = "${tls_private_key.ssl_private.algorithm}"
  private_key_pem = "${tls_private_key.ssl_private.private_key_pem}"

  subject {
    common_name = "*.example.com"
  }

  dns_names = ["*.example.com", "example.com"]
}

output "ssl_request" {
  value = "${tls_cert_request.ssl_request.cert_request_pem}"
}

Expected Behavior

Terraform generates a valid X.509 certificate request.

Actual Behavior

The certificate request cannot be used with an OpenSSL CA. An error "The string contains characters that are illegal for the ASN.1 type" is returned. I believe the certificate request is not formatted correctly.

Steps to Reproduce

1. terraform apply
2. terraform output ssl_request > request.pem
3. openssl ca [parameters] -in request.pem -out certificate.pem

Important Factoids

I think what's going on here is that Go is encoding the CommonName using the ASN.1 'PrintableString' character string type. The '*' character is not valid for this string type (see here). I verified the string type using this online ASN.1 decoder; sending another request generated by OpenSSL for the same commonName through the same decoder showed that CommonName was encoded using the 'UTF8String' character string type.

I'm not sure if Terraform can fix this or not. There is an 'ExtraNames' field in pkix.Name which can override CommonName, but it's not obvious whether you can pass something that Go will encode as a UTF8String instead of a PrintableString.

I was able to override the subject when using the request (e.g. -subj /CN=\*.example.com) to work around this. I think it's also valid to have a non-wildcard commonName and have a wildcard entry in the SAN field instead.

This issue was originally opened by @RichardKnop as hashicorp/terraform#8782. It was migrated here as part of the provider split. The original body of the issue is below.

Related to hashicorp/terraform#7821 (which is closed although the development version is still broken)

Refreshing state of tls_cert_request fails with error message.

This issue makes using tls_cert_request very problematic at the moment (having to pass -refresh=false to plan and apply is the only way to work around this).

Terraform Version

Terraform v0.7.4-dev (291f2985354454749e3e6da586c1ecd5d245c181)

Affected Resource(s)

• tls_cert_request

Debug Output

Error refreshing state: 7 error(s) occurred:

* tls_cert_request.registry: no PEM block found in private_key_pem
* tls_cert_request.client.0: no PEM block found in private_key_pem
* tls_cert_request.client.1: no PEM block found in private_key_pem
* tls_cert_request.client_server.0: no PEM block found in private_key_pem
* tls_cert_request.client_server.1: no PEM block found in private_key_pem
* tls_cert_request.server.0: no PEM block found in private_key_pem
* tls_cert_request.server.1: no PEM block found in private_key_pem

Expected Behavior

Terraform plan and/or apply should not fail with tls_cert_request resource. Otherwise this means tls_cert_request can only be used by passing -refresh=false flag around.

Refresh is effectively not possible when you have this resource in your manifests.

Actual Behavior

Terraform plan and apply fails during the refresh phase with the error message.

Steps to Reproduce

1. Initial terraform apply with tls_cert_request resource
2. terraform plan / terraform refresh / terraform apply all broken (during the refresh step)

Terraform Version

neil@xenial-vm:~$ terraform version
Terraform v0.11.7

Affected Resource(s)

• tls_self_signed_cert

Terraform Configuration Files

resource "tls_private_key" "k8s_etcd_ca" {
  algorithm = "RSA"
}

resource "tls_self_signed_cert" "k8s_etcd_ca" {
  key_algorithm   = "${tls_private_key.k8s_etcd_ca.algorithm}"
  private_key_pem = "${tls_private_key.k8s_etcd_ca.private_key_pem}"

  subject {
    common_name = "cert_name"
    organizational_unit = "etd"
  }

  validity_period_hours = 8160

  allowed_uses = [
    "key_encipherment",
    "digital_signature",
    "cert_signing",
  ]

  is_ca_certificate = true
}

Debug Output

https://gist.github.com/NeilW/9deaba372e62a45b6bf7ede83c7fb37b

Expected Behavior

Update or replace self-signed key

Actual Behavior

Error: Error applying plan:

1 error(s) occurred:

• tls_self_signed_cert.k8s_etcd_ca: 1 error(s) occurred:

• tls_self_signed_cert.k8s_etcd_ca: doesn't support update

Steps to Reproduce

1. terraform apply
2. Change organisational unit in TF file from etd to etcd
3. terraform apply

The "standard library" Terraform Providers should implement nascent provider development tooling to encourage consistency, foster automation where possible, and discover bugs/enhancements to that tooling. To that end, this provider's documentation should be switched to terraform-plugin-docs, including:

• Migrating directory structures and files as necessary
• Enabling automation for documentation generation (e.g. make gen or go generate ./...)
• Enabling automated checking that documentation has been re-generated during pull request testing (e.g. no differences)

Would be nice to support EdDSA/Ed25519 certificates. I tried to put together a PR, but without hackey workarounds, it looks like it's going to need some upstream changes in x509: golang/go#25355

This issue was originally opened by @martinssipenko as hashicorp/terraform#14856. It was migrated here as part of the provider split. The original body of the issue is below.

I would like to propose a new data source under TLS provider named tls_cert (or something like that).

Arguments:

• You would be able to either supply a path to TLS certificate as argument, or supply a PEM, which could be read by ${file('path/to/cert.pem')}.

Attributes:

• signature_algo
• public_key_algo
• serial_number (represented as integer)
• serial_number_hex (represented as hex delimited with :)
• is_ca
• version
• issuer
• subject
• not_before
• not_after

Possibly even more.

Please share your view on introducing such provider.

Terraform Version

Terraform v0.12.10
+ provider.tls v2.1.1

Affected Resource(s)

Please list the resources as a list, for example:

• tls_cert_request
• tls_self_signed_cert

Terraform Configuration Files

• fails:

  resource "tls_private_key" "this" {
    algorithm = "RSA"
  }
  resource "tls_self_signed_cert" "this" {
    early_renewal_hours   = 720
    key_algorithm         = "RSA"
    private_key_pem       = tls_private_key.this.private_key_pem
    validity_period_hours = 2160
  }

• fails:

  resource "tls_private_key" "this" {
    algorithm = "RSA"
  }
  resource "tls_self_signed_cert" "this" {
    early_renewal_hours   = 720
    key_algorithm         = "RSA"
    private_key_pem       = tls_private_key.this.private_key_pem
    validity_period_hours = 2160
    subject {}
  }

• fails:

  resource "tls_private_key" "this" {
    algorithm = "RSA"
  }
  resource "tls_self_signed_cert" "this" {
    early_renewal_hours   = 720
    key_algorithm         = "RSA"
    private_key_pem       = tls_private_key.this.private_key_pem
    validity_period_hours = 2160
    subject {
      common_name = "" # <--- note the empty string
    }
  }

• succeeds:

  resource "tls_private_key" "this" {
    algorithm = "RSA"
  }
  resource "tls_self_signed_cert" "this" {
    early_renewal_hours   = 720
    key_algorithm         = "RSA"
    private_key_pem       = tls_private_key.this.private_key_pem
    validity_period_hours = 2160
    subject {
      common_name = " " # <--- note the space... this is the kludge to get it to work
    }
  }

Expected Behavior

Terraform generates the tls_self_signed_cert resource with no subject field on the certificate, and Terraform demands no subject block at all.

Actual Behavior

Fails with this error when no subject block:
https://github.com/terraform-providers/terraform-provider-tls/blob/afd9e9546f57b662e375ef4146c0209e1b75c6f6/tls/resource_cert_request.go#L94

Fails with this error when an empty subject block:
https://github.com/terraform-providers/terraform-provider-tls/blob/afd9e9546f57b662e375ef4146c0209e1b75c6f6/tls/resource_cert_request.go#L98

Fails with this (same) error when subject block has single field explicitly set to an empty string common_name = "":
https://github.com/terraform-providers/terraform-provider-tls/blob/afd9e9546f57b662e375ef4146c0209e1b75c6f6/tls/resource_cert_request.go#L98

Steps to Reproduce

1. terraform apply with the first set of configs (labelled "fails") above.

Important Factoids

I believe this was introduced in #7. That issue is addressing a (valid) user behavior of providing no subject at all (#1) which had been causing a panic.

I think this all stems from type coercion:
https://github.com/terraform-providers/terraform-provider-tls/blob/afd9e9546f57b662e375ef4146c0209e1b75c6f6/tls/resource_cert_request.go#L96

... which is only necessary because subject is (unnecessarily) marked required:
https://github.com/terraform-providers/terraform-provider-tls/blob/afd9e9546f57b662e375ef4146c0209e1b75c6f6/tls/resource_cert_request.go#L71-L76

Of note, the code which parses the subject block's fields treats all of them as optional:
https://github.com/terraform-providers/terraform-provider-tls/blob/afd9e9546f57b662e375ef4146c0209e1b75c6f6/tls/provider.go#L35-L70

References

• https://tools.ietf.org/html/rfc5280#section-4.1.2.6 implies that an empty subject field is valid:

  Where it is non-empty, the subject field MUST contain an X.500
  distinguished name (DN)

Terraform Version

Latest

Affected Resource(s)

N/A

Terraform Configuration Files

N/A

Expected Behavior

As described here once the version of a go module hits greater than v1 the path needs changed.

https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher

Actual Behavior

The path of this provider has not been changed so the latest version can not be pulled by other projects/providers.

Steps to Reproduce

Important Factoids

This provider is being included in acme provider and it cannot move to the Terraform Plugin SDK until this fix has been made to this provider.

References

I have started a fix for this in PR #64

It would be nice to be able to add extensions (custom OIDs) to the signed certificate too like openssl allows:

e.g.

oid_section=new_oids
...
[ new_oids ]
CustomExtention=1.2.3.100.2.3
...
[ req_distinguished_name ]
CN=Blah Blah
0.CustomExtention=Example
...
[ req_ext ]
0.CustomExtentionAlternateLocation=Example

Terraform Version

Terraform v0.12.9
+ provider.tls v2.1.0

Affected Resource(s)

Please list the resources as a list, for example:

• tls_self_signed_cert
• probably all certificates with expiration time

Terraform Configuration Files

provider "tls" {
  version = "= 2.1.1"
}

resource "tls_private_key" "root_ca" {
  algorithm = "RSA"
  rsa_bits  = "4096"
}

resource "tls_self_signed_cert" "root_ca" {
  key_algorithm   = tls_private_key.root_ca.algorithm
  private_key_pem = tls_private_key.root_ca.private_key_pem

  subject {
    common_name  = "root-ca"
    organization = "example"
  }

  is_ca_certificate     = true

  // 2562047 ~= 290 * 365 * 24
  // https://golang.org/pkg/time/#Duration
  // 
  //validity_period_hours = 2562047
  validity_period_hours = 2562048

  allowed_uses = [
    "key_encipherment",
    "digital_signature",
    "cert_signing",
  ]
}

output "validity_end_time" {
  value = tls_self_signed_cert.root_ca.validity_end_time
}

Expected Behavior

Provider should return error to the user if user specifies wrong validity time of the certificate.

Actual Behavior

The validity end time of the certificate is in the past.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

1. terraform apply

Terraform Version

Terraform v0.11.9
+ provider.aws v1.46.0
+ provider.template v1.0.0
+ provider.tls v1.2.0

Affected Resource(s)

• tls_self_signed_cert
• tls_cert_request

Terraform Configuration Files

resource "tls_cert_request" "client" {
  key_algorithm   = "${tls_private_key.client.algorithm}"
  private_key_pem = "${tls_private_key.client.private_key_pem}"

  subject {
    common_name = "client"
  }

  # this is what's missing
  # rfc822 = "[email protected]"

  # or more easily 
  # subject {
  #  common_name = "client"
  # email_address = "[email protected]" 
  # this should generate the legacy support ones which is the email address as part of the subject but also add the rfc822 SAN 
  # }
}

Debug Output

n/a

Panic Output

n/a

Expected Behavior

Should support it so we can have name and email addresses to be assigned to client certificates.

Actual Behavior

n/a

Steps to Reproduce

n/a

Important Factoids

https://tools.ietf.org/html/rfc5280#section-4.1.2.6 talks about the emailAddresses

References

#27

I am trying to retrieve a certificate via the tls_certificate data source as per the example in the docs. This is in context of an OIDC provider for an EKS cluster running in a private VPC (no public network connectivity).

Given an OIDC issuer URL such as https://oidc.eks.eu-west-1.amazonaws.com/id/838DB18FA8EC26D87848FDEC1D50CFDC the call evetually fails with:

Error: dial tcp 34.248.140.150:443: connect: connection timed out

This is because of the private VPC and the fact that the data source does not support a HTTP proxy (there are unfortunately no EKS VPC endpoints currently).

Terraform Version

0.14.4

Affected Data Source(s)

• tls_certificate

Terraform Configuration Files

data "tls_certificate" "eks_cluster_oidc_issuer" {
  // E.g. https://oidc.eks.eu-west-1.amazonaws.com/id/838DB18FA8EC26D87848FDEC1D50CFDC
  url = aws_eks_cluster.eks_cluster.identity[0].oidc[0].issuer
}

Expected Behavior

The url should support using a HTTP proxy. Currently

Actual Behavior

Connection eventually times out (connection timed out)

References

Perhaps adjusting/replacing the dialer with something similar to:

• https://github.com/mwitkow/go-http-dialer
• https://gist.github.com/jim3ma/3750675f141669ac4702bc9deaf31c6b

The "standard library" Terraform Providers should implement nascent provider development tooling to encourage consistency, foster automation where possible, and discover bugs/enhancements to that tooling. To that end, this provider's CHANGELOG handling should be switched to go-changelog, including:

• Adding .changelog directory and template files
• Enabling automation for regenerating the CHANGELOG (e.g. scripts or GitHub Actions)
• (If enhancements are made available upstream in time) Enabling automation for checking CHANGELOG entries and formatting

Maintenance of the standard library providers prioritises stability and correctness relative to the provider's intended feature set. Create a design document describing this feature set, and any other design considerations which influence the architecture of the provider and what can and cannot be added to it.

Terraform Version

terraform 0.12
provider 2.2.0

Affected Resource(s)

• tls_private_key

Terraform Configuration Files

 resource "tls_private_key" "cert" {
   algorithm   = "RSA"
   rsa_bits    = "2048"
}

output "cert-thumprint" {
  value = "${tls_private_key.cert.thumbprint_sha1}"
}

this is useful for:
https://www.terraform.io/docs/providers/azurerm/r/batch_certificate.html

It would be useful to support generating a PKCS #12 (PKCS12 or also known as PFX) archive file out of PKI components, including an optional private key, and a chain of one or more certificates. The current set of TLS resources support generating/exporting to PEM format files, but there are many cases where a PFX archive file is preferred or required such as Windows host environments, Azure provider or Oracle OCI provider.

I recommend supporting this resource in a more general-purpose manner, such that you can give it an optional private key PEM, and one or more certificates (i.e. an array of certificate PEM clobs). By doing so, the resource would be usable in tandem with other resources of this provider, as well as alternate providers, such as the third-party ACME cert provider.

An example usage might look like this:

## Generate a self-signed cert using a private key stored on disk
resource "tls_self_signed_cert" "example" {
  key_algorithm   = "ECDSA"
  private_key_pem = "${file(\"private_key.pem\")}"

  subject {
    common_name  = "example.com"
    organization = "HCTF Examples, Inc"
  }

  validity_period_hours = 12

  allowed_uses = [
    "key_encipherment",
    "digital_signature",
    "server_auth",
  ]
}

## Produce a PKCS #12 archive of the self-signed cert (private key included)
resource "tls_pkcs12_archive" "example_pfx" {
  private_key_pem = "${file(\"private_key.pem\")}"
  certificate_pem = [
    "${tls_self_signed_cert.example.cert_pem}"
  ]
}

## Save the PKCS #12 archive to an S3 bucket
resource "aws_s3_bucket_object" "example_pfx_s3obj" {
    bucket = "${aws_s3_bucket.example_s3_bucket.id}"
    key    = "pki/example.pfx"

    content = <<EOF
${tls_pkcs12_archive.example_pfx.archive_blob}
EOF
}

Terraform Version

Terraform v0.11.3

Affected Resource(s)

provider.tls v1.1.0

This issue was originally opened by @dhanubiarca as hashicorp/terraform#23605. It was migrated here as a result of the provider split. The original body of the issue is below.

crash.log
Hi All,

I am new to Tectonic, I am trying to deploy tectonics on VMware environment, but could not succeed.

with little modifications in the provider files, I could able to run Plan, when run apply, terraform is getting crashed.
I have followed the below link:
https://coreos.com/tectonic/docs/latest/install/vmware/vmware-terraform.html

Here I am attaching the crash log, terraform.tfvar, provider.tf, varibale.tf files.
I am using terraform version v0.11.3
could someone help me in resolving the issue.

below is the crash output.

Tectonic_VMWARE.zip
Tectonic_VMWARE.zip

• tls_private_key.etcd_ca: unexpected EOF
  2018/02/05 16:54:42 [ERROR] root.etcd_certs: eval: *terraform.EvalSequence, err: 1 error(s) occurred:

• tls_private_key.etcd_ca: unexpected EOF
  2018/02/05 16:54:42 [TRACE] [walkApply] Exiting eval tree: module.etcd_certs.tls_private_key.etcd_ca
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.tls_self_signed_cert.etcd_ca"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.data.template_file.etcd_ca_cert_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.output.etcd_ca_crt_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.var.etcd_ca_cert_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.local_file.service_account_key"
  2018/02/05 16:54:42 [TRACE] root: eval: *terraform.EvalSequence
  2018/02/05 16:54:42 [TRACE] root: eval: terraform.EvalNoop
  2018/02/05 16:54:42 [TRACE] root: eval: *terraform.EvalOpFilter
  2018/02/05 16:54:42 [TRACE] root: eval: *terraform.EvalInterpolate
  2018/02/05 16:54:42 [TRACE] root: eval: *terraform.EvalVariableBlock
  2018/02/05 16:54:42 [TRACE] root: eval: *terraform.EvalCoerceMapVariable
  2018/02/05 16:54:42 [TRACE] root: eval: *terraform.EvalTypeCheckVariable
  2018/02/05 16:54:42 [TRACE] root: eval: *terraform.EvalSetVariables
  2018/02/05 16:54:42 [TRACE] [walkApply] Exiting eval tree: module.identity_certs.var.ca_key_pem
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.identity_certs.tls_locally_signed_cert.identity_client"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.identity_certs.output.client_cert_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.tectonic.var.identity_client_cert_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.tls_locally_signed_cert.etcd_server"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.output.etcd_server_crt_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd.var.tls_server_crt_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd.data.ignition_file.etcd_server_crt"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.tls_locally_signed_cert.etcd_client"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.data.template_file.etcd_client_crt"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.output.etcd_client_crt_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd.var.tls_client_crt_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd.data.ignition_file.etcd_client_crt"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.tls_locally_signed_cert.etcd_peer"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.data.archive_file.etcd_tls_zip"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.output.etcd_tls_zip"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.local_file.etcd_ca_crt"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd.var.tls_ca_crt_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd.data.ignition_file.etcd_ca"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.kube_certs.local_file.kubelet_key"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.identity_certs.tls_locally_signed_cert.identity_server"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.identity_certs.output.server_cert_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.tectonic.var.identity_server_cert_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.tectonic.template_dir.tectonic"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.tectonic.output.id"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "provider.tls (close)"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.local_file.etcd_server_crt"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.local_file.etcd_client_crt"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.var.etcd_client_cert_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.template_dir.bootkube"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.output.etcd_peer_crt_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd.var.tls_peer_crt_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd.data.ignition_file.etcd_peer_crt"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.local_file.etcd_peer_crt"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.etcd_certs.output.id"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.kube_certs.output.kubelet_key_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.var.kubelet_key_pem"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.data.template_file.kubeconfig"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.output.kubeconfig"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.masters.var.kubeconfig"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.masters.vsphere_virtual_machine.node"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.masters.output.ip_address"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "null_resource.bootstrap"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "provider.null (close)"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.template_dir.bootkube_bootstrap"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "provider.ignition (close)"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.local_file.kubeconfig"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.workers.var.kubeconfig"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.workers.vsphere_virtual_machine.node[0]"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "provider.template (close)"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.bootkube.output.id"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "data.archive_file.assets"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "provider.archive (close)"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.workers.vsphere_virtual_machine.node1"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.workers.output.ip_address"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "provider.vsphere (close)"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "provisioner.remote-exec (close)"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "provisioner.file (close)"
  2018-02-05T16:54:42.483+0530 [DEBUG] plugin: plugin process exited: path=/root/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster/.terraform/plugins/linux_amd64/terraform-provider-tls_v1.0.0_x4
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalDiff
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalReadDiff
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalCompareDiff
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalGetProvider
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalReadState
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalApplyPre
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalApply
  2018/02/05 16:54:42 [DEBUG] apply: local_file.kube_ca_crt: executing Apply
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalWriteState
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalApplyProvisioners
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalIf
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalWriteState
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalWriteDiff
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalApplyPost
  2018/02/05 16:54:42 [TRACE] root.kube_certs: eval: *terraform.EvalUpdateStateHook
  2018/02/05 16:54:42 [TRACE] Preserving existing state lineage "73f05e45-1e01-4bfb-896f-43553f11cbce"
  2018/02/05 16:54:42 [TRACE] [walkApply] Exiting eval tree: module.kube_certs.local_file.kube_ca_crt
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "module.kube_certs.output.id"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "meta.count-boundary (count boundary fixup)"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "provider.local (close)"
  2018/02/05 16:54:42 [TRACE] dag/walk: upstream errored, not walking "root"
  2018/02/05 16:54:42 [TRACE] Preserving existing state lineage "73f05e45-1e01-4bfb-896f-43553f11cbce"
  2018/02/05 16:54:42 [DEBUG] plugin: waiting for all plugin processes to complete...
  2018-02-05T16:54:42.561+0530 [WARN ] plugin: error closing client during Kill: err="connection is shut down"
  2018-02-05T16:54:42.575+0530 [DEBUG] plugin: plugin process exited: path=/root/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster/.terraform/plugins/linux_amd64/terraform-provider-null_v1.0.0_x4
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin: plugin process exited: path=/root/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster/.terraform/plugins/linux_amd64/terraform-provider-local_v1.0.0_x4
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin: plugin process exited: path=/root/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster/.terraform/plugins/linux_amd64/terraform-provider-archive_v1.0.0_x4
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin: plugin process exited: path=/root/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster/.terraform/plugins/linux_amd64/terraform-provider-vsphere_v0.4.2_x4
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin: plugin process exited: path=/root/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster/.terraform/plugins/linux_amd64/terraform-provider-template_v1.0.0_x4
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin: plugin process exited: path=/root/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster/.terraform/plugins/linux_amd64/terraform-provider-ignition_v0.1.0_x4
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin: plugin process exited: path=/root/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster/.terraform/plugins/linux_amd64/terraform-provider-random_v1.0.0_x4
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin.terraform: remote-exec-provisioner (internal) 2018/02/05 16:54:42 [DEBUG] plugin: waiting for all plugin processes to complete...
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin: plugin process exited: path=/usr/bin/terraform
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin.terraform: file-provisioner (internal) 2018/02/05 16:54:42 [DEBUG] plugin: waiting for all plugin processes to complete...
  2018-02-05T16:54:42.576+0530 [DEBUG] plugin: plugin process exited: path=/usr/bin/terraform

!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!

Terraform crashed! This is always indicative of a bug within Terraform.
A crash log has been placed at "crash.log" relative to your current
working directory. It would be immensely helpful if you could please
report the crash with Terraform1 so that we can fix this.

When reporting bugs, please include your terraform version. That
information is available on the first line of crash.log. You can also
get it by running 'terraform --version' on the command line.

!!!!!!!!!!!!!!!!!!!!!!!!!!! TERRAFORM CRASH !!!!!!!!!!!!!!!!!!!!!!!!!!!!
root@ubuntuvm:~/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster# terraform --version
Terraform v0.11.3

• provider.archive v1.0.0
• provider.external v1.0.0
• provider.ignition v0.1.0
• provider.local v1.0.0
• provider.null v1.0.0
• provider.random v1.0.0
• provider.template v1.0.0
• provider.tls v1.0.0
• provider.vsphere v0.4.2

root@ubuntuvm:~/tec_vm2/tectonic_1.8.4-tectonic.3/build/bcluster#

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!

The TLS provider should support the ability to set CRL and OCSP endpoints when creating locally signed (CA signed) certificates. Currently there is no way to set this using the provider, and as a result, the only way to do this would be using tools outside of Terraform such as OpenSSL CLI.

Terraform Version

Run terraform -v to show the version. If you are not running the latest version of Terraform, please upgrade because your issue may have already been fixed.

Affected Resource(s)

Please list the resources as a list, for example:

• tls_locally_signed_cert

If this issue appears to affect multiple resources, it may be an issue with Terraform's core, so please mention this.

Terraform Configuration Files

resource "tls_locally_signed_cert" "example" {
  cert_request_pem   = "${file("cert_request.pem")}"
  ca_key_algorithm   = "ECDSA"
  ca_private_key_pem = "${file("ca_private_key.pem")}"
  ca_cert_pem        = "${file("ca_cert.pem")}"

  validity_period_hours = 12

  allowed_uses = [
    "key_encipherment",
    "digital_signature",
    "server_auth",
  ]
}

Code taken from the example resource in the provider documentation.

Debug Output

N/A

Panic Output

N/A

Expected Behavior

Expect to be able to provide CRL Info similar to OpenSSL config, e.g.

crl_info {
  uris = [
    "crl1.example.com",
    "crl2.example.org",
  ]
}

Actual Behavior

Requested functionality does not currently exist.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:
N/A - Feature request

Important Factoids

Are there anything atypical about your accounts that we should know? For example: Running in EC2 Classic? Custom version of OpenStack? Tight ACLs? N/A

References

• relates and partially overlaps with #20

In resource tls_self_signed_cert it'll be helpful to define SignatureAlgorithm.
For example, currently Spring Security OAuth only support sha1WithRSAEncryption...

Provider should support setting URIs within the subject alternative name in the same way as it supports setting DNS names and IP addresses.

Affected Resource(s)

Please list the resources as a list, for example:

• tls_cert_request
• tls_self_signed_cert

Propose adding a uris attribute to the resources that takes a list of strings that results in the URI being parsed and stored in the X509 CertificateRequest/Certificate URIs field.

Terraform Version

terraform -v
Terraform v0.13.2
+ provider registry.terraform.io/hashicorp/tls v2.2.0

Affected Resource(s)

Please list the resources as a list, for example:

• tls_certificate

Terraform Configuration Files

data "tls_certificate" "oidc_idp" {
  url = "https://oidc.eks.sa-east-1.amazonaws.com/id/<REDACTED>"
}

Expected Behavior

Consistent id across consecutive plans.

Actual Behavior

Resource id changes every plan even if certificates are the same.

...
      ~ id           = "2020-09-14 19:34:14.498463939 +0000 UTC" -> "2020-09-14 19:34:14.722109742 +0000 UTC"
...

Steps to Reproduce

1. terraform plan .
2. terraform apply .
3. terraform plan .

Important Factoids

Obviously, this is the behavior given by this line.
Is this intentional? Could it be something stable, like the certificate's serial number or sha1 fingerprint?

Out of curiosity, how often is this provider module updated? With my recent PR being merged, I'd love to be able to start using it.
Trying to get an idea of the schedule behind this.

Thanks
/cc @vancluever @apparentlymart

Terraform Version

Terraform v0.11.10

Affected Resource(s)

• data tls_public_key

Terraform Configuration Files

data "tls_public_key" "example" {
  private_key_pem = "corrupt"
}

Panic Output

https://gist.github.com/harryrose/7332ec751d8a63281095a5f24fd3c54b

Expected Behavior

What should have happened?
Graceful error message

Actual Behavior

What actually happened?
Panic

Steps to Reproduce

1. terraform apply

Important Factoids

Fixed locally, raising this bug to give something to anchor it to. Will raise a PR.

Terraform Version

Terraform v0.11.14
+ provider.tls v2.2.0

Affected Resource(s)

tls_certificate

Terraform Configuration Files

data "tls_certificate" "cert" {
  url = "https://hashicorp.com"
}

output "cert1-root-cert" {
  value = "${data.tls_certificate.cert.certificates.0.raw}"
}

Expected Behavior

Ability to get PEM encoded certificates in chain.

Please add support for adding issuer into AKI. Right now it automatically contains just the keyid.
An example

        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:36:42:90:48:8A:7B:44:9A:73:B9:5D:E2:AB:90:03:A6:9D:CE:7F:D1
                DirName:/CN=etcd-signer@1512497667
                serial:87:A9:79:FE:EE:EA:7E:8B

Terraform Version

Terraform v0.11.4

• provider.tls v1.1.0

Description

Please could you add support for Apple Silicon (aka release darwin/arm64 binaries) - this would require adopting Go 1.16

References

Goes along with hashicorp/terraform#27257

Equivalent to hashicorp/terraform-provider-aws#16948

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

When the private_key_pem attribute is set on a tls_self_signed_cert, and the provided value is read back out of the resource, the returned result is a hash of the supplied private key instead of the supplied private key itself.

Terraform Version

• Terraform v0.13.5
• registry.terraform.io/hashicorp/tls v3.0.0

Affected Resource(s)

• tls_locally_signed_cert
  • .cert_request_pem
  • .ca_private_key_pem
  • .ca_cert_pem
  • .private_key_pem
• tls_self_signed_cert
  • .private_key_pem

Terraform Configuration Files

N/A

Debug Output

https://gist.github.com/jgoldschrafe/6c619e5e0e36d396aaf4a9cec502a70b

Expected Behavior

The private_key_pem attribute should contain the value that was set on the resource.

Actual Behavior

The private_key_pem attribute contains a hash of the value that was set on the resource.

Steps to Reproduce

resource "tls_private_key" "root_ca" {
  algorithm = "RSA"
  rsa_bits  = 2048
}

resource "tls_self_signed_cert" "root_ca" {
  key_algorithm   = "RSA"
  private_key_pem = tls_private_key.root_ca.private_key_pem

  subject {
    common_name = "blah"
  }

  allowed_uses = [
    "key_encipherment",
    "digital_signature",
    "server_auth",
    "cert_signing",
    "crl_signing",
  ]

  is_ca_certificate     = true
  validity_period_hours = 2160
}

resource "local_file" "original_value" {
  filename = "original-value.log"
  content  = tls_private_key.root_ca.private_key_pem
}

resource "local_file" "reread_value" {
  filename = "reread-value.log"
  content  = tls_self_signed_cert.root_ca.private_key_pem
}

$ terraform apply -auto-approve
...
$ cat original-value.log
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEA6Ec9vmKkZMyG+kYLDIoq+KM2h4n3dWNui9RZzF+0e9PkKLWO
BoSxsSeH/TKmlFsx2Ulsk7CBktclquh3Cmphp8cKE+n87Q1afodfrRpaoouWygoS
UDqcxknCrlF3qhuEbWb4g2UVrUJgIwKBCTdB+/l78RceAlQPhImnT1eSAltc4/t7
CgHB5A0NUK+ZfiPtu6Lls5+PGUXf7mgCc1Wh/lXopZllc8U1HgynXd9jEpNzM/tN
0k1pC5mv79bbkBwx1cIf2B9vtA3ISxWTShVuh8i3O+SwoDjfPWzHNHd+SvDQDpvX
2WLulKp4QDFf9+BuJaVATLNEYidiHNfKJ+AFvwIDAQABAoIBAQDjco9FVHZBtf0e
KWQ8XTeCzN9ijXjhXAItrjxYYgbrkitCqbVvMJSHMnx5NRXlA/+mE73cSOQ4k7Bw
0L1wV4dUsRRvN5rRzVeluo23hazmqeV35bDVGu/VQvj9lQymZ9efAUur7lnxlKNq
5NLR4WgdgskY5VgfU4z2bYyFpux0nIB5+M43cgodku3nvDU//4Io+6d59MuSIRgi
PqFM8gbMtNdgRM2oPBJoBwsTo0RYG6ZZcOGttU5tF0hDi0v9ebO/5t5x+k3nTAJk
bY7ntnyE2sbX1bwV4HaU/vduo3gMuN+B4y3FZy6nVaCIizu0eOa7OKTQ2ZA7PtpL
Mlbgv3nBAoGBAPozLYZicaeOdSZZmMN5asBDlKnWkdQOScUtk1DF9bjTv0NZfzlQ
YDe4wZi/vsTXnf66ULLim6yitbPFG/raILR3MJxVxBT59HPg5XDh2vWnwXGUYwaJ
RDFlqJrG93fFUwEDVdd7cz6NxhGIRaPc+iVRGDmpxtlJDAFE9cZQkXQvAoGBAO2p
tOk4etm0H8p0v0Mc7zri8yEzl+B/VG5qmzAu2W3wPpjEU5/gHU9ldoKzCYVdShxq
EF00rcUtIlqigIrQNVPcHt87gaijAIjOfdRwIyibpCKD8eM7W84LopVJyRytS/+O
nht1fg9v/UUpNrjPq26C50Ks2uCx83j+UeDqZ9NxAoGBANvu6uDLXo7kihRJBCEo
dO9HOMJGzG+0k6JRWsLRERwEfodsf4pZHgs9TGjCfKY5xzeofdGRoziQ2tqItPzA
i6k3cLKsLa4mvnyyP94Hm1r/uOrnfli7hwdJDnnn1pchDMLCNM4zRW3CYE7/FABj
+judWoctt48/R99ByC4omoOfAoGBALuhK66kZHjTd/XCTe2SPlxjKEeiD9mxLNsv
Vu2nTwk4jnLVLKAfs4QnOnTdHDsp94SPR/QNztLIW0Lq4Ei3MCLQuZ7LwAV/CsD3
JOg+z8MTfXWybZlUF5qIHQd3hUsaldFgqvpKvAc8Btw/OXCWo2VP+3vsM7EJTIrN
XZ8P8IBBAoGAGeYKfFAMa9zOB3T8mrzm+BL5z6OqeuQ72De6nr7nOCC9aSc/udn+
Z3kUsqk/ntjLQGBod/lSW6iNz8kUGS/fDFE65af01Ut7nuRVQZt6NpAgFQmxLUpF
WdKA4xtm3Ae91+jMdd7u+8l6tvOBZkJaDNszccdi5Hbks3h8g9ZkFGY=
-----END RSA PRIVATE KEY-----
$ cat reread-value.log
1372d7d00099cdea83e13bff4a1892daa201ee6f

Important Factoids

This does not appear to be an issue related to the general handling of sensitive attribute values in Terraform; I was unable to reproduce it using a different provider that permits setting and re-reading sensitive attributes, like local_file.

References

N/A

Use case is the following:
If you have a server which requires a valid certificate to log in, you would also want to keep the CRL of the revoked certificates in order to prevent the deleted users get authorized.

When you iterate over a list with users, you need to create new certificates for new users and revoke the certificates for the deleted users, which have disappeared from the list.

I'm not sure whether the current architecture of the terraform states allows us to keep the history of changes, but we need to think about generating the CRL somehow. In theory, we may use some kind of index file to keep the history of certificates.

Currently, when you iterate over a list with users, terraform will destroy resources for disappeared users. As a solution we might iterate over a map instead and do something like this (some kind of the index file in a variable)

users = {
  "1"  = "user1"
  "2"  = "user2"
  "3"  = false # user3 retired
}

resource "tls_locally_signed_cert" "client" {
  count                 = "${length(var.users)}"
  ...
  is_valid              = "${lookup(var.users, count.index+1) == 0 ? 0 : 1}"
}

If is_valid true, CRL will be generated in a new attribute