Cert-manager: Undocumented requirement/convention on Certificate and secretName

[safanaj]

/kind bug

What happened:
Deleting a certificate it is recreated by ingress-shim Sync.
I had a Certificate with spec.config[0].http01.ingress, I want to delete the Certificate, but
it is recreated because the Ingress has the annotation searched by ingress-shim during Sync.
The ingress-shim is looking for a certificate named as the secret required by Ingress, here.
I don't find any documentation related to this "assumption", so I should be able to use different names between Certificate and Secret and the ingress shim should look for certificate with the secretName matching which one is required by the Ingress TLS section.

What you expected to happen:

I'd expect that ingress-shim look for secretName in spec of certificates not by name.
maybe using something like c.certificateLister.Certificates(ing.Namespace).GetBySecretName(tls.SecretName) to find existing certificates.
Alternatively I'd expect that this assumption would be well-documented.

How to reproduce it (as minimally and precisely as possible):

1. create a Certificate named "a" with a secretName equal "b"
2. deploy an Ingress that uses the secret named "b"
3. delete the Certificate "a"

the Certificate "a" is recreated with the Ingress in ownerReferences

[munnerz]

I'm unsure whether we want to do this - it seems quite complex, and I don't
see an immediate benefit.

Can you describe your use case further?

You should either manually create your Certificate resource and reference
the outputted secret from your ingress (without adding the tls-acme
annotation). Or otherwise use tls-acme annotation and allow cert manager to
create and manage the Certificate for you.

Why do you manually provision the Certificate resource, and also add the
tls-acme annotation?

On Thu, 3 May 2018 at 18:47, Marco [e-mail] wrote:

/kind bug

What happened:
Deleting a certificate it is recreated by ingress-shim Sync.
I had a Certificate with spec.config[0].http01.ingress, I want to delete
the Certificate, but
it is recreated because the Ingress has the annotation searched by
ingress-shim during Sync.
The ingress-shim is looking for a certificate named as the secret required
by Ingress, here
https://github.com/jetstack/cert-manager/blob/master/pkg/controller/ingress-shim/sync.go#L94
.
I don't find any documentation related to this "assumption", so I should
be able to use different names between Certificate and Secret and the
ingress shim should look for certificate with the secretName matching
which one is required by the Ingress TLS section.

What you expected to happen:

I'd expect that ingress-shim look for secretName in spec of certificates
not by name.
maybe using something like
c.certificateLister.Certificates(ing.Namespace).GetBySecretName(tls.SecretName)
to find existing certificates.
Alternatively I'd expect that this assumption would be well-documented.

How to reproduce it (as minimally and precisely as possible):

1. create a Certificate named "a" with a secretName equal "b"
2. deploy an Ingress that uses the secret named "b"
3. delete the Certificate "a"

the Certificate "a" is recreated with the Ingress in ownerReferences

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/jetstack/cert-manager/issues/535, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMbP4T1tQCtivTM6hIkAXFqv68dwI4-ks5tuzSfgaJpZM4TxbXr
.

[safanaj]

Hi, thank you for your replay and sorry for my delay,
I forgot to mention that I am using a 0.2 release (specifically the chart cert-manager-0.2.8),
the only annotation on ingresses I use are:

    certmanager.k8s.io/acme-challenge-type: http01
    certmanager.k8s.io/issuer: letsencrypt-exinda-issuer

no kubernetes.io/tls-acme: "true".

My use case / purpose is to allow "users of k8s cluster" to be able to have a their own ACME issuer (with associated their account, for rate-limit etc) and get valid certificates for domains they choose to be used in Ingresses they need.

To achieve that I understood that they have to deploy:
1) an Issuer associated to their email/acme account
2) a Certificate for some domains
3) an Ingress to serve the domains using the secret they are referencing in Certificate for those domains (at point 2)

