Cert-manager: Configuring LetsEncrypt, DNS01 on AWS

[rodrigdav]

Configuration:

Uncomment only one, leave it on its own line:

/kind bug
/kind feature

What happened:
I have installed / configured cert-manager as specified https://github.com/jetstack/cert-manager/tree/master/contrib/charts/cert-manager, https://github.com/jetstack/cert-manager/blob/master/docs/user-guides/acme-dns-validation.md, and here https://github.com/jetstack/cert-manager/blob/master/docs/api-types/issuer/spec.md#user-content-acme-issuer-dns-provider-configuration

I then create a certificate request. The thought being that I just want to see if I can get a certificate before I start trying to configure the ingress-shim. Like that I am not hunting down two issues.
When I request a certificate I get the following error when I describe the certificate.

Name:         test-example-com
Namespace:    jenkins
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Certificate
Metadata:
  Cluster Name:
  Creation Timestamp:  2018-01-24T20:10:48Z
  Generation:          0
  Resource Version:    282426
  Self Link:           /apis/certmanager.k8s.io/v1alpha1/namespaces/jenkins/certificates/test-example-com
  UID:                 ab58e558-0142-11e8-8103-121107800b9e
Spec:
  Acme:
    Config:
      Dns 01:
        Provider:  route53
      Domains:
        example.com
  Common Name:  test.example.com
  Dns Names:
    test.example.com
  Issuer Ref:
    Name:       letsencrypt-staging
  Secret Name:  test-tls
Status:
  Acme:
    Authorizations:  <nil>
  Conditions:
    Last Transition Time:  2018-01-24T20:10:49Z
    Message:               Error checking ACME domain validation: error picking challenge type to use for domain 'test.example.com': no configured and supported challenge type found
    Reason:                ErrCheckAuthorization
    Status:                False
    Type:                  Ready
Events:
  Type     Reason                   Age                 From                     Message
  ----     ------                   ----                ----                     -------
  Warning  ErrorPrepareCertificate  16m (x8 over 16m)   cert-manager-controller  Error preparing issuer for certificate: error picking challenge type to use for domain 'test.example.com': no configured and supported challenge type found
  Warning  ErrorCheckCertificate    10m (x17 over 16m)  cert-manager-controller  Error checking existing TLS certificate: secret "test-tls" not found

When I view the Issuer I get the following.

Name:         letsencrypt-staging
Namespace:    jenkins
Labels:       <none>
Annotations:  <none>
API Version:  certmanager.k8s.io/v1alpha1
Kind:         Issuer
Metadata:
  Cluster Name:
  Creation Timestamp:  2018-01-24T20:10:39Z
  Generation:          0
  Resource Version:    282399
  Self Link:           /apis/certmanager.k8s.io/v1alpha1/namespaces/jenkins/issuers/letsencrypt-staging
  UID:                 a5cc0c0d-0142-11e8-8103-121107800b9e
Spec:
  Acme:
    Dns 01:
      Providers:
        Name:  route53
        Route 53:
          Access Key ID:   xxx
          Hosted Zone ID:  xxxx
          Region:          us-east-1
          Secret Access Key Secret Ref:
            Key:   secretKey
            Name:  aws
    Email:         email
    Private Key Secret Ref:
      Key:
      Name:  letsencrypt-staging
    Server:  https://acme-staging.api.letsencrypt.org/directory
Status:
  Acme:
    Uri:  https://acme-staging.api.letsencrypt.org/acme/reg/5440465
  Conditions:
    Last Transition Time:  2018-01-24T20:10:40Z
    Message:               The ACME account was registered with the ACME server
    Reason:                ACMEAccountRegistered
    Status:                True
    Type:                  Ready
Events:                    <none>

So to me it seems like the issuer has a provider. I am just not sure why the certificate is saying it can't find a provider.

What you expected to happen:
I would expect a cert to be generated.
Environment:
-Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-04T20:00:41Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"8", GitVersion:"v1.8.6", GitCommit:"6260bb08c46c31eea6cb538b34a9ceb3e406689c", GitTreeState:"clean", BuildDate:"2017-12-21T06:23:29Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}

• AWS
• I used helm to install cert-manager

[rodrigdav]

Here are some logs from cert-manager.

I0124 20:12:12.741157 1 controller.go:187] certificates controller: syncing item 'jenkins/test-example-com' I0124 20:12:12.741210 1 sync.go:107] Error checking existing TLS certificate: secret "test-tls" not found I0124 20:12:12.741248 1 sync.go:238] Preparing certificate with issuer I0124 20:12:12.741620 1 prepare.go:239] Compare "" with "https://acme-staging.api.letsencrypt.org/acme/reg/5440465" I0124 20:12:12.893857 1 sync.go:242] Error preparing issuer for certificate: error picking challenge type to use for domain 'test.example.com': no configured and supported challenge type found E0124 20:12:12.897093 1 sync.go:190] [jenkins/test-example-com] Error getting certificate 'test-tls': secret "test-tls" not found E0124 20:12:12.897125 1 controller.go:196] certificates controller: Re-queuing item "jenkins/test-example-com" due to error processing: error picking challenge type to use for domain 'test.example.com': no configured and supported challenge type found

