Hi @todd-dsm,
The typical way we address problems like this in Terraform is to have a standard/conventional representation of any kind of value that tends to cross provider boundaries. In this case it’s conventional in Terraform to use a PEM representation for certificates and other related objects like private keys. This is a similar principle to how timestamps in Terraform should always be represented as RFC 3339 strings, so that timestamps from one provider can be sent to another without the visual noise of format conversion directly in the Terraform configuration.
Unfortunately it seems that the azuread_service_principal_token_signing_certificate
resource type is not following that convention. The way I’d expect to solve this is for that resource type to offer the standard PEM encoding as one of its attributes so that this would’ve worked the way you expected it to work, and so it might be worth opening a feature request for that in the provider’s repository if there isn’t one already.
In the meantime, I see in the documentation that this value
attribute is explicitly documented as being a PEM string without the PEM envelope:
value
- The certificate data, which is PEM encoded but does not include the header-----BEGIN CERTIFICATE-----\n
or the footer\n-----END CERTIFICATE-----
.
Based on that documentation, it should be safe to template in the PEM envelope markers yourself, if this is indeed “PEM encoded but without the header”:
resource "okta_idp_saml_key" "idp_signing_key" {
x5c = [
<<-EOT
-----BEGIN CERTIFICATE-----
${azuread_service_principal_token_signing_certificate.saml_signing_cert.value}
-----END CERTIFICATE-----
EOT
]
}
Hopefully a future version of this provider can offer an additional value_pem
attribute that comes with these extra markers already present so that the string is compatible with what other providers will typically expect, but until then this should hopefully get the effect you wanted.