provider/tls: add locally signed certificates

[silas]

This allows you to generate and sign certificates using a local CA.

It's based on tls_self_signed_cert and shares much of the code, tests, and docs.

Example

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

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

    subject {
        common_name = "ca"
    }

    validity_period_hours = 24

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

    is_ca_certificate = true
}

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

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

    subject {
        common_name = "client"
    }
}

resource "tls_locally_signed_cert" "test" {
    cert_request_pem = "${tls_cert_request.test.cert_request_pem}"

    ca_key_algorithm = "${tls_private_key.ca.algorithm}"
    ca_private_key_pem = "${tls_private_key.ca.private_key_pem}"
    ca_cert_pem = "${tls_self_signed_cert.ca.cert_pem}"

    validity_period_hours = 12

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

[apparentlymart]

Awesome! Thanks for working on this.

This looked great to me on a first pass, though I didn't get a chance to test it for real yet.

Given the similarity between tls_self_signed_cert and tls_locally_signed_cert I wonder if we could factor out most of the code to be shared between the two. The main differences seem to be:

• Locally-signed cert wants some additional arguments to provide the CA cert, whereas for self-signed cert it's implied that the cert will sign itself. This introduces some minor differences to the schema and the argument-decoding part of Create.
• Locally-signed cert uses a different cert to sign the generated certificate.

Recently I worked on a family of resources in the AWS provider: aws_ami, aws_ami_copy and aws_ami_from_instance. These shared a similar property that they have a very similar schema and differ only in some details of the Create implementation. In that case I made a function to dynamically produce a schema based on some arguments representing the differences between the cases, and then I wrote a different Create for each but had them all share the same Read and Delete implementations.

My intuition is telling me that if we were to add tls_certificate into the mix for ACME-registered certificates then it could also share part of the implementation here; although the Create would be significantly different (since most of the work is done on the ACME server in that case), the schema would have some similarities (I'd still include early_renewal_hours, for example) and Read and Delete would be the same again.

Do you think we could use a similar pattern here as I did for the AMI resources?

I'm thinking of creating a resource_certificate.go file that would later become the ACME certificate resource but for now would just be home to the schema-building function, to the shared Read and Delete implementations, and to a "take a schema.ResourceData and return a x509.Certificate" function that could be shared between tls_self_signed_cert and tls_locally_signed_cert. The separate resource_self_signed_cert.go and resource_locally_signed_cert.go files would then be pretty small, including only the stuff that's unique to those particular resources.

[silas]

Sure, I'll review aws_ami* and update the pull request.

Thanks for taking a look!

[silas]

Updated, let me know if that's what you were thinking.

I also created a util.go file and moved some of the shared pem/x509 decoding/parsing code into it.

[apparentlymart]

Sorry for the delay on this one. Looking good! 🚢

[silas]

Awesome, thanks! Looking forward to the ACME as well.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.