cert-manager: Passing apiVersion as apiGroup should give a validation error

Describe the bug: I am using cert-manager v1.0.1. If I use apiVersion as apiGroup, the generated secret name becomes spec.secretName-${random_suffix}.

# This works as expected
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: mycert
  namespace: demo
spec:
  secretName: mycert-tls
  issuerRef:
    name: mongo-ca-issuer
  dnsNames:
  - '*.example.com'
  - example.com
  - foo.com

# This does NOT work. Here the generated secret has 1 key and the secret name becomes `spec.secretName`-${random_suffix}
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: mycert
  namespace: demo
spec:
  secretName: mycert-tls
  issuerRef:
    group: cert-manager.io/v1
    kind: Issuer
    name: mongo-ca-issuer
  dnsNames:
  - '*.example.com'
  - example.com
  - foo.com

Expected behaviour: I expected sert-manager to throw error that the group name is not valid. More importantly, I did not expect cert-manager to generate an opaque secret with name spec.secretName-${random_suffix}`

Steps to reproduce the bug: https://github.com/appscodelabs/tasty-kube/tree/master/cert-manager

Frankly as certificate object will work.

Anything else we need to know?:

Environment details::

Kubernetes version (e.g. v1.10.2): 1.18, 1.19
Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): kind
cert-manager version (e.g. v0.4.0): v1.0.1
Install method (e.g. helm or static manifests): yaml

/kind bug

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 6
Comments: 38 (9 by maintainers)

Most upvoted comments

this is still an issue, even with the below Clusterissuer status

Status: Acme: Last Registered Email: @ Uri: https://acme-v02.api.letsencrypt.org/acme/acct/286178370 Conditions: Last Transition Time: 2021-11-17T14:32:35Z Message: The ACME account was registered with the ACME server Reason: ACMEAccountRegistered Status: True Type: Ready Events: <none>

mrkeyiano on Nov 18, 2021

I am generating the certificates using let’sencrypt ACME challenge. Generating generates a temporary secret with that extra suffix . I also get errors while nginix tries to load the certificate since the rule is configured washout the suffix:

W0930 12:51:26.257470       6 controller.go:1132] Error getting SSL certificate "dev/myapp-tls-secret": local SSL certificate dev/myapp-tls-secret was not found. Using default certificate

$ k get secrets -n dev

myapp-tls-secret-mtfj5   Opaque                                1      11m
 
 $ k get certificate -n dev
NAME                    READY      SECRET                  AGE
myapp-tls-secret   **False**   myapp-tls-secret   21m

I can’t curl my public domain from wihin the cluster , it times out(this might be an issue ) .I also get the following error in the logs and:

E0930 14:30:57.202139       1 sync.go:183] cert-manager/controller/challenges "msg"="propagation check failed" "error"="failed to perform self check GET request 'http://myproduct.net/.well-known/acme-challenge/oAYduASDASDASDASDASD': Get \"http://myproduct.net/.well-known/acme-challenge/oAYduYAASDASDASDASD\": dial tcp 51.x.x.x:80: connect: connection timed out" "dnsName"="myproduct.net" "resource_kind"="Challenge" "resource_name"="myapp-tls-secret-vjfl5-1143258667-678349576" "resource_namespace"="dev" "resource_version"="v1" "type"="HTTP-01"

ovidiubuligan on Sep 30, 2020

Facing the same error in gke. Secret is getting created with random suffix having only tls.key and not able to create the expected tls secret. Can anyone address the issue if there is any quick fix for the same as it is troubling me to complete many application setup

Prasannavenkatesh2598 on Sep 28, 2022

No, the secret only contains a private key (if I recall correctly), no cert.

Then the random name is expected, it will get renamed to the correct one once the cert got issued. This is to allow private key rotation.

meyskens on Sep 22, 2020

same issue for me

ghost on Dec 3, 2021

The same error here, with a valid issuer…

lucasGras on Jul 5, 2022