[whereisaaron]

It looks like you've inserted a space into dns01? I guess it is some sort of pretty printing.

Your Certificate only has a challenge for example.com but the only name for the cert is www.example.com.

[munnerz]

@whereisaaron that is just how kubectl describe renders the field name.

@rodrigdav it appears you've requested a certificate for test.example.com, but only configured a DNS provider on the Certificate for example.com. See:

  Acme:
    Config:
      Dns 01:
        Provider:  route53
      Domains:
        example.com
  Common Name:  test.example.com
  Dns Names:
    test.example.com

Thus, cert-manager prints error picking challenge type to use for domain 'test.example.com': no configured and supported challenge type found because you've not configured a challenge mechanism for test.example.com.

[rodrigdav]

Thanks guys. I will double check the last suggestion.

On Jan 25, 2018 10:02 AM, "James Munnelly" [e-mail] wrote:

@whereisaaron https://github.com/whereisaaron that is just how kubectl
describe renders the field name.

@rodrigdav https://github.com/rodrigdav it appears you've requested a
certificate for test.example.com, but only configured a DNS provider on the
Certificate for example.com. See:

Acme:
Config:
Dns 01:
Provider: route53
Domains:
example.com
Common Name: test.example.com
Dns Names:
test.example.com

Thus, cert-manager prints error picking challenge type to use for domain '
test.example.com': no configured and supported challenge type found because
you've not configured a challenge mechanism for test.example.com.

—
You are receiving this because you were mentioned.

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

[rodrigdav]

Well that did it. I can't believe I missed that. Live and learn I guess. Now I have another error.

error getting route53 secret access key: secret "aws" not found

When I do

davidr: ~/Documents/git/cert-manager ((HEAD detached at v0.2.3)) $ kubectl get secrets aws
NAME      TYPE      DATA      AGE
aws       Opaque    2         1d
davidr: ~/Documents/git/cert-manager ((HEAD detached at v0.2.3)) $

I see the secret. So what format am I not getting correct. Mind you the certificate is being generated in the jenkins namespace and the secret is in the default namespace. Do these need to be in the same namespace even though my issuer is a CluserIssuer?

[rodrigdav]

So if I am reading this correctly (never really worked with Go) . https://github.com/jetstack/cert-manager/blob/2f159a0f0071a378d3dd2b959e64459fc886c403/pkg/issuer/acme/dns/dns.go#L139

It is expecting the secret to be in the namespace of the of the certificate or Issuer? Not sure which one. In my case the issuer has no namespace because it is a clusterissuer. I have the secret in both the default namespace and the jenkins namespace. Do I need to have it somewhere else ?

[munnerz]

The resources that ClusterIssuers reference are all stored in a single
namespace that is configurable.

"As ClusterIssuer resources do not specify a namespace, we must configure a
namespace that cert-manager will use to store supporting resources required
for each ClusterIssuer. We do this by specifying the
--cluster-resource-namespace flag on the cert-manager controller. By
default, this flag will be set to kube-system."

From:
https://github.com/jetstack/cert-manager/blob/master/docs/user-guides/cluster-issuers.md

If you put the 'aws' secret into kube-system it should work.
On Thu, 25 Jan 2018 at 21:55, David Rodriguez [e-mail]
wrote:

So if I am reading this correctly (never really worked with Go) .
https://github.com/jetstack/cert-manager/blob/2f159a0f0071a378d3dd2b959e64459fc886c403/pkg/issuer/acme/dns/dns.go#L139

It is expecting the secret to be in the namespace of the of the
certificate or Issuer? Not sure which one. In my case the issuer has no
namespace because it is a clusterissuer. I have the secret in both the
default namespace and the jenkins namespace. Do I need to have it somewhere
else ?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/jetstack/cert-manager/issues/278#issuecomment-360613592,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAMbP-56tB1ojTcXRkL7VlqmOhghP3-2ks5tOPhsgaJpZM4Rs6Mp
.

[rodrigdav]

Thanks for all the help. I must have missed that in the documentation. I was able to get it working. Jumping into getting familiar with kubernetes and all of this stuff has been a little overwhelming. But a great experience thanks for all of the help. Maybe I will take some notes on how I did this with AWS once I get ingress-shim working. Would that be helpful?

[whereisaaron]

You're not the first to be caught out by that default @rodrigdav!

I proposed to switch the default namespace for cluster resources to the one the cert-manager is running in, rather than kube-system, with the --cluster-resource-namespace option still there if you want to use a separate namespace. @munnerz were you agreeable to that? I can't remember.

[rodrigdav]

Thank you all for all of the help once again. I have this fully working. we can close this.