Struggled with Configuring DigitalOcean's Load Balancer, Now Cannot Deploy Applications, Still

What would you like to share?

I am currently using the following load-balancer settings on DigitalOcean:

    kubernetes.digitalocean.com/load-balancer-id: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
    service.beta.kubernetes.io/do-loadbalancer-disable-lets-encrypt-dns-records: "false"
    service.beta.kubernetes.io/do-loadbalancer-enable-proxy-protocol: "true"
    service.beta.kubernetes.io/do-loadbalancer-redirect-http-to-https: "true"
    service.beta.kubernetes.io/do-loadbalancer-size-unit: "2"
    service.beta.kubernetes.io/do-loadbalancer-tls-passthrough: "true"
    service.beta.kubernetes.io/do-loadbalancer-tls-ports: "443"

As can be seen here: https://kubero.theworkgroup.org, the website is insecure even though the certificate is valid:

Note that I am new to all of this so I do not have much of a troubleshooting strategy but I read the documentation thoroughly and all of it checks out fine.

Additional information

kubero debug outputs the following:

Kubero CLI
kuberoCLIVersion: v2.4.0
OS: darwin
Arch: arm64
goVersion: go1.21.13

Kubernetes
clientVersion:
  buildDate: "2024-06-11T20:29:44Z"
  compiler: gc
  gitCommit: 39683505b630ff2121012f3c5b16215a1449d5ed
  gitTreeState: clean
  gitVersion: v1.30.2
  goVersion: go1.22.4
  major: "1"
  minor: "30"
  platform: darwin/arm64
kustomizeVersion: v5.0.4-0.20230601165947-6ce0bf390ce3
serverVersion:
  buildDate: "2024-09-11T21:22:08Z"
  compiler: gc
  gitCommit: 948afe5ca072329a73c8e79ed5938717a5cb3d21
  gitTreeState: clean
  gitVersion: v1.31.1
  goVersion: go1.22.6
  major: "1"
  minor: "31"
  platform: linux/amd64


Kubero Operator
NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
kubero-operator-controller-manager   1/1     1            1           7h26m

Kubero Operator Image
gcr.io/kubebuilder/kube-rbac-proxy:v0.11.0

Kubero UI
NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
kubero                                 1/1     1            1           6h36m
kubero-prometheus-kube-state-metrics   1/1     1            1           159m
kubero-prometheus-server               1/1     1            1           6h50m

Kubero UI Ingress
NAME     CLASS   HOSTS                     ADDRESS     PORTS     AGE
kubero   nginx   kubero.theworkgroup.org   localhost   80, 443   6h36m

Kubero UI Secrets
NAME                                      TYPE                 DATA   AGE
kubero-secrets                            Opaque               4      6h39m
kubero-tls                                kubernetes.io/tls    2      21m
registry-basic-auth                       Opaque               1      6h36m
registry-login                            Opaque               3      6h36m
sh.helm.release.v1.example.v272           helm.sh/release.v1   1      89s
sh.helm.release.v1.example.v273           helm.sh/release.v1   1      29s
sh.helm.release.v1.kubero-prometheus.v4   helm.sh/release.v1   1      159m
sh.helm.release.v1.kubero.v1              helm.sh/release.v1   1      6h36m

Kubero UI Image
ghcr.io/kubero-dev/kubero/kubero:latest

Cert Manager
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
cert-manager              1/1     1            1           6h54m
cert-manager-cainjector   1/1     1            1           6h54m
cert-manager-webhook      1/1     1            1           6h54m

Cert Manager Cluster Issuers
NAME               READY   AGE
letsencrypt-prod   True    6h51m

More command output

• kubectl get certificaterequests.cert-manager.io --all-namespaces

• kubectl get clusterissuers.cert-manager.io

• kubectl get clusterissuers.cert-manager.io letsencrypt-prod -o yaml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"cert-manager.io/v1","kind":"ClusterIssuer","metadata":{"annotations":{},"name":"letsencrypt-prod"},"spec":{"acme":{"email":"info@theworkgroup.org","privateKeySecretRef":{"name":"letsencrypt"},"server":"https://acme-v02.api.letsencrypt.org/directory","solvers":[{"http01":{"ingress":{"class":"nginx"}}}]}}}
  creationTimestamp: "2024-09-17T16:24:58Z"
  generation: 1
  name: letsencrypt-prod
  resourceVersion: "16978"
  uid: 2cc70ab9-8cd1-484c-887b-7b86d8dd38ba
spec:
  acme:
    email: info@theworkgroup.org
    privateKeySecretRef:
      name: letsencrypt
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - http01:
        ingress:
          class: nginx
status:
  acme:
    lastPrivateKeyHash: r38RkGMnNBTpkfhUf6bvgamWEBNf5t56R/8Jk3srFg4=
    lastRegisteredEmail: info@theworkgroup.org
    uri: https://acme-v02.api.letsencrypt.org/acme/acct/1951867176
  conditions:
  - lastTransitionTime: "2024-09-17T16:24:59Z"
    message: The ACME account was registered with the ACME server
    observedGeneration: 1
    reason: ACMEAccountRegistered
    status: "True"
    type: Ready

Note that I am also not able to deploy any services so far. So I am working on solving one problem at a time. I am suspecting that the load-balancer's configuration is the right place to start but I am not entirely sure.

Start by reproducing the reported deployment and HTTPS problems using the listed DigitalOcean load-balancer annotations and the kubectl debug output. Inspect the Kubernetes ingress, load balancer, TLS secret, and cert-manager status; the work is done when applications deploy successfully and the reported site serves valid HTTPS without the browser security warning.