Ubuntu – Cert-Manager: Challenge stuck on presenting

I want to set up TLS on my microk8s kubernetes setup on Ubuntu 20.04.
This has worked in the past, but after switching to microk8s 1.28 and cert-manager 1.13, I am stuck.

I always get Waiting for HTTP-01 challenge propagation: failed to perform self check GET request.
Furthermore, the challenge description says dial tcp xx.xx.xx.xx:80: connect: connection refused.

kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    email: ...
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          name: whoami

For the ingress-type, I tried name, class, and also ingressClassName as mentioned in the docs. Problem is always the same.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  namespace: default
  labels:
    app: whoami
spec:
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
      - name: whoami
        image: containous/whoami
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
  namespace: default
spec:
  selector:
    app: whoami
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: whoami
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  rules:
  - host: my.domain.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: whoami
            port:
              number: 80
  tls:
  - hosts:
    - my.domain.com
    secretName: letsencrypt-prod

The ACME-solver pod gets created, but what I noticed was the listening port being 8089 for whatever reason.
The service also listens on this port:

cm-acme-http-solver-h648p   NodePort    10.152.183.48   <none>        8089:30571/TCP   15m

Shouldn’t this be 80, as my server is not exposing port 8089?