Restricting times of day Caddy can attempt certificate renewals

[mscdex (mscdex dotexe)]

@francislavoie

You’re really way over-engineering this. This is really an imaginary problem that you think exists but is so infinitesimally unlikely to occur that it’s not worth worrying about.

What can I say, I like infinitesimally better sleep at night. The question still stands though if anyone cares to answer it…

[matt (Matt Holt)]

What question remains at this point? We’ve explained how Caddy works. I don’t know how ZFS works, so if you have questions about ZFS you should ask a ZFS forum or mailing list.

[Whitestrake (Matthew Fay)]

Out of curiosity, I went and had a look at one of my Caddy server instances for a real world renewal.

caddy-1  | {"level":"info","ts":1718749892.5743167,"logger":"tls.issuance.acme.acme_client","msg":"successfully downloaded available certificate chains","count":2,"first_url":"[snip]"}
caddy-1  | {"level":"info","ts":1718749892.57588,"logger":"tls.renew","msg":"certificate renewed successfully","identifier":"[snip]"}
caddy-1  | {"level":"info","ts":1718749892.5764122,"logger":"tls.renew","msg":"releasing lock","identifier":"[snip]"}
caddy-1  | {"level":"info","ts":1718749892.5767727,"logger":"tls","msg":"reloading managed certificate","identifiers":["[snip]"]}

The difference between finishing the download and reloading the newly written certificate is 0.002456 seconds, or about 2.5ms.

Then, I tested the duration of a snapshot process for a 3.20T dataset, which I think is a reasonable middle ground for possible size - much, much higher than a more focused critical application dataset, but plausible that someone might be snapshotting Caddy incidentally as part of a much, much, larger dataset.

root@triton[~]# time zfs snapshot tank/home/whitestrake@test_snapshot_speed
zfs snapshot tank/home/whitestrake@test_snapshot_speed  0.00s user 0.02s system 12% cpu 0.167 total

20ms. I don’t think that’s really representative of the time variance in which certain blocks were frozen - I think much of that is ZFS administrative overhead - but we’ll use the full 20ms because we don’t know when in that 20ms the actual block freezing occurred.

The probability of a collision changes depending on the time periods. So, lets assume:

• We expect a snapshot every 60 seconds (60,000ms), indefinitely
• We expect a certificate renewal every 60 days and 1 minute (5,184,060,000ms), indefinitely
• We have 50 certificates to renew, and they all happen at different times

Therefore:

• The probability of a snapshot is (1 snapshot * 20ms) = 20/60000
• The probability of a cert renewal is (50 certs * 2.5ms) = 125/5184060000

To get the probability of multiple events, you multiply the probabilities together. That gives us… 2,500/311,043,600,000,000 probability of overlap.

A probability of 0.0000000000080374584142.

You could repeat this experiment over six billion times before we reach a statistically significant probability of overlap.

5% chance: 0.05 = 1-(1-0.0000000000080374584142)^x
x = 6,381,340,000 times 60 days and 1 minute = ~1,048,303,063 years before we reach statistically significant probability.

50% chance: 0.5 = 1-(1-0.0000000000080374584142)^x
x = 86,233,600,000 times 60 days and 1 minute = ~14,166,138,619 years before we reach equal likelihood. Fourteen billion years. For reference, our Sun is estimated to be 4.603 billion years old.

I cannot imagine this ever actually occurring to you.