Need to figure out if we support Keyless SSL from within this resource or a separate resource.
One thought is having private key be either the PEM or the key server details. In the future, key server itself will be a proper resource so we should plan for this change accordingly.
To clarify your issue a little bit (and please excuse my ignorance with all the SSL/TLS offerings from Cloudflare available).
Are you talking about custom certificates in the context of https://api.cloudflare.com/#custom-ssl-for-a-zone-properties? Aka, upload your own certificate in the UI?
If so, we might be able to do a similar thing to how Filters and Firewall Rules are composed whereby it is actually two resources but they reference one another. Here is an example of the filter based firewall rules.
resource "cloudflare_filter" "wordpress" {
zone_id = "d41d8cd98f00b204e9800998ecf8427e"
description = "Wordpress break-in attempts that are outside of the office"
expression = "(http.request.uri.path ~ \".*wp-login.php\" or http.request.uri.path ~ \".*xmlrpc.php\") and ip.src ne 192.0.2.1"
}
resource "cloudflare_firewall_rule" "wodpress" {
zone_id = "d41d8cd98f00b204e9800998ecf8427e"
description = "Block wordpress break-in attempts"
filter_id = "${cloudflare_filter.wordpress.id}"
action = "block"
}
(full documentation: https://www.terraform.io/docs/providers/cloudflare/r/firewall_rule.html)
In the case of custom certificates, perhaps something like this would work?
resource "cloudflare_custom_certificate" "test_cert" {
certificate = "-----BEGIN CERTIFICATE-----\nMIIDtTCCAp2gA...4rzaskDJY5L6xmY=\n-----END CERTIFICATE-----\n"
private_key = "-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAK...EePXpDMpY7HQpoLDi\n-----END RSA PRIVATE KEY-----\n"
bundle_method = "ubiquitous"
}
resource "keyless_ssl" "my_keyless_ssl" {
# pull the attributes and values in from
# https://api.cloudflare.com/#keyless-ssl-for-a-zone-properties
certificate_id = "${cloudflare_custom_certificate.test_cert.id}"
}
There are a couple of things to consider here:
private_key attribute as sensitive and potentially don't store it in the state file and all updates to that resource trigger a recreation. I don't think this sensitive material should live in a state file (especially in the way most people store it). If we must store it, perhaps a checksum (sha256/512) of the key contents would suffice.Taking this approach also means we could separate the keyless_ssl_key_server into it's own resource and again just reference the ID in the keyless_ssl when support is added.
WDYT?
I'd very much like to see support for the v4/certificates API in the provider.
Perhaps worth relying on the existing tls_private_key and tls_cert_request resources as a starting point to move this forward?
For those of us who want to configure encryption along the whole path between Cloudflare and the origin, with Cloudflare handling the edge certificates (ie. 'Full' mode), it'd be very useful to configure origin certificates from Terraform - ie. this:

Merged #418.
Most helpful comment
For those of us who want to configure encryption along the whole path between Cloudflare and the origin, with Cloudflare handling the edge certificates (ie. 'Full' mode), it'd be very useful to configure origin certificates from Terraform - ie. this: