131–140 of 164 posts
Earlier quoted context omitted.
For the love of god, switch to a DNS provider with an API. Whatever legacy behemoth you’re working with doesn’t justify a gap this wide.
Name one that doesn’t have an AWS-style per-query cost. (There might well be a nice one, but I haven’t found it yet.)
Earlier quoted context omitted.
> It's not that much work to trust my root certificate on each device Sure, but is trusting your homebrewed CA on all your devices for essentially everything really a good idea? When your homebrewed CA somehow gets compromised, all your devices are effectively compromised and not only for local connections, but everything that uses PKIX.
Name constraints https://systemoverlord.com/2020/06/14/private-ca-with-x-509-...
I'm surprised that this doesn't require DNSSEC or at the very least actively encourage configuring DNSSEC. While I used to be fully in the camp that DNSSEC was way more trouble than it was worth, in particular when access was de-facto secured by trusted CA certificates, more and more DNS record types (CAA, CERT, SSHFP, these TXT records) are responsible for storing information that can be manipulated in MITM attacks…
Earlier quoted context omitted.
Hetzner does not charge any money for their dns service and they have an api.
Hi there, Hetzner here. Thanks for mentioning us. For anyone who is interested: - https://www.hetzner.com/dns/ - https://docs.hetzner.com/networking/dns - https://docs.hetzner.cloud/reference/cloud#tag/zones --Katie
I'm one of the draft authors. Several questions here touch real design tradeoffs — addressing the main threads: Why account URI instead of a public key in the record? (micw, 9dev, csense) Three reasons: 1. Key rotation without DNS changes. dns-persist-01 exists because DNS updates are expensive. Embedding a public key forces a DNS update on every key rotation — the exact problem this method solves. The account URI su…
I think this is a good call. For the web, the CAB sets CA requirements and they could choose to require DNSSEC at a later date. It would be a breaking change, but the CAB can, and has, made breaking changes to the BR. The IETF draft seems flexible enough that we could end up with a DNSSEC MUST for the web, in practice, based on the CAB's discretion.
I'm surprised that this doesn't require DNSSEC or at the very least actively encourage configuring DNSSEC. While I used to be fully in the camp that DNSSEC was way more trouble than it was worth, in particular when access was de-facto secured by trusted CA certificates, more and more DNS record types (CAA, CERT, SSHFP, these TXT records) are responsible for storing information that can be manipulated in MITM attacks…
(For example, an attacker with control of DNS could switch the A record to their server and use that to pass HTTP-01 or TLS-ALPN-01 validation, or update the _acme-challenge TXT record and use that to pass DNS-01.)
Eager to give this a try as I modernize the homelab.
Earlier quoted context omitted.
Abolition of the Leap Second is basically a done deal. So, the differences caused by leap seconds will become frozen as arbitrary offsets, GPS time versus UTC for example. 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 by…
I tried to think about and leap seconds on their own don't seem to be a real problem. The problem is that leap seconds, minutes, hours, days, years, etc are a human interface concept and therefore only make sense to humans, but we've decided to force machines to deal with these human interface concepts as the primary way of dealing with time, when only the presentation layer should even know what a leap second is.
If humans cared the existing systems couldn't exist. For more than a century we've all lived with time "zones" which are thousands of seconds wide and we're not bothered by that. Many of us have civil time systems which shift twice per year by 3600 seconds for really no good reason, and while that's annoying it's barely worth a brief mention on TV news or in small talk. Leap seconds are 3600 times smaller and happen way less often, they're entirely negligible.
They existed because we thought we cared, and we actually don't care, and we thought it was pretty easy to do, and it actually wasn't very easy after all.
Earlier quoted context omitted.
You should persist certs somewhere. Otherwise your availability is heavily tied to LE’s uptime.
Technically, because Let's Encrypt always publishes all requested certificates to the logs (this isn't mandatory, it's just easier for most people so Let's Encrypt always does this) your tool can go look in the logs to get the certificate. You do need to know your private key, nobody else ever knew that so if you don't have that then you're done.
The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish.
Earlier quoted context omitted.
Now you depend on CT log providers uptime, which as far as I can tell is worse than LE.
Google, Cloudflare, Let's Encrypt, DigiCert, GlobalSign and others run logs. Here is the list Chrome checks: https://www.gstatic.com/ct/log_list/v3/log_list.json While they do not have direct SLAs, they still have to comply with rules enforced by browser vendors, as they will remove you from CT checks and you'll be marked retired/untrusted (you can find some in the above list). This means a 99% uptime on a 90 day rol…
The final certificate (without poison and with SCT proof) is usually not published in any CT logs but you can submit it yourself if you wish.
OP idea won't work unless OP will submit final certificate himself to CT logs.