github.com/turtlemonvh/terraform@v0.6.9-0.20151204001754-8e40b6b855e8/website/source/docs/providers/tls/r/self_signed_cert.html.md (about) 1 --- 2 layout: "tls" 3 page_title: "TLS: tls_self_signed_cert" 4 sidebar_current: "docs-tls-resourse-self-signed-cert" 5 description: |- 6 Creates a self-signed TLS certificate in PEM format. 7 --- 8 9 # tls\_self\_signed\_cert 10 11 Generates a *self-signed* TLS certificate in PEM format, which is the typical 12 format used to configure TLS server software. 13 14 Self-signed certificates are generally not trusted by client software such 15 as web browsers. Therefore clients are likely to generate trust warnings when 16 connecting to a server that has a self-signed certificate. Self-signed certificates 17 are usually used only in development environments or apps deployed internally 18 to an organization. 19 20 This resource is intended to be used in conjunction with a Terraform provider 21 that has a resource that requires a TLS certificate, such as: 22 23 * ``aws_iam_server_certificate`` to register certificates for use with AWS *Elastic 24 Load Balancer*, *Elastic Beanstalk*, *CloudFront* or *OpsWorks*. 25 26 * ``heroku_cert`` to register certificates for applications deployed on Heroku. 27 28 ## Example Usage 29 30 ``` 31 resource "tls_self_signed_cert" "example" { 32 key_algorithm = "ECDSA" 33 private_key_pem = "${file(\"private_key.pem\")}" 34 35 subject { 36 common_name = "example.com" 37 organization = "ACME Examples, Inc" 38 } 39 40 validity_period_hours = 12 41 42 allowed_uses = [ 43 "key_encipherment", 44 "digital_signature", 45 "server_auth", 46 ] 47 } 48 ``` 49 50 ## Argument Reference 51 52 The following arguments are supported: 53 54 * `key_algorithm` - (Required) The name of the algorithm for the key provided 55 in `private_key_pem`. 56 57 * `private_key_pem` - (Required) PEM-encoded private key data. This can be 58 read from a separate file using the ``file`` interpolation function. If the 59 certificate is being generated to be used for a throwaway development 60 environment or other non-critical application, the `tls_private_key` resource 61 can be used to generate a TLS private key from within Terraform. Only 62 an irreversable secure hash of the private key will be stored in the Terraform 63 state. 64 65 * `subject` - (Required) The subject for which a certificate is being requested. This is 66 a nested configuration block whose structure is described below. 67 68 * `validity_period_hours` - (Required) The number of hours after initial issuing that the 69 certificate will become invalid. 70 71 * `allowed_uses` - (Required) List of keywords each describing a use that is permitted 72 for the issued certificate. The valid keywords are listed below. 73 74 * `dns_names` - (Optional) List of DNS names for which a certificate is being requested. 75 76 * `ip_addresses` - (Optional) List of IP addresses for which a certificate is being requested. 77 78 * `early_renewal_hours` - (Optional) If set, the resource will consider the certificate to 79 have expired the given number of hours before its actual expiry time. This can be useful 80 to deploy an updated certificate in advance of the expiration of the current certificate. 81 Note however that the old certificate remains valid until its true expiration time, since 82 this resource does not (and cannot) support certificate revocation. Note also that this 83 advance update can only be performed should the Terraform configuration be applied during the 84 early renewal period. 85 86 * `is_ca_certificate` - (Optional) Boolean controlling whether the CA flag will be set in the 87 generated certificate. Defaults to `false`, meaning that the certificate does not represent 88 a certificate authority. 89 90 The `allowed_uses` list accepts the following keywords, combining the set of flags defined by 91 both [Key Usage](https://tools.ietf.org/html/rfc5280#section-4.2.1.3) and 92 [Extended Key Usage](https://tools.ietf.org/html/rfc5280#section-4.2.1.12) in 93 [RFC5280](https://tools.ietf.org/html/rfc5280): 94 95 * `digital_signature` 96 * `content_commitment` 97 * `key_encipherment` 98 * `data_encipherment` 99 * `key_agreement` 100 * `cert_signing` 101 * `encipher_only` 102 * `decipher_only` 103 * `any_extended` 104 * `server_auth` 105 * `client_auth` 106 * `code_signing` 107 * `email_protection` 108 * `ipsec_end_system` 109 * `ipsec_tunnel` 110 * `ipsec_user` 111 * `timestamping` 112 * `ocsp_signing` 113 * `microsoft_server_gated_crypto` 114 * `netscape_server_gated_crypto` 115 116 ## Attributes Reference 117 118 The following attributes are exported: 119 120 * `cert_pem` - The certificate data in PEM format. 121 * `validity_start_time` - The time after which the certificate is valid, as an 122 [RFC3339](https://tools.ietf.org/html/rfc3339) timestamp. 123 * `validity_end_time` - The time until which the certificate is invalid, as an 124 [RFC3339](https://tools.ietf.org/html/rfc3339) timestamp. 125 126 ## Automatic Renewal 127 128 This resource considers its instances to have been deleted after either their validity 129 periods ends or the early renewal period is reached. At this time, applying the 130 Terraform configuration will cause a new certificate to be generated for the instance. 131 132 Therefore in a development environment with frequent deployments it may be convenient 133 to set a relatively-short expiration time and use early renewal to automatically provision 134 a new certificate when the current one is about to expire. 135 136 The creation of a new certificate may of course cause dependent resources to be updated 137 or replaced, depending on the lifecycle rules applying to those resources.