41–50 of 92 posts
Earlier quoted context omitted.
Yeah, further, I doubt many certificates were issued from an account key belonging to a email address that people monitor often, if not at all.
I hadn't considered this. Am I in the minority by having a legit, monitored email account for my ACME certs?
Small feedback for the letsencrypt folk: I got the email saying that I have two ACME accounts ids affected. It would have been nice to know which domains are (even if it's just the first ~10 or so per account).
It's disappointing that they haven't learned from this.
They found some issue ("irregularities") and made 2 changes, but the changes are merely restricting the TLS version to 1.2 and deprecating an old OID identifier. While TLS (I have been somewhat concerned about the security properties of the acme/alpn validation for unrelated other reasons, but haven't been able to pin that down to a specific threat - notably the RFC implies that the security is improved due to strict ALPN validation, which in practice usually does not happen.)
Update: RFC 8737 (the ALPN validation method) says "ACME servers that implement "acme-tls/1" MUST only negotiate TLS 1.2". So maybe this is "just" a policy issue?
Can anyone make sense of what they're trying to tell there? They found some issue ("irregularities") and made 2 changes, but the changes are merely restricting the TLS version to 1.2 and deprecating an old OID identifier. While TLS (I have been somewhat concerned about the security properties of the acme/alpn validation for unrelated other reasons, but haven't been able to pin that down to a specific threat - notably…
Earlier quoted context omitted.
I tried solving this a different way for my selfhosted services. Instead of running certbot on every server, I wrote a custom ACME client that runs on a master server and is responsible for requesting/renewing all certificates that I use. It also automatically deploys each cert to the correct server. It is a single point of failure but it makes tracking certificate expiry, renewal and revocation so much easier.
Sounds like a fun project. Assuming you're talking about web servers, did you know Caddy can do that? Simply configure each one to use the same storage backend and Caddy will automatically coordinate management as a cluster, and share the certificate (and OCSP staple) resources. (And depending on the storage backend, it's no longer a single point of failure. And even if storage is the failure, it's just storage, if i…
Earlier quoted context omitted.
Certificates have always been sold and priced per year. I highly doubt lifetime changes benefitted certificate authorities, and I’m pretty sure they had it forced upon them by browsers. If anything, it prevents them from collecting 2-3 years of revenue upfront.
The reduction to 27 months was voted through CA/B (where either CAs or Browsers can effectively veto, like the way Northern Ireland is governed) but only after Ryan suggested Google might just unilaterally impose 90 days if the CAs rejected a reduction. The reduction to 398 days was imposed by Apple, unilaterally, although in practice the ecosystem went along with it. It actually took a few weeks to get clarity on ex…
Earlier quoted context omitted.
I tried solving this a different way for my selfhosted services. Instead of running certbot on every server, I wrote a custom ACME client that runs on a master server and is responsible for requesting/renewing all certificates that I use. It also automatically deploys each cert to the correct server. It is a single point of failure but it makes tracking certificate expiry, renewal and revocation so much easier.
That's what I pondered doing. Do you have any code you can open source? Thanks.
The bulk of the work was already done for me as there was already an ACME library for my language.
I'll probably open source it once I have a chance to clean everything up.
Can anyone make sense of what they're trying to tell there? They found some issue ("irregularities") and made 2 changes, but the changes are merely restricting the TLS version to 1.2 and deprecating an old OID identifier. While TLS (I have been somewhat concerned about the security properties of the acme/alpn validation for unrelated other reasons, but haven't been able to pin that down to a specific threat - notably…
I don't have a deep understanding of the TLS-ALPN-01 validation nor of the vulnerabilities they might be concerned about, but that would be the only reason for revoking certificates (unless it's more of a political statement, "we revoke certs when we screwed up!").
Can anyone make sense of what they're trying to tell there? They found some issue ("irregularities") and made 2 changes, but the changes are merely restricting the TLS version to 1.2 and deprecating an old OID identifier. While TLS (I have been somewhat concerned about the security properties of the acme/alpn validation for unrelated other reasons, but haven't been able to pin that down to a specific threat - notably…
The population of browsers and things that don't understand TLS1.2 is miniscule now, so there should be no impact in disabling tls1.1 and below anywhere possible.
If such a server only supports TLS 1.1, then TLS-APLN-01 validation will fail after this change is implemented.