Cert renewal issued even without proper DNS

[mikesplain]

We’ve been using letsencrypt certs for quite some time now so I’m pretty well versed in renewals and all but this is baffling me.

We generate a number of certs mostly for internal / system use that aren’t publicly available and the DNS entries are, as such, in private DNS as well. Generally when I would create or renew one of these certs, I would temporarily setup a public DNS entry to allow challenges to work and open up a load balancer rule publicly for the challenge to come through on. Recently I renewed a bunch of our domains, didn’t need to setup these public entries, and didn’t setup a load balancer rule (./certbot-auto --debug renew --force-renewal) and it still worked:

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/portal.dev1.barkly.com.conf
-------------------------------------------------------------------------------
Starting new HTTPS connection (1): acme-v01.api.letsencrypt.org
Renewing an existing certificate
Performing the following challenges:
tls-sni-01 challenge for portal.dev1.barkly.com
tls-sni-01 challenge for api-event.dev1.barkly.com
tls-sni-01 challenge for api-web.dev1.barkly.com
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0026_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0027_csr-certbot.pem

-------------------------------------------------------------------------------

While DNS looks like this:

; <<>> DiG 9.10.3-P4-Ubuntu <<>> portal.dev1.barkly.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28188
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;portal.dev1.barkly.com.                IN      A

;; AUTHORITY SECTION:
barkly.com.             852     IN      SOA     ns-123.awsdns-15.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Nov 28 14:46:04 EST 2016
;; MSG SIZE  rcvd: 129

So my question is, can anyone tell me why I’m being issued these certs? I know we’re utilizing tls-sni-01 based challenge but I figured DNS and a method of ingress like a load balancer would be required? Another thing to note, the same command fails with running with dry-run.

Thanks!

[schoen]

Hi @mikesplain,

This is discussed a bit in other threads, but basically the Let’s Encrypt server’s software (Boulder) remembers that a certain account key is authorized to issue certs for a particular name. That authorization remains valid for a period of time without reperforming challenges. In the future, the amount of time that an authorization (authz) lasts without revalidation will be decreased. This is the most likely explanation for why certificates can sometimes be renewed even without being able to perform the challenge again.

If you can confirm from more detailed logs that the challenges were actually performed and satisfied, then we still have a mystery.

[cpu]

Hi @mikesplain,

What you’re seeing here is likely the product of existing valid authorizations associated with your account for the domains in question being reused (more explanation here.)

The already valid authorizations likely do not exist in the staging environment, which is why dry-run causes it to fail.

Edit: Oops! I collided with @schoen !

[serverco]

When you validate your domain ( by whichever method) this authorizes your account key to obtain the cert for your domain. This authorization is valid for a period of time (currently 60 days, it used to be longer, and will I believe be reduced to 7 days in the future). In that period your account key is authorized, you can obtain new certs without revalidating.

Edit: I claim the prize of coming third in the race of similar responses

[mikesplain]

Ahh thank you all, great answers. That makes perfect sense. I knew I was missing something big. Thanks!