Cross-regional Internal HTTPS Load Balancer Certificate Manager Compatibility doesn't work with proxy resource

[dgulli]

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.
• If an issue is assigned to the modular-magician user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to hashibot, a community member has claimed the issue already.

Terraform Version

Terraform v1.5.7

Affected Resource(s)

google_compute_target_https_proxy

Terraform Configuration Files

resource "google_compute_target_https_proxy" "gil7-https-proxy" {
  name             = "gil7-https-proxy"
  url_map        = google_compute_url_map.gil7-map.id
  project          = var.project-name
  provider        = google-beta.beta
  //id is taken as per https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/certificate_manager_certificate#attributes-reference
  ssl_certificates = ["projects/dg*********t/locations/global/certificates/l***t"]
}

Debug Output

https://gist.github.com/dgulli/6838e4903ac764e7f7ff03d0d2fd736b

Expected Behavior

As per the documentation, cross-regional internal https load balancers allow for the use of certificate manager hosted google or self-managed certificates. Using the gcloud or UI produces the correct result and allows the target https proxy to utilise a certificate hosted in certificate manager.

Actual Behavior

Using the terraform resource google_compute_target_https_proxy, and setting ssl_certificates to the url of the certificate produces the error:
Error: Error creating TargetHttpsProxy: googleapi: Error 400: Invalid value for field 'resource.sslCertificates[0]': 'projects/dg******t/global/sslCertificates/l****t'. Compute SSL certificates are not supported with global INTERNAL_MANAGED load balancer., invalid │
(full path redacted with *)

However, the resource documentation states that this should be possible:

A list of SslCertificate resource URLs or Certificate Manager certificate URLs that are used to authenticate connections between users and the load balancer. At least one resource must be specified.

Steps to Reproduce

1. terraform apply

Important Factoids

• Authenticating as a service account which has OWNER access to the resource (to remove all doubt of an IAM issue)
• Beta provider behaves in the same manner.
• gcloud compute target-https-proxies create gil7-https-proxy \ --url-map=gil7-map \ --certificate-manager-certificates=gilb-certificate works as intended, and using a terraform import on the resource after creation via gcloud allows the rest to continue building. the resource literally wont just accept a certificate manager url despite the doco saying it can.

References

• resource documentation
• documentation

--->

• b/299997560

[edwardmedia]

@dgulli you receive the error code 400 from the api, Invalid value for field, Clearly it is rejected by the api.
Can you share the debug log for below working command execution?

gcloud compute target-https-proxies create gil7-https-proxy \ --url-map=gil7-map \ --certificate-manager-certificates=gilb-certificate

[DanielRieske]

A colleague of mine and I were running into the same issue and I wanted to create an issue for it so it's great someone already took the effort to do it.

The reason it's getting rejected is because we force the resource url from a certificatemanager certificate to an sslCertificate.

When you create the target-https-proxies through gcloud it logs the following,

== body start ==
{
"name": "gil7-https-proxy",
"sslCertificates": ["https://certificatemanager.googleapis.com/v1/projects/project-x/locations/global/certificates/self-managed-cert"], 
"urlMap": "https://compute.googleapis.com/compute/beta/projects/project-x/global/urlMaps/l7-ilb-regional-url-map"
}     
== body end ==

This implies that the sslCertificate has a resource on the path projects/project-x/locations/global/certificates/self-managed-cert and that's important here.

Also i'd like to emphasize that it does work through gcloud, it doesn't get rejected with the command above.

When you create the resource in terraform like this:

resource "google_compute_target_https_proxy" "default" {
  name             = "l7-ilb-target-https-proxy"
  provider         = google-beta
  url_map          = google_compute_url_map.default.id
  ssl_certificates = ["https://certificatemanager.googleapis.com/v1/projects/project-x/locations/global/certificates/self-managed-cert"]
}

It will reject it with the response below, which is odd because the reference should be to /global/certificates/self-managed-cert

 Error creating TargetHttpsProxy: googleapi: Error 400: Invalid value for field 'resource.sslCertificates[0]': 'projects/project-x/global/sslCertificates/self-managed-cert'. Compute SSL certificates are not supported with global INTERNAL_MANAGED load balancer.

I believe that this is because of the current implementation of the ssl_certificates attribute in the google_compute_target_https_proxy resource.

We force it to a google_compute_ssl_certificate resource while in reality it can also be a google_certificate_manager_certificate

I'd like to pick this issue up as soon as possible as it's quite blocking for a customer of ours.

[dgulli]

@dgulli you receive the error code 400 from the api, Invalid value for field, Clearly it is rejected by the api. Can you share the debug log for below working command execution?

gcloud compute target-https-proxies create gil7-https-proxy \ --url-map=gil7-map \ --certificate-manager-certificates=gilb-certificate

sure @edwardmedia - here it is https://gist.github.com/dgulli/183a0ab45690b07d14180fbce4ee1e40

[bschaatsbergen]

Thanks for the extensive deep-dive you've did @DanielRieske. This indeed seems to be the problem.

[github-actions]

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.