Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Ayy wildcard free ssl letsencrypt wowie :)
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.

Ayy wildcard free ssl letsencrypt wowie :)

Comments

  • Been waiting for this.

  • trewqtrewq Administrator, Patron Provider

    This makes my life so much easier. I've been holding off projects waiting for this.

  • CConnerCConner Member, Host Rep
    edited March 2018

    Welp.

  • Finally can get rid of caddy in the middle of my GitLab Pages server

    Thanked by 1Aidan
  • Sweet! Finally!

  • This is a great news.

  • WSSWSS Member

    *FartZ*

  • bapbap Member

    awesome!

  • You can try them using below cmd

    ./certbot-auto certonly --server https://acme-v02.api.letsencrypt.org/directory -d *.domain.com --manual --preferred-challenges dns-01

  • great!

  • I heard this news last year. Although they delay the release, they still want to celebrate.

  • joepie91joepie91 Member, Patron Provider

    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:

    Each certificate should only be used for one server, or one homogeneous cluster of servers. Different services on different servers should have their own, usually non-wildcard certificates.

    If you have a lot of hostnames pointing at the same service on the same server(s), then it's fine to use a wildcard certificate - so long as that wildcard certificate doesn't also cover hostnames pointing at other servers; otherwise, each service should have its own certificates.

    If you have a few hostnames pointing at unique servers and everything else at one single service - eg. login.mysite.com and then a bunch of user-created sites - then you may want to put the wildcard-covered hostnames under their own prefix. For example, you might have one certificate for login.mysite.com, and one (wildcard) certificate for *.users.mysite.com.

    In practice, you will almost never need wildcard certificates. It's nice that the option exists, but unless you're automatically generating subdomains for users, a wildcard certificate is probably an unnecessary and insecure option.

    (To be clear: this is in no way specific to Let's Encrypt, it applies to wildcard certificates in general. But now that they're suddenly not expensive anymore, I think this problem requires a bit more attention.)

  • angstromangstrom Moderator

    @joepie91 said: 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.

  • joepie91joepie91 Member, Patron Provider

    angstrom said: 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.

    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).

  • angstromangstrom Moderator

    @joepie91 said: angstrom said: 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.

    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.

    I imagine that that requires the use of certbot, which I don't use.

    joepie91 said: 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).

    To be honest, I'm in no rush to use a wildcard certificate. :-)

  • sithrebel15sithrebel15 Member
    edited March 2018

    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).

    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.

  • @joepie91 said:

    >

    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'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?

  • joepie91joepie91 Member, Patron Provider
    edited March 2018

    angstrom said: I imagine that that requires the use of certbot, which I don't use.

    No, the ability to handle multiple hostnames transparently is something I'd expect any ACME implementation to be capable of.

    sithrebel15 said: You can revoke it.

    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.

    deluxe said: 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?

    Yep. Since the server A certificate would be valid for *.foo.bar, that means it can also be used to MITM connections to subB.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.

    Thanked by 1vimalware
Sign In or Register to comment.