How to renew SslCertificate resource on Google Cloud load balancer

google-cloud-platform

Is there a way to renew an SslCertificate resource on the Google Cloud load balancer when the underlying certificate expires, or do you have to create a new resource with the renewed certificate?

I'm referring to this service: https://cloud.google.com/compute/docs/load-balancing/http/ssl-certificates (Note the lack of reference to renewing a certificate).

Thanks, all!

Best Answer

On Google’s Global HTTP Load Balancer, each HTTPS target proxy is linked to a certificate. You can use the gcloud tool (pre-installed on GCE images) to update your target proxies with new certificates. But make sure that:

Your version of gcloud is relatively recent. The target-https-proxies commands were only recently added, so they aren’t present in older versions of gcloud. (Not to be confused with target-http-proxies, which manges plaintext HTTP sites)
Your renewal server has API access to Compute Engine resources. You can configure this in your GCE templates, or on a instance-by-instance basis.

You can query gcloud for the current certificate, to check if it’s about to expire. If it is, you can upload your new certificate, then use the target-https-proxies update command to switch over to the new certificate. You won’t see the changes immediately, but soon, the renewed certificate should be installed globally.

There’s a usage quota of 30 SSL certificates (at least on my account). But if you aren’t too aggressive with your renewals, you won’t have any problems even if your renewal script doesn’t clean out expired certificates. It’d be a good idea to keep around at least 1 old certificate, just in case something goes wrong and you need to revert.

Related Solutions

Google Cloud: Health Check is not removing failed instance from HTTP Load Balancer

health checks managed instance groups VS health checks load balancing

The health checks used by managed instance groups are the same health checks used by load balancing, with some differences in behavior. Health checks that you apply to load balancing services help a load balancer determine where to direct network traffic. These health checks do not cause Compute Engine to recreate instances. Health checks that you apply to managed instance groups will proactively signal to the managed instance group to delete and recreate instances if they become UNHEALTHY.

For the majority of scenarios, use separate health checks for load balancing and for monitoring managed instance groups. Health checking for load balancing can and should be more aggressive since these health checks determine whether an instance receives user traffic. Since customers might rely on your services, you want to catch non-responsive instances quickly so you can redirect traffic if necessary. In contrast, health checking for instance groups will cause Compute Engine proactively replace failing instances so you could create health checks that are more conservative than health checks for a load balancer.

https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-managed-instances#monitoring_groups

Expose port 80 and 443 on Google Container Engine without load balancer

Yep, through externalIPs on the service. Example service I've used:

apiVersion: v1
kind: Service
metadata:
  name: bind
  labels:
    app: bind
    version: 3.0.0
spec:
  ports:
    - port: 53
      protocol: UDP
  selector:
    app: bind
    version: 3.0.0
  externalIPs:
    - a.b.c.d
    - a.b.c.e

Please be aware that the IPs listed in the config file must be the internal IP on GCE.

Best Answer

Related Solutions

Google Cloud: Health Check is not removing failed instance from HTTP Load Balancer

Expose port 80 and 443 on Google Container Engine without load balancer

Related Topic