Posted by todsacerdoti 7 hours ago
/usr/bin/letsencrypt renew -n --agree-tos --email me@example.com --keep-until-expiring
Will I need to change that? Will I need to manually add custom DNS entries to all my domains?
PS To add, compared to dealing with some paid certificate services, LetsEncrypt has been a dream.
This is going to greatly simplify some of my scripts.
That should be TAI, right? Is that really correct or do they actually mean unix timestamps (those shift with leap seconds unlike TAI which is actually just the number of seconds that have passed since 1970001Z)?
Basically when it was invented leap seconds seemed like a good idea because we assumed the inconvenience versus value was a good trade, but in practice we've discovered the value is negligible and the inconvenience more than we expected, so, bye bye leap seconds.
The body responsible has formal treaty promises to make UTC track the Earth's spin and replacing those treaties is a huge pain, so, the "hack" proposed is to imagine into existence a leap minute or even a leap hour that could correct for the spin, and then in practice those will never be used either because it's even less convenient than a leap second - but by the time they're asked to set a date for these hypothetical changes likely the signatory countries won't exist and their successors can just sign a revised treaty, countries only tend to last a few hundred years, look at the poor US which is preparing 250th anniversary celebrations while also approaching civil war.
unixtime is almost certainly what is meant by the standard, but it is not the count of UTC seconds since 1970; unix time is the number of seconds since 1970 as if all days had 86400 seconds. UTC, TAI, and GPS seconds are all the same length, and the same number have happened since 1970, but TAI appears 37 seconds ahead of UTC because TAI has days with 86400 seconds, while UTC has some days with 86401 seconds and was 10 seconds ahead of UTC in 1970. unixtime and UTC are in sync because unixtime allows some days to encompass 86401 UTC seconds while unixtime only counts 86400 seconds.
Pasting a challenge string once and letting its continued presence prove continued ownership of a domain is a great step forward. But I agree with others that there is absolutely no reason to expose account numbers; it should be a random ID associated with the account in Let's Encrypt's database.
As a workaround, you should probably make a new account for each domain.
Why not using some public/private key auth where the dns contains a public key and the requesting server uses the private key to sign the cert request? This would decouple the authorization from the actual account. It would not reveal the account's identity. It could be used with multiple account (useful for a wildcard on the DNS plus several independent systems requesting certs for subdomains).
Prior to this accounts were nearly pointless as proof of control was checked every time so people (rightfully) just threw away the account key LE generated for them. Now if you use PERSIST you have to keep it around and deploy it to servers you want to be able to issue certs.
Years ago, I had a really fubar shell script for generating the DNS-01 records on my own (non-cloud) run authoritative nameserver. It "worked," but its reliability was highly questionable.
I like this DNS-PERSIST fixes that.
But I don't understand why they chose to include the account as a plain-text string in the DNS record. Seems they could have just as easily used a randomly generated key that wouldn't mean anything to anyone outside Let's Encrypt, and without exposing my account to every privacy-invasive bot and hacker.
Isn't that pretty much what an accounturi is in the context of ACME? Who goes around manually creating Let's Encrypt accounts and re-using them on every server they manage?
If you’re worried about correlating between domains, then yes just make multiple accounts.
There is an email field in ACME account registration but we don’t persist that since we dropped sending expiry emails.
1. It matches what the CAA accounturi field has
2. Its consistent across an account, making it easier to set up new domains without needing to make any API calls
3. It doesn’t pin a users key, so they can rotate it without needing to update DNS records - which this method assumes is nontrivial, otherwise you’d use the classic DNS validation method
I didn't realize the email field wasn't persisted. I assumed it could be used in some type of account recovery scenario.
Simple: it's for tracking. Someone paid for that.
`certbot register` followed by `certbot show_account` is how you'd do this with certbot.
Once again I would like to ask CA/B to permit name constrained, short lifespan, automatically issued intermediate CAs. Last year's request: https://news.ycombinator.com/item?id=43563676