Describe the bug:

When

1. a (Cluster)Issuer is configured with the new spec.acme.solvers[].http01.ingress.ingressClassName property to set the default ingress class for challenge solver ingresses (instead of the older ...http01.ingress.class),
2. and an application ingress tries to override the default ingress class using the documented acme.cert-manager.io/http01-ingress-class annotation,

the generated Challenge resource will have both class and ingressClassName set in its spec. This causes a conflict with the status message "the fields ingressClassName and class cannot be set at the same time" and fail to create an Ingress resource to solve the HTTP01 challenge.

Stripped-down/redacted example of the Challenge resource created by cert-manager:

apiVersion: acme.cert-manager.io/v1
kind: Challenge
metadata:
  name: testingress-tls-xxxxx-000000000-1111111111
  namespace: acmetest
spec:
  authorizationURL: https://acme-v02.api.letsencrypt.org/acme/authz-v3/00000000000
  dnsName: testingress.example.com
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: my-clusterissuer
  key: >-
    xxxxxxxxxxxxxxx.....
  solver:
    http01:
      ingress:
        class: nginx
        ingressClassName: nginx
  token: yyyyyyyyyyyyyyyy.....
  type: HTTP-01
  url: https://acme-v02.api.letsencrypt.org/acme/chall-v3/00000000000/xxxxxx
  wildcard: false
status:
  presented: false
  processing: true
  reason: the fields ingressClassName and class cannot be set at the same time
  state: pending

Setting the old-style ...http01.ingress.class attribute on the Issuer's solver spec instead of ingressClassName avoids the issue and works as expected, but will create challenge solver ingresses with the legacy class annotation instead of the modern ingressClassName spec.

Expected behaviour:

• Either there should be a separate, new and well documented annotation for Ingresses to override the ingressClassName instead of the class attribute of a Challenge, e.g. something like acme.cert-manager.io/http01-ingress-ingressclassname,
• or cert-manager should automatically figure out, based on the configuration of a solver, which type of configuration is set as default, and convert the class name set via Ingress annotation as necessary to replace that default, instead of adding a duplicate/conflicting attribute.

Steps to reproduce the bug:

Stripped-down app ingress manifest:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    acme.cert-manager.io/http01-ingress-class: nginx
    cert-manager.io/cluster-issuer: my-clusterissuer
  name: testingress
  namespace: acmetest
spec:
  ingressClassName: nginx
  rules:
    - host: testingress.example.com
      http:
        paths: [] # ...
  tls:
    - hosts:
        - testingress.example.com
      secretName: testingress-tls

Stripped-down ClusterIssuer manifest:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: dico-clusterissuer
spec:
  acme:
    # ...
    solvers:
      - http01:
          ingress:
            ingressClassName: nginx

Anything else we need to know?:

This relates to the new http01.ingress.ingressClassName solver spec attribute which got introduced in the recent v1.15 cert-manager version. It's not a regression, but a bug or a missing part with the new feature.

Environment details::

• Kubernetes version: 1.24.10
• Cloud-provider/provisioner: Azure/AKS
• cert-manager version: v1.12.1
• Install method: official Helm chart

/kind bug

CyberArk tracker: VC-46500