How to use multiple SSL certificates with Google Load Balancer?

1
votes

I have a multi-tier app in Google Container Engine and I have a single ingress with single static IP address where I'll be forwarding multiple domains. Each domain will require its own ssl certificate(let's encrypt). The issue I am facing is that I do not see any option to use multiple certificates in the load balancer. It looks like each IP address has a single global forwarding rule that can forward to only one SSL(port 443) HTTPS proxy which can use only one SSL certificate.

I do not want to use multi-domain SSL certificate because it would be huge pita to manage.

This isn't some weird exotic use case but quite normal requirement. What is the proper solution here?

I was thinking of maybe setting up static IP for each domain and using routes to route to the single IP "front end", but each IP costs some money so having tens or hundreds of domains would be financially just crazy(100 domains would cost 1800 USD per month, data/traffic not included).

3
kubernetesgoogle-cloud-platformgoogle-compute-enginegoogle-kubernetes-engine

3 Answers

1
votes

Update: GCE now supports SNI by attaching at most 10 SSL certificates to a load balancer. You can specify the SSL certificates list with TargetHttpsProxy or TargetSslProxy.

Reference: https://cloud.google.com/compute/docs/load-balancing/http/ssl-certificates#multiple_ssl_certificate_example

=======================
You can use network load balancer and terminate the ssl connection on your VM instances. Note that network load balancing cannot forward your traffic to different regions. If you want that, you'll need to set up them separately in different regions.

Reference: https://cloud.google.com/compute/docs/load-balancing/network/

0
votes

I've successfully setup sites with multiple SSL/TLS certificates in Google Container Engine using kube-lego that fetches certs from Let's Encrypt and updates them automatically when they are about to expire. According to the tags you may be using other parts of the Cloud Engine than Kubernetes, but using Kube-lego may at least simplify management of your containers.

We are using two namespaces - production and staging - and in total we are using about 50 certificates for all of the services. Without using kube-lego it would be quite cumbersome to manage all the certificates.

Kube-lego listens for ingress changes and in case a new deployment is done it will take action in case the proper config is in place. For example the other day I had to add a new service to staging. By just adding a small configuration to the deployment script a SSL/TLS cert was automatically issued. Here is the ingress that I deployed and within a minute the cert for proxy.domain.com was up running. 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: proxy-web-ingress
  namespace: staging
  annotations:
    kubernetes.io/tls-acme: "true"
    kubernetes.io/ingress.class: "nginx"
spec:
  tls:
  - hosts:
    - proxy.domain.com
    secretName: proxy-web-tls
  rules:
  - host: proxy.domain.com
    http:
      paths:
      - path: /
        backend:
          serviceName: proxy-web-svc
          servicePort: 80

One drawback is that one may not issue infinite number of certs a week, for understandable reasons. However, during setup one can work with the staging environment at Let's Encrypt having no restrictions. When using kube-lego, Nginx is used to handle routing and termination of the SSL/TLS.