New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Ayy wildcard free ssl letsencrypt wowie :)
https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579
Ditch capitalistic SSL issuers, join the leftie internets!
Comments
Been waiting for this.
This makes my life so much easier. I've been holding off projects waiting for this.
Welp.
Finally can get rid of caddy in the middle of my GitLab Pages server
Sweet! Finally!
This is a great news.
*FartZ*
awesome!
You can try them using below cmd
great!
I heard this news last year. Although they delay the release, they still want to celebrate.
So, going to say this here as well: you probably should NOT use wildcard certificates.
I wrote a little article here that explains the technical details and reasons, but here's the TL;DR:
My guess is that in practice, the great majority of use cases of LE certificates are for services/subdomains on a single server.
In my use case (probably similar to other use cases), I have multiple services/subdomains (mail, ftp, www, ...) on a single server. The advantage of a wildcard certificate is that if I decide add a new service/subdomain (e.g., owncloud), nothing more needs to be done as far as the certificate is concerned. If I don't have a wildcard certificate, then I have to cancel and request a new certificate that includes the new service/subdomain.
But your point about services on more than one server is well-taken.
Ideally your ACME implementation should be taking care of this automatically - that's half the point of the automation-driven approach of Let's Encrypt, to make this kind of thing no longer require additional effort.
An additional problem is that requesting a wildcard certificate means that that certificate will be a liability until it expires. If you request a wildcard certificate today, and in two weeks decide to add a second server hosting some different subdomains, you now have a security problem, until your wildcard certificate expires (which is probably in 2.5 more months or so).
I imagine that that requires the use of certbot, which I don't use.
To be honest, I'm in no rush to use a wildcard certificate. :-)
You can revoke it.
Just be aware that revocation only works right if you use HSTS.Actually looks like they don't even check revocation for HSTS sites anymore.>
I'm not sure I understand the scenario. You host subA.foo.bar with a wildcard cert on server X. And you host subB.foo.bar with a wildcard cert on server Y.
What is the attack surface? Server A hacked and then them using the wildcard cert to do a MiTM on server Y's subB which is on a different host?
No, the ability to handle multiple hostnames transparently is something I'd expect any ACME implementation to be capable of.
This doesn't get a lot of public attention usually, but right now revocation is pretty broken. Almost nothing actually checks revocation lists of any kind, due to scalability issues; people are still working on fixing this, but until then it's best to stay on the safe side and assume that revocation just totally doesn't work.
Yep. Since the server A certificate would be valid for
*.foo.bar
, that means it can also be used to MITM connections tosubB.foo.bar
, and clients will consider it totally valid even though somebody's MITMing them. Essentially completely breaks the guarantees of TLS certificate validation for everything under*.foo.bar
.