Getting staging certificate instead of production

[wernight]

The kube-lego container has LEGO_URL set to production:

Containers:
  kube-lego:
    Container ID:       docker://...
    Image:              jetstack/kube-lego:0.1.2
    Image ID:           docker://...
    Port:               8080/TCP
    State:              Running
    Ready:              True
    Restart Count:      0
    Readiness:          http-get http://:8080/healthz delay=5s timeout=1s period=10s #success=1 #failure=3
    Environment Variables:
      LEGO_EMAIL:       example@example.com
      LEGO_NAMESPACE:   default (v1:metadata.namespace)
      LEGO_POD_IP:       (v1:status.podIP)
      LEGO_URL:         https://acme-v01.api.letsencrypt.org/directory

However its retrieving the staging TLS certificate:

time="2016-08-31T11:51:50Z" level=info msg="CREATE foo/ingress" context=kubelego 
time="2016-08-31T11:51:50Z" level=info msg="creating new secret" context=secret name=foo-tls-certificate namespace=foo 
time="2016-08-31T11:51:50Z" level=info msg="no cert associated with ingress" context="ingress_tls" name=ingress namespace=foo 
time="2016-08-31T11:51:50Z" level=info msg="requesting certificate for foo.example.com" context="ingress_tls" name=ingress namespace=foo 
time="2016-08-31T11:51:50Z" level=debug msg="testing reachablity of http://foo.example.com/.well-known/acme-challenge/_selftest" context=acme host=foo.example.com 
time="2016-08-31T11:51:50Z" level=warning msg="wrong status code '502'" context=acme host=foo.example.com 
time="2016-08-31T11:52:08Z" level=debug msg="testing reachablity of http://foo.example.com/.well-known/acme-challenge/_selftest" context=acme host=foo.example.com 
time="2016-08-31T11:52:08Z" level=warning msg="wrong status code '503'" context=acme host=foo.example.com 
time="2016-08-31T11:52:16Z" level=debug msg="testing reachablity of http://foo.example.com/.well-known/acme-challenge/_selftest" context=acme host=foo.example.com 
2016/08/31 11:52:17 [INFO][foo.example.com] acme: Obtaining bundled SAN certificate
time="2016-08-31T11:52:18Z" level=warning msg="Error while obtaining certificate: Errors while obtaining cert: map[foo.example.com:acme: Error 400 - urn:acme:error:badNonce - JWS has invalid anti-replay nonce *************************************]" context=acme 
time="2016-08-31T11:52:34Z" level=debug msg="testing reachablity of http://foo.example.com/.well-known/acme-challenge/_selftest" context=acme host=foo.example.com 
2016/08/31 11:52:34 [INFO][foo.example.com] acme: Obtaining bundled SAN certificate
2016/08/31 11:52:35 [INFO][foo.example.com] acme: Trying to solve HTTP-01
2016/08/31 11:52:35 [INFO][foo.example.com] The server validated our request
2016/08/31 11:52:35 [INFO][foo.example.com] acme: Validations succeeded; requesting certificates
2016/08/31 11:52:36 [INFO][foo.example.com] Server responded with a certificate.
time="2016-08-31T11:52:36Z" level=info msg="Got certs={foo.example.com https://acme-staging.api.letsencrypt.org/acme/cert/*****************  https://acme-staging.api.letsencrypt.org/acme/reg/123456 -----BEGIN RSA PRIVATE KEY-----\n*************************

Note: I kept Nginx Ingress controller hsts-include-subdomains to the default (true).

Should I expect to receive any e-mail at example@example.com? Should I delete the token or something else if I change from staging to production?

[biwwy-zz]

+1

I have the same issue.

[wernight]

Okay found the issue. You must to delete all secrets (and probably restart kube-lego) after changing the LEGO_URL. This is a bug; it should detect URL changes and probably use another secret per environment. Another idea is to have a boolean flag for the environment instead of a full URL. Full URL may be provided as alternative.

In order do this (adapt to your namespaces);

$ kubectl --namespace=default delete secret kube-lego-account
$ kubectl --namespace=foo delete secret foo-tls-certificate
$ kubectl --namespace=default delete po -l app=kube-lego

[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