What I understood is that, in the Certificate definition, in the acme.config stanza there is the instructions for cert-manager (controller and/or ingress-shim) related to ingress/pods management to implement the ACME challenge.
In my understanding it should be possible to choose a name for the Certificate different by the Secret used to store the "real" key/cert blob.
Maybe I'm misunderstanding the [documentation|http://docs.cert-manager.io/en/release-0.2/reference/ingress-shim.html#supported-annotations] on Ingress annotations related to certmanager,
in my guessing the annotation certmanager.k8s.io/acme-challenge-type: http01 and certmanager.k8s.io/issuer: letsencrypt-exinda-issuer would be used/required only in the case I use spec.config[0].http01.ingress in Certificate instead of ingressClass an existing ingress is patched to add url endpoints for the ACME challenge, otherwise using the ingressClass a new ingress will be created for the ACME challenge and destroyed when the cert is issued.

In "my" particular case I have for sure a bad configuration of certificate and ingress, because I have 2 Certificates that refer to the same secretName, and also the Certificate is using the ingress (not ingressClass), so I cleaned up my configuration and my problem is gone, but I would want just suggest to better clarify those aspects related to annotations (maybe mutually exclusive) and names to use for certificates and secrets refs in the Documentation.
I pointed that code line because reading that I realized why the Certificate was continuously recreated when I already have the Secret with real key/cert for ingress, and I guess also the annotations on Ingress are involved because they would be observed by ingress-shimm in my guess.

Thank you very much,
best regards

[whereisaaron]

@munnerz related to this issue ingres-shim is creating Certificate resources even when it is unnecessary (and unhelpful), because the required Secret exists.

When ingress-shim is checking an Ingress, it should not create a new Certificate if the Secret named in the Ingress already exists. E.g. it is often the case that some domains are provided by a non-ACME registrar, and are stored in Secret with the name give in the Ingress. Since the Secret required by the Ingress is already satisfied, ingress-shim should not create an unnecessary Certificate (which is a proxy for creating a missing Secret).

E.g. if a Secret called 'my-static-secret' already exists, ingress-shim should only create a Certificate for 'www.example.com' called 'missing-secret'.

  tls:
  - secretName: missing-secret
    hosts:
    - www.example.com
  - secretName: my-static-secret
    hosts:
    - foo.example2.com

If you fix this, you will also fix @safanaj's problem. Since his manually created Certificate creates the required Secret mentioned in his Ingress, and so ingress-shim, with my proposed check, won't create another. That is, you only need to check if the Secrets named in the Ingress exist, you don't (I think) need to check every Certificate as @safanaj was suggesting, to fix both my and his use case.

[xstevens]

I ran into the issue @whereisaaron describes as well. Where I've pre-provisioned a Certificate with three DNS Subject Alt Names. Then when I deploy Ingress with one of those host names it creates a new certificate at secretName rather than using the one that is already there and starts causing SSL failures because now the other two alt names are missing.

[munnerz]

I don't think we can, or should, skip creating a certificate if the target
secret exists.

This would prevent users migrating from certificates from other sources.
Adding an annotation to an ingress resource is an expression of "I want a
certificate resource to be created and kept valid for the contents of this
ingress".

If you are reusing a single certificate/secret between ingress resources,
then only one of those ingresses should have the annotation (or you should
just manage the Certificate resource manually instead).

On Fri, 7 Sep 2018 at 00:26, Xavier Stevens [e-mail]
wrote:

I ran into the issue @whereisaaron https://github.com/whereisaaron
describes as well. Where I've pre-provisioned a Certificate with three
DNS Subject Alt Names. Then when I deploy Ingress with one of those host
names it creates a new certificate at secretName rather than using the
one that is already there and starts causing SSL failures because now the
other two alt names are missing.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/jetstack/cert-manager/issues/535#issuecomment-419273339,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMbP3NYzFkVQ43Lt2W3zIwwkaxFXQ2Lks5uYa9CgaJpZM4TxbXr
.

[xstevens]

@munnerz Ah, this makes sense now. Sorry I misunderstood. I've removed the annotations from my Ingress definitions and things are working as expected.

[retest-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle stale

[retest-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to jetstack.
/lifecycle rotten
/remove-lifecycle stale