13 ms·

Wildcard Certificates Coming January 2018

857 points by darwhy 9y ago

kharms 9y ago
Question on this topic - is there a method of encrypting subdomains when you don't own the domain? An example: I run a vm that exposes mysubdomain.azure.com, can I turn on ssl at that level? A google search says "no" but I figure this is a place where someone might have a workaround.
- modalduality 9y ago
  I don't see why this wouldn't be possible, just tell Nginx (or whatever proxy) to serve one on 443 with appropriate TLS options and the root domain on 80. To a large extent subdomains are treated as different sites w.r.t. security. But it's possible Azure has some particular settings to make this impossible.
- deleted 9y ago
  [deleted]
- 4mnt 9y ago
  Sure, LetsEncrypt can issue certificates for that domain. If you have a webserver you control that runs on port 80, you can use Certbot[1] to get a certificate for that domain. [1]: https://certbot.eff.org/ https://certbot.eff.org/
- madsushi 9y ago
  It looks like LE will let you do that: https://community.letsencrypt.org/t/can-i-use-lets-encrypt-if-i-only-possess-one-subdomain/28914 https://community.letsencrypt.org/t/can-i-use-lets-encrypt-i...
- throwanem 9y ago
  It seems like LetsEncrypt should support that, per e.g. [1] - I haven't tried it myself, but I don't see any obvious howlers in that thread, or any a priori reason why it should not work given correct arguments to certbot and a service configuration that permits ownership verification to succeed. It looks as though Azure itself also provides a CA [2], or at least resells one's services, for use with apps hosted on the platform. Depending on your needs, that may be a better alternative, though certainly it will also be more costly. It also appears [3] that the only route that service offers to satisfy the subdomain requirement is a wildcard cert, so there's that. [1] https://community.letsencrypt.org/t/certificate-for-just-a-subdomain/23785/3 https://community.letsencrypt.org/t/certificate-for-just-a-s... [2] https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-purchase-ssl-web-site https://docs.microsoft.com/en-us/azure/app-service-web/web-s... [3] https://stackoverflow.com/q/43074994/1713079 https://stackoverflow.com/q/43074994/1713079
- keeperofdakeys 9y ago
  Each DNS zone (azure.com, mydomain.azure.com, otherdomain.mydomain.azure.com) is separate, and they can all be given independent TLS certs. The only relationship between azure.com and mydomain.azure.com, is that the azure.com name servers delegate DNS for mydomain.azure.com to the name servers of mydomain.azure.com. So you can turn on encryption at that level, and using Let's Encrypt, the private key for your cert would be unique for you. So private keys for azure.com won't be able to decrypt traffic for mydomain.azure.com.
- pfg 9y ago
  Each FQDN is treated separately, so generally speaking, if you can demonstrate control for a FQDN under an ICANN TLD, you can obtain a certificate. Something you have to keep in mind are rate limits. Unless the (parent) domain owner has registered the domain in question as a public suffix[1], you, together with all other users who have subdomains under the parent domain, will be limited to 20 certificates per week. Some domains, like for example the hostnames EC2 instances get that resolve to their public IP, have also been explicitly blacklisted because they are generally not assigned to anyone for longer periods of time, and it would be easy to mint certificates for a large number of those hostnames by just spawning tons of EC2 instances, which would make those certificates largely useless. Finally, domain owners may decide to prevent issuance using a CAA DNS record, which are supported by Let's Encrypt. [1]: https://publicsuffix.org/ https://publicsuffix.org/
- apawloski 9y ago
  You can encrypt any subdomain at which you can serve an answer to Let's Encrypt's ACME Challenge [1][2]. That being said, I know they have a blacklist of certain domains. I've seen it once with amazonaws.com [3], and it's possible they have similar entries for azure.com, heroku, etc. They don't publicly release their blacklist. [1] https://letsencrypt.org/how-it-works/ https://letsencrypt.org/how-it-works/ [2] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.txt https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.txt [3] As in "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
- e12e 9y ago
  Afaik you would have to register a domain, and point alias.example.com to alias.azure.com via a CNAME record. But for ssl etc to work you would also have to get your vm setup so it "knows it's own (new) name" (alias.example.com). [you could also use an A record with the ip, but I'm guessing guaranteeing sub-domain.azure.com points to the right ip is easier that updating the ip on updates etc to the vm]
middleclick 9y ago
I am genuinely curious as to how much this will affect the cert providers commercial business? Other than Lets Encrypt not being able to issue EV certs. Does anyone have a resource that talks about this?
- artursapek 9y ago
  I hope it hurts them enough that they stop with the shady business practices.
  - callalex 9y ago
    Decreased revenue tends to lead to even shadier business practices though.
    - RKearney 9y ago
      When we moved our certs away from COMODO we received a sales call from one of them. They found the contact info for an executive here and told them that by replacing our COMODO certs with another brand, we were at "tremendous" risk for not having our websites work on the latest iPhones and iPads. The entire call (which we ended up pulling and listening to, and then sent back to COMODO as a prime example as to why we're threw with their business) was designed to have a non-technical decision maker make an impulse decision over the phone to buy thousands of dollars worth of certificates again. Wildcard certs from Let's Encrypt cannot come soon enough.
      - Cumulonimbus 9y ago
        Fortunately (and unfortunately) all the way up to the assistant vice president came from software engineers and systems engineers. So when Comodo did their little scam, the AVP called bullshit on them and told them off. (The unfortunately is that some of the higher ups are technically exceptional, they have low regard of people skills). We're on LE for 90%. There's a client (there always is...) that demands Network Solutions certs. Yet they cannot put to words why that's their need, other than stupid bullyish business practices. We're still trying to wrap our heads how LE plans to offer wildcards.. But I digress.
madsushi 9y ago
Wildcards were one of the two big blockers for Let's Encrypt adoption at a lot of organizations. The second blocker, the operational discipline to automatically refresh the cert and restart services every <90 days, will likely be the only excuse left.
- djstein 9y ago
  While I do not know the full potential of this, apparently certbot is the way to go for refresh services: https://certbot.eff.org/ https://certbot.eff.org/ In our prod we use https://github.com/GUI/lua-resty-auto-ssl https://github.com/GUI/lua-resty-auto-ssl to generate over 1k lets encrypt certs that refresh as they expire. Hope these can help
  - quintin 9y ago
    Saved me a lot of time. Thanks!
  - pricechild 9y ago
    I've really enjoyed using https://github.com/hlandau/acme https://github.com/hlandau/acme and we use it in prod. I'm not sure how up to date https://github.com/hlandau/acme#comparison-list-of-client-implementations https://github.com/hlandau/acme#comparison-list-of-client-im... is.
- tokenizerrr 9y ago
  Just use any of the dozens of tools to manage this automatically through cron. You don't even have to restart services, just reload them.
  - madsushi 9y ago
    There are lots of organizations where certificates are "managed" by a recurring Outlook meeting on a 2-year cycle, where you hope that employee is still around. Moving to an automated system like certbot (which I use and love) with proper logging and email alerts is the right way to go! But that can require a lot of communication between the server teams, web teams, IT teams, etc. There are plenty of places where it seems more convenient (true or not) to just deal with $100 every couple of years than spend the time to implement new processes.
randomf1fan 9y ago
This is great news for organizations. I work at a large Fortune 150, and there are lots of services that require wildcard certs. We have a process to get these from our internal CA as well as a third-party - the internal CA is automated, but the third-party (for external services) can be slow and cumbersome, to the point where many departments just buy their own cert. And then a year later, they move on, forget, etc, and suddenly we have services that have expired certs and there's a scramble to fix them. This move by Letsencrypt should hopefully make them the standard for any external service that doesn't require an EV cert.
- randomf1fan 9y ago
  And a quick follow up - our security team does not allow rogue * .company.com wildcards - they hunt down those sites and boot them off the network. They do, however, allow *.<service>.company.com.
  - SallySwanSmith 9y ago
    Can you clarify who "our security team" is?
    - wolfgang42 9y ago
      From the parent post: > I work at a large Fortune 150 [...] we have [an] internal CA (This was a lot clearer when there weren't so many other comments in between.)
    - randomf1fan 9y ago
      Sure - this was in reference to my top level comment, but I see that this dropped lower down the page. I work for a large Fortune 150, one that you've heard of, and we have a security team that is constantly scanning our network for weaknesses and potential exploit vectors. They will kill (firewall off) any sites that might compromise the network and tell the application owner to fix the issue before they allow it back on the public net.
  - IncRnd 9y ago
dijit 9y ago
I strongly dislike wildcard certificates. I worked in a few places that had a *.company.com which covered, obviously, everything under that domain. That meant if that wildcard cert leaked then our EV cert for, say, checkout.company.com would be essentially compromised too. Not to mention. If you have a wildcard cert it's rather likely you're passing those certs around servers, lots of scope for leakage. I really think that if you feel the need to do wildcard certificates, then you should at least try to figure out another way around it. I'm not saying you absolutely must never use them, but be incredibly mindful of what is at stake and limit the scope and availability of such certs as much as possible. For instance. Don't put the same wildcard on mail servers and IM servers and git servers and etc; a compromise of one will compromise them all and the revokation system is not good enough. https://blog.dijit.sh/please-stop-advocating-wildcard-certificates https://blog.dijit.sh/please-stop-advocating-wildcard-certif...
- Shorel 9y ago
  A big part of that was cost. A wildcard certificate can be used to lower costs if a company has hundreds of sub-domains. But now, with the full LE offer of services, cost is no longer an issue, and all you mention should be easily automated via scripts.
- mnutt 9y ago
  I agree that wildcards aren't great if they're being passed around an organization to avoid registering a few extra certs, but they are very useful in a few circumstances such as sandstorm.io: every app session uses a different subdomain to prevent cookie leakage, and registering that many certs would overwhelm LE. I'd imagine there are other cases out there involving automatically created subdomains that will benefit.
  - dijit 9y ago
    Like I said. There are uses for wildcard certs I'm just arguing against the fact they're used en masse. People should be perfectly aware of the ramifications and sandbox appropriately. (*.tennant.sandstorm.io or whatever.) Everyone keeps saying SaaS is the reason for the use of wildcard certs and I would absolutely argue the point that multi-tennancies weakest tenet is the fact that if you get compromised the scale can be broad. Why intentionally weaken that system? LE can handle thousands of domain creations a minute, they've been very forthcoming with lifting limits for people on domain creation. The downside is your server sites which need a little overhead for vhost creation but that could be automated with less than a day of ops work.
deleted 9y ago
[deleted]
jpsim 9y ago
Is there a write-up somewhere explaining why this was a technical hurdle compared to base domain certs? Very curious.
- tyingq 9y ago
  Some of the original discussion is here: https://github.com/letsencrypt/acme-spec/issues/64 https://github.com/letsencrypt/acme-spec/issues/64
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
benth 9y ago
I recently read about how Plex got trusted SSL certificates for all their users in partnership with DigiCert, and was really curious if a similar scheme could be accomplished with Let's Encrypt. The scheme required wildcard certificates so I figured it wouldn't be possible. But with this announcement, maybe it would be! I work on a product that generates a self-signed cert and so our customers always get a cert warning. They can replace the cert with their own if they like, but some customers aren't set up to do that. Offering an alternative where we securely mediate creation of a trusted SSL cert would be fantastic. See: https://www.plex.tv/blog/its-not-easy-being-green-secure-communication-arrives/ https://www.plex.tv/blog/its-not-easy-being-green-secure-com... and https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...
- tialaramex 9y ago
  If your product consists mainly of a HTTPS service with some particular Internet accessible fully qualified domain name, say https://benth-app.customername.example/ https://benth-app.customername.example/ where your customer owns customername.example then it's possible already today although you should ensure the customer is told what you're up to of course. If your service doesn't provide HTTPS or customers don't have it accessible from the public Internet then you'd need cooperation from them unless you yourselves control the DNS records involved.
  - benth 9y ago
    In our case, the appliance usually can access the internet, possibly through a proxy, but it's not accessible from the internet.
gsylvie 9y ago
I want multi-wildcard-certs (using subject alternative names aka SAN). Also, if I get a cert that covers: [*.a.company.com] and [*.b.company.com] Can I please also have [a.company.com] and [b.company.com] stuffed into two additional SAN slots! p.s. How do I get an inline asterisk into my HN comment!?
- pfg 9y ago
  Wildcard issuance and validation hasn't been implemented yet, but I see no reason why this shouldn't be possible once the feature is rolled out. My best guess is that you'll be able to mix wildcards and FQDNs to your liking, provided that you can demonstrate control of all domains.
JepZ 9y ago
Hooray!
mnglkhn2 9y ago
I would feel even more comfortable if I would be able to pay a nominal sum. Even $1 per cert would go a long way in securing their infrastructure. Maybe Letsencrypt does not want to handle the hassle of managing payments.
- Dobbs 9y ago
  You can setup a reoccurring donation to letsencrypt: https://letsencrypt.org/ https://letsencrypt.org/ The reason these are free has nothing to do with payments but instead allows removing an additional barrier to entry from getting SSL working.
- jcwayne 9y ago
  You can: https://letsencrypt.org/donate/ https://letsencrypt.org/donate/
  - no_wizard 9y ago
    I personally donate to Lets Encrypt once a year. The trouble with donations at my company, however, is that 'gifting' money is a lot more complicated than buying something. For instance, we are supporters of Vim, but we couldn't make a direct donation to the project. Our corporate policies on this makes things a little stiff as any donation like this is seen as potential publicity. so we couldn't move forward on that. However, we do often buy things for corporate events from Amazon, so we could use the affiliate link to buy our stuff and still contribute to the project. There was another instance, i can't remember what the project is as I didn't deal with it directly, where you could donate directly or buy 'swag' (like T-shirts, cups etc). I remember one of the teams that wanted to contribute funds managed to expense it as swag for their department so everyone got hats, t-shirts, pens, coffee cups etc. because again, can't directly donate. And of course, sponsorship is usually out of the question, because they don't want to be known as supporting one specific thing or another. Sometimes its just easier to make a 'sale' than it is to get a donation from huge users of your product.
- tialaramex 9y ago
  Machines don't (on the whole) have wallets. So even for one dollar the effect is that now auto-renewal isn't possible, a human must intervene to pay. Donations, however, are appreciated.
LinuxBender 9y ago
Serious question. What does LetsEncrypt buy me that I could not get from having a knob in applications and browsers that lets me accept self signed certs? To be clear, the reason I am asking is that historically a CA was intended to be a way to validate "who" you are talking to. LetsEncrypt is providing a signed cert that does not validate an entity. It just solves the self signed cert, which could also be solved in applications by having a setting to "Accept Self Signed Certs". Some apps and appliances already have this.
- sgift 9y ago
  If you ask LetsEncrypt for a certificate for www.google.com you won't be able to get it as you cannot solve the challenge LetsEncrypt issues to check that you actually own www.google.com. Creating a self-signed certificate for www.google.com on the other hand is something everyone can do.
  - LinuxBender 9y ago
    Fair enough, that makes sense. I understand that there are about 17k certs with paypal.com in the name. Are there plans to try to prevent some of that in the future?
    - pfg 9y ago
      "paypal.com in the name" is a bit too ambiguous. You can register a subdomain like "paypal.com.example.com" and acquire a certificate for that, that's correct. There have been no mis-issuances under the actual domain "paypal.com", to my knowledge. Here's a blog post explaining why Let's Encrypt does not think it should be the CA's job to prevent this[1]. At least two browser vendors seem to share this sentiment[2][3]. [1]: https://letsencrypt.org/2015/10/29/phishing-and-malware.html https://letsencrypt.org/2015/10/29/phishing-and-malware.html [2]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/4Xy1Q6PHA7Y/-OcrrsTqCAAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p... [3]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vMrncPi3tx8/M-U5F8K7AQAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p...
    - 9y ago
stephenr 9y ago
Sigh. Wildcard certs, that are generally seen as a security risk, and could have been alleviated for most legitimate uses with higher limits on issuance per domain will be supported. But S/MIME, the email encryption option that actually works out of the box in basically every mail client, sorry, nothing doing.
IncRnd 9y ago
It is a serious security issue to add wildcard certificates for multiple unrelated domains.
dopamean 9y ago
The company I work for is a large user of Let's Encrypt certs (we order them for our customer's sites). It doesn't look like we'll be able to use this since we don't control our customer's DNS.
- geetfun 9y ago
  Yup. We use a lot of Let's Encrypt certs with domain validation via http-01 where our internal API can handle all the requests and validation without the end user requiring any technical knowledge. It seems they will evaluate other options, but it's hard to imagine they would use something as convenient as http-01 for wildcards as then it opens up the platform to major abuse.
  - dopamean 9y ago
    How would it open up the platform for abuse (serious quetion, not snark)? The CA we use to get wildcard certs for our customers uses a challenge process very similar to LE's http-01.
eridius 9y ago
What verification strategy are they using to determine when a wildcard cert can be created? I see the discussion on https://github.com/letsencrypt/acme-spec/issues/64 https://github.com/letsencrypt/acme-spec/issues/64 suggesting that they validate a sampling of randomly-generated subdomains, but it's unclear if that's actually the strategy they're using (and an obvious downside with that strategy is it won't work for a client that wants a wildcard cert for whatever reason but hasn't configured DNS to handle arbitrary subdomains, though you could of course argue that these clients don't actually need wildcard certs).
- jaas 9y ago
  Currently we're only planning to allow DNS method validation for wildcards. You'll have to validate the base domain via DNS, that's all. No HTTP or file-based validation option. We decided not to offer HTTP-based (file-based) validation via randomly-generated subdomains for wildcards in part because if you're required to set up random subdomains you're modifying DNS to do that, and if you're already modifying DNS you might as well just use the DNS validation method.
  - eridius 9y ago
    Glad to hear it. So the assumption is that if you control the DNS for example.com then you control the DNS for all subdomains? That seems like a reasonable assumption.
    - icebraining 9y ago
      To validate you actually need to create a specific subdomain (_acme-challenge.<domain>), so effectively you do control the DNS for subdomains.
  - sofaofthedamned 9y ago
    I used to use the DNS challenge for my (few) sites. Unfortunately i'd had many problems so I switched to HTTP. These problems boiled down to: 1. Namecheap's API is rubbish - extremely rate limited so after doing 2 or 3 in an hour it basically stopped working 2. Propagation delays - I don't know if this was provider specific for Namecheap and Gandi, but sometimes lego would just hang waiting for LE to confirm propagation. HTTP challenge works fine and is far easier if punched into the load balancer rather than relying on each back end. Note note of these problems are the fault of LE from what I see. I'm going to see if any of the ACME clients support updating Google Cloud DNS which I use now, as their propagation time seems minimal. Thanks for your work btw in securing the internet.
ikrisztian 9y ago
What if id like to scan objects with my phone's cam, and use those in VR?
nvr219 9y ago
Can I get Windows/IIS support please?
- mi100hael 9y ago
  Looks like it'll use DNS-based verification, so it should work regardless of webserver/OS
- tialaramex 9y ago
  ACME is on the path to IETF standardisation, and all of Let's Encrypt is Free Software, so Microsoft absolutely could enable this in a future IIS version. If you're a customer it can't hurt to tell MS you want this. Meanwhile you're at the mercy of third party probably volunteers to make what you want possible.
a1exus 9y ago
thank you!
prdonahue 9y ago
Looking forward to using these at Cloudflare for our Universal SSL product. Our plan is let customers choose which CA they would like us to issue from, with sane defaults based on constraints imposed by other settings, e.g., CAA record prohibiting issuance from one of the CA choices.
taylorbuley 9y ago
In my best Oprah voice: "Subdomains for everybody! You get a secured subdomain.. you get a secured subdomain..." In seriousness, I pine for the post `~username`, pre-`/username` days where services would hand out subdomains for user management. It still happens -- viz Tumblr, etc. -- but I feel like it's less frequently then it used to. One reason I would avoid is that wildcard certs are pricey. Nice to see that will commoditize a bit come January.
SwellJoe 9y ago
Let's Encrypt is just about the best thing to happen to the web this decade. It really is huge to have encryption be something that can Just Work. It is, by far, the most popular feature we've added to Virtualmin in many years (and we had support from very early on due to the high demand for it). Wildcard certs have been a common request, but you can already specify multiple domains using SAN. And, since you can issue a new LE cert on-demand, it's actually not necessary for a lot of use cases that would have required a wildcard in the past. In the bad old days, getting a new certificate (even just to change details like adding a name to it) was time-consuming and often cost money. Most of the time when our users have needed a wildcard, it was just because they wanted to save a little money by having all of their subdomains on one cert; and not so much that they really needed to be able to spring up dozens/hundreds/thousands of new subdomains that could just automatically be secured. If you have a fixed number of names that need SSL with the same cert, you can already do that today with Let's Encrypt. Nonetheless, this is great. I'm just super impressed by how effective the LE folks have been at improving the state of security on the web, and for free! They really deserve every kind word and every donation dollar that comes their way.
- mgkimsal 9y ago
  Can I ask for a virtualmin feature here wrt SSL certs (and maybe specifically LE)? I know it's not the first request, but an easy way from the GUI to force all requests to be SSL would be great. The only way I see in GUI is a "redirect everything", but... that also redirects requests for ".well-known" which means renewal requests don't work (have been hit by this a few times). Some recommended ways of handling "always use SSL" with LE renewals would help. Thanks for VM work!
  - pfg 9y ago
    > [...] that also redirects requests for ".well-known" which means renewal requests don't work What issue did you run into with this? Let's Encrypt follows redirects both to HTTP and HTTPS and accepts practically any certificate for redirect targets when validating via http-01, including self-signed, expired and mismatching certificates (which isn't a problem since the initial request is plaintext anyway).
_eqet 9y ago
Thank you so much for your efforts!!
hdhzy 9y ago
Wow, very cool. I wonder if elliptic curve certificates and intermediaries via certbot are also in the pipeline. P-256 can be issued via manual CSR and EC intermediaries are scheduled "before September" according to https://letsencrypt.org/upcoming-features/ https://letsencrypt.org/upcoming-features/
chtitux 9y ago
One great advantage of wildcard certificates is the privacy of the domains. If you use customer1.mycorp.com, customer2.mycorp.com, etc. the names of your clients is exposed twice : - if you issue one certificate with all the domains, all the domains are readable in the certificate (Cloudflare free cert. has this issue too) - all the LE certificates are published in Certificate Transparency logs. So you can detect if anyone issues a cert. for your domain, but anyone can view the certificates you issued. With a wildcard certificate, the subdomains used are not public. Note this issue applies to "internal" subdomains too. You probably don't want to expose the hostname of your backoffice (admin.mycorp.com) or your new top secret project (linux.microsoft.org).
- overint 9y ago
  Would you not be exposing those subdomains via DNS anyway?
  - ec109685 9y ago
    That could be wildcard as well.
  - chtitux 9y ago
    You can't enumerate sub domains via DNS (except if you use DNSSEC with NSEC algorithm, but nobody do that). It does not prevent people guesssing it tough.
    - tptacek 9y ago
      Correction: you can also enumerate through NSEC3, the most common (and default) mode of deployment; NSEC3 turns enumerable zone entries into the equivalent of a password hash file, which can be cracked. There's a hack to prevent this that seeds the zone with false entries, but it requires the server to operate as an online signer. Since this is essentially incoherent to the design of the protocol (which makes major cryptographic and usability sacrifices to enable offline signers), there's an "NSEC4" being worked on now. DNSSEC is silly.
gonmf 9y ago
This is great news!
e12e 9y ago
This is fantastic news. I just whish x509/browsers/other clients could be fixed with proper support/implementation for scoping, so signing a CA cert limited to a single TLD wouldn't be a big deal. That way, Letsencrypt could've just signed a CA cert that was authorised to sign certs for anything under example.com - but not for anything else - and we could bootstrap trust in internal/local CAs just as we now do with certificates.

857 points by darwhy 9y ago

Question on this topic - is there a method of encrypting subdomains when you don't own the domain? An example: I run a vm that exposes mysubdomain.azure.com, can I turn on ssl at that level? A google search says "no" but I figure this is a place where someone might have a workaround.

modalduality 9y ago
I don't see why this wouldn't be possible, just tell Nginx (or whatever proxy) to serve one on 443 with appropriate TLS options and the root domain on 80. To a large extent subdomains are treated as different sites w.r.t. security. But it's possible Azure has some particular settings to make this impossible.
deleted 9y ago
[deleted]
4mnt 9y ago
Sure, LetsEncrypt can issue certificates for that domain. If you have a webserver you control that runs on port 80, you can use Certbot[1] to get a certificate for that domain. [1]: https://certbot.eff.org/ https://certbot.eff.org/
madsushi 9y ago
It looks like LE will let you do that: https://community.letsencrypt.org/t/can-i-use-lets-encrypt-if-i-only-possess-one-subdomain/28914 https://community.letsencrypt.org/t/can-i-use-lets-encrypt-i...
throwanem 9y ago
It seems like LetsEncrypt should support that, per e.g. [1] - I haven't tried it myself, but I don't see any obvious howlers in that thread, or any a priori reason why it should not work given correct arguments to certbot and a service configuration that permits ownership verification to succeed. It looks as though Azure itself also provides a CA [2], or at least resells one's services, for use with apps hosted on the platform. Depending on your needs, that may be a better alternative, though certainly it will also be more costly. It also appears [3] that the only route that service offers to satisfy the subdomain requirement is a wildcard cert, so there's that. [1] https://community.letsencrypt.org/t/certificate-for-just-a-subdomain/23785/3 https://community.letsencrypt.org/t/certificate-for-just-a-s... [2] https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-purchase-ssl-web-site https://docs.microsoft.com/en-us/azure/app-service-web/web-s... [3] https://stackoverflow.com/q/43074994/1713079 https://stackoverflow.com/q/43074994/1713079
keeperofdakeys 9y ago
Each DNS zone (azure.com, mydomain.azure.com, otherdomain.mydomain.azure.com) is separate, and they can all be given independent TLS certs. The only relationship between azure.com and mydomain.azure.com, is that the azure.com name servers delegate DNS for mydomain.azure.com to the name servers of mydomain.azure.com. So you can turn on encryption at that level, and using Let's Encrypt, the private key for your cert would be unique for you. So private keys for azure.com won't be able to decrypt traffic for mydomain.azure.com.
pfg 9y ago
Each FQDN is treated separately, so generally speaking, if you can demonstrate control for a FQDN under an ICANN TLD, you can obtain a certificate. Something you have to keep in mind are rate limits. Unless the (parent) domain owner has registered the domain in question as a public suffix[1], you, together with all other users who have subdomains under the parent domain, will be limited to 20 certificates per week. Some domains, like for example the hostnames EC2 instances get that resolve to their public IP, have also been explicitly blacklisted because they are generally not assigned to anyone for longer periods of time, and it would be easy to mint certificates for a large number of those hostnames by just spawning tons of EC2 instances, which would make those certificates largely useless. Finally, domain owners may decide to prevent issuance using a CAA DNS record, which are supported by Let's Encrypt. [1]: https://publicsuffix.org/ https://publicsuffix.org/
apawloski 9y ago
You can encrypt any subdomain at which you can serve an answer to Let's Encrypt's ACME Challenge [1][2]. That being said, I know they have a blacklist of certain domains. I've seen it once with amazonaws.com [3], and it's possible they have similar entries for azure.com, heroku, etc. They don't publicly release their blacklist. [1] https://letsencrypt.org/how-it-works/ https://letsencrypt.org/how-it-works/ [2] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.txt https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.txt [3] As in "my-loadbalancer-1234567890.us-west-2.elb.amazonaws.com"
e12e 9y ago
Afaik you would have to register a domain, and point alias.example.com to alias.azure.com via a CNAME record. But for ssl etc to work you would also have to get your vm setup so it "knows it's own (new) name" (alias.example.com). [you could also use an A record with the ip, but I'm guessing guaranteeing sub-domain.azure.com points to the right ip is easier that updating the ip on updates etc to the vm]

middleclick 9y ago

I am genuinely curious as to how much this will affect the cert providers commercial business? Other than Lets Encrypt not being able to issue EV certs. Does anyone have a resource that talks about this?

artursapek 9y ago
I hope it hurts them enough that they stop with the shady business practices.
- callalex 9y ago
  Decreased revenue tends to lead to even shadier business practices though.
  - RKearney 9y ago
    When we moved our certs away from COMODO we received a sales call from one of them. They found the contact info for an executive here and told them that by replacing our COMODO certs with another brand, we were at "tremendous" risk for not having our websites work on the latest iPhones and iPads. The entire call (which we ended up pulling and listening to, and then sent back to COMODO as a prime example as to why we're threw with their business) was designed to have a non-technical decision maker make an impulse decision over the phone to buy thousands of dollars worth of certificates again. Wildcard certs from Let's Encrypt cannot come soon enough.
    - Cumulonimbus 9y ago
      Fortunately (and unfortunately) all the way up to the assistant vice president came from software engineers and systems engineers. So when Comodo did their little scam, the AVP called bullshit on them and told them off. (The unfortunately is that some of the higher ups are technically exceptional, they have low regard of people skills). We're on LE for 90%. There's a client (there always is...) that demands Network Solutions certs. Yet they cannot put to words why that's their need, other than stupid bullyish business practices. We're still trying to wrap our heads how LE plans to offer wildcards.. But I digress.

madsushi 9y ago

Wildcards were one of the two big blockers for Let's Encrypt adoption at a lot of organizations. The second blocker, the operational discipline to automatically refresh the cert and restart services every <90 days, will likely be the only excuse left.

djstein 9y ago
While I do not know the full potential of this, apparently certbot is the way to go for refresh services: https://certbot.eff.org/ https://certbot.eff.org/ In our prod we use https://github.com/GUI/lua-resty-auto-ssl https://github.com/GUI/lua-resty-auto-ssl to generate over 1k lets encrypt certs that refresh as they expire. Hope these can help
- quintin 9y ago
  Saved me a lot of time. Thanks!
- pricechild 9y ago
  I've really enjoyed using https://github.com/hlandau/acme https://github.com/hlandau/acme and we use it in prod. I'm not sure how up to date https://github.com/hlandau/acme#comparison-list-of-client-implementations https://github.com/hlandau/acme#comparison-list-of-client-im... is.
tokenizerrr 9y ago
Just use any of the dozens of tools to manage this automatically through cron. You don't even have to restart services, just reload them.
- madsushi 9y ago
  There are lots of organizations where certificates are "managed" by a recurring Outlook meeting on a 2-year cycle, where you hope that employee is still around. Moving to an automated system like certbot (which I use and love) with proper logging and email alerts is the right way to go! But that can require a lot of communication between the server teams, web teams, IT teams, etc. There are plenty of places where it seems more convenient (true or not) to just deal with $100 every couple of years than spend the time to implement new processes.

randomf1fan 9y ago

This is great news for organizations. I work at a large Fortune 150, and there are lots of services that require wildcard certs. We have a process to get these from our internal CA as well as a third-party - the internal CA is automated, but the third-party (for external services) can be slow and cumbersome, to the point where many departments just buy their own cert. And then a year later, they move on, forget, etc, and suddenly we have services that have expired certs and there's a scramble to fix them. This move by Letsencrypt should hopefully make them the standard for any external service that doesn't require an EV cert.

randomf1fan 9y ago
And a quick follow up - our security team does not allow rogue * .company.com wildcards - they hunt down those sites and boot them off the network. They do, however, allow *.<service>.company.com.
- SallySwanSmith 9y ago
  Can you clarify who "our security team" is?
  - wolfgang42 9y ago
    From the parent post: > I work at a large Fortune 150 [...] we have [an] internal CA (This was a lot clearer when there weren't so many other comments in between.)
  - randomf1fan 9y ago
    Sure - this was in reference to my top level comment, but I see that this dropped lower down the page. I work for a large Fortune 150, one that you've heard of, and we have a security team that is constantly scanning our network for weaknesses and potential exploit vectors. They will kill (firewall off) any sites that might compromise the network and tell the application owner to fix the issue before they allow it back on the public net.
- IncRnd 9y ago

dijit 9y ago

I strongly dislike wildcard certificates. I worked in a few places that had a *.company.com which covered, obviously, everything under that domain. That meant if that wildcard cert leaked then our EV cert for, say, checkout.company.com would be essentially compromised too. Not to mention. If you have a wildcard cert it's rather likely you're passing those certs around servers, lots of scope for leakage. I really think that if you feel the need to do wildcard certificates, then you should at least try to figure out another way around it. I'm not saying you absolutely must never use them, but be incredibly mindful of what is at stake and limit the scope and availability of such certs as much as possible. For instance. Don't put the same wildcard on mail servers and IM servers and git servers and etc; a compromise of one will compromise them all and the revokation system is not good enough. https://blog.dijit.sh/please-stop-advocating-wildcard-certificates https://blog.dijit.sh/please-stop-advocating-wildcard-certif...

Shorel 9y ago
A big part of that was cost. A wildcard certificate can be used to lower costs if a company has hundreds of sub-domains. But now, with the full LE offer of services, cost is no longer an issue, and all you mention should be easily automated via scripts.
mnutt 9y ago
I agree that wildcards aren't great if they're being passed around an organization to avoid registering a few extra certs, but they are very useful in a few circumstances such as sandstorm.io: every app session uses a different subdomain to prevent cookie leakage, and registering that many certs would overwhelm LE. I'd imagine there are other cases out there involving automatically created subdomains that will benefit.
- dijit 9y ago
  Like I said. There are uses for wildcard certs I'm just arguing against the fact they're used en masse. People should be perfectly aware of the ramifications and sandbox appropriately. (*.tennant.sandstorm.io or whatever.) Everyone keeps saying SaaS is the reason for the use of wildcard certs and I would absolutely argue the point that multi-tennancies weakest tenet is the fact that if you get compromised the scale can be broad. Why intentionally weaken that system? LE can handle thousands of domain creations a minute, they've been very forthcoming with lifting limits for people on domain creation. The downside is your server sites which need a little overhead for vhost creation but that could be automated with less than a day of ops work.

deleted 9y ago

[deleted]

jpsim 9y ago

Is there a write-up somewhere explaining why this was a technical hurdle compared to base domain certs? Very curious.

tyingq 9y ago
Some of the original discussion is here: https://github.com/letsencrypt/acme-spec/issues/64 https://github.com/letsencrypt/acme-spec/issues/64

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

benth 9y ago

I recently read about how Plex got trusted SSL certificates for all their users in partnership with DigiCert, and was really curious if a similar scheme could be accomplished with Let's Encrypt. The scheme required wildcard certificates so I figured it wouldn't be possible. But with this announcement, maybe it would be! I work on a product that generates a self-signed cert and so our customers always get a cert warning. They can replace the cert with their own if they like, but some customers aren't set up to do that. Offering an alternative where we securely mediate creation of a trusted SSL cert would be fantastic. See: https://www.plex.tv/blog/its-not-easy-being-green-secure-communication-arrives/ https://www.plex.tv/blog/its-not-easy-being-green-secure-com... and https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/ https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

tialaramex 9y ago
If your product consists mainly of a HTTPS service with some particular Internet accessible fully qualified domain name, say https://benth-app.customername.example/ https://benth-app.customername.example/ where your customer owns customername.example then it's possible already today although you should ensure the customer is told what you're up to of course. If your service doesn't provide HTTPS or customers don't have it accessible from the public Internet then you'd need cooperation from them unless you yourselves control the DNS records involved.
- benth 9y ago
  In our case, the appliance usually can access the internet, possibly through a proxy, but it's not accessible from the internet.

gsylvie 9y ago

I want multi-wildcard-certs (using subject alternative names aka SAN). Also, if I get a cert that covers: [*.a.company.com] and [*.b.company.com] Can I please also have [a.company.com] and [b.company.com] stuffed into two additional SAN slots! p.s. How do I get an inline asterisk into my HN comment!?

pfg 9y ago
Wildcard issuance and validation hasn't been implemented yet, but I see no reason why this shouldn't be possible once the feature is rolled out. My best guess is that you'll be able to mix wildcards and FQDNs to your liking, provided that you can demonstrate control of all domains.

JepZ 9y ago

Hooray!

mnglkhn2 9y ago

I would feel even more comfortable if I would be able to pay a nominal sum. Even $1 per cert would go a long way in securing their infrastructure. Maybe Letsencrypt does not want to handle the hassle of managing payments.

Dobbs 9y ago
You can setup a reoccurring donation to letsencrypt: https://letsencrypt.org/ https://letsencrypt.org/ The reason these are free has nothing to do with payments but instead allows removing an additional barrier to entry from getting SSL working.
jcwayne 9y ago
You can: https://letsencrypt.org/donate/ https://letsencrypt.org/donate/
- no_wizard 9y ago
  I personally donate to Lets Encrypt once a year. The trouble with donations at my company, however, is that 'gifting' money is a lot more complicated than buying something. For instance, we are supporters of Vim, but we couldn't make a direct donation to the project. Our corporate policies on this makes things a little stiff as any donation like this is seen as potential publicity. so we couldn't move forward on that. However, we do often buy things for corporate events from Amazon, so we could use the affiliate link to buy our stuff and still contribute to the project. There was another instance, i can't remember what the project is as I didn't deal with it directly, where you could donate directly or buy 'swag' (like T-shirts, cups etc). I remember one of the teams that wanted to contribute funds managed to expense it as swag for their department so everyone got hats, t-shirts, pens, coffee cups etc. because again, can't directly donate. And of course, sponsorship is usually out of the question, because they don't want to be known as supporting one specific thing or another. Sometimes its just easier to make a 'sale' than it is to get a donation from huge users of your product.
tialaramex 9y ago
Machines don't (on the whole) have wallets. So even for one dollar the effect is that now auto-renewal isn't possible, a human must intervene to pay. Donations, however, are appreciated.

LinuxBender 9y ago

Serious question. What does LetsEncrypt buy me that I could not get from having a knob in applications and browsers that lets me accept self signed certs? To be clear, the reason I am asking is that historically a CA was intended to be a way to validate "who" you are talking to. LetsEncrypt is providing a signed cert that does not validate an entity. It just solves the self signed cert, which could also be solved in applications by having a setting to "Accept Self Signed Certs". Some apps and appliances already have this.

sgift 9y ago
If you ask LetsEncrypt for a certificate for www.google.com you won't be able to get it as you cannot solve the challenge LetsEncrypt issues to check that you actually own www.google.com. Creating a self-signed certificate for www.google.com on the other hand is something everyone can do.
- LinuxBender 9y ago
  Fair enough, that makes sense. I understand that there are about 17k certs with paypal.com in the name. Are there plans to try to prevent some of that in the future?
  - pfg 9y ago
    "paypal.com in the name" is a bit too ambiguous. You can register a subdomain like "paypal.com.example.com" and acquire a certificate for that, that's correct. There have been no mis-issuances under the actual domain "paypal.com", to my knowledge. Here's a blog post explaining why Let's Encrypt does not think it should be the CA's job to prevent this[1]. At least two browser vendors seem to share this sentiment[2][3]. [1]: https://letsencrypt.org/2015/10/29/phishing-and-malware.html https://letsencrypt.org/2015/10/29/phishing-and-malware.html [2]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/4Xy1Q6PHA7Y/-OcrrsTqCAAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p... [3]: https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/vMrncPi3tx8/M-U5F8K7AQAJ https://groups.google.com/forum/#!msg/mozilla.dev.security.p...
  - 9y ago

stephenr 9y ago

Sigh. Wildcard certs, that are generally seen as a security risk, and could have been alleviated for most legitimate uses with higher limits on issuance per domain will be supported. But S/MIME, the email encryption option that actually works out of the box in basically every mail client, sorry, nothing doing.

IncRnd 9y ago

It is a serious security issue to add wildcard certificates for multiple unrelated domains.

dopamean 9y ago

The company I work for is a large user of Let's Encrypt certs (we order them for our customer's sites). It doesn't look like we'll be able to use this since we don't control our customer's DNS.

geetfun 9y ago
Yup. We use a lot of Let's Encrypt certs with domain validation via http-01 where our internal API can handle all the requests and validation without the end user requiring any technical knowledge. It seems they will evaluate other options, but it's hard to imagine they would use something as convenient as http-01 for wildcards as then it opens up the platform to major abuse.
- dopamean 9y ago
  How would it open up the platform for abuse (serious quetion, not snark)? The CA we use to get wildcard certs for our customers uses a challenge process very similar to LE's http-01.

eridius 9y ago

What verification strategy are they using to determine when a wildcard cert can be created? I see the discussion on https://github.com/letsencrypt/acme-spec/issues/64 https://github.com/letsencrypt/acme-spec/issues/64 suggesting that they validate a sampling of randomly-generated subdomains, but it's unclear if that's actually the strategy they're using (and an obvious downside with that strategy is it won't work for a client that wants a wildcard cert for whatever reason but hasn't configured DNS to handle arbitrary subdomains, though you could of course argue that these clients don't actually need wildcard certs).

jaas 9y ago
Currently we're only planning to allow DNS method validation for wildcards. You'll have to validate the base domain via DNS, that's all. No HTTP or file-based validation option. We decided not to offer HTTP-based (file-based) validation via randomly-generated subdomains for wildcards in part because if you're required to set up random subdomains you're modifying DNS to do that, and if you're already modifying DNS you might as well just use the DNS validation method.
- eridius 9y ago
  Glad to hear it. So the assumption is that if you control the DNS for example.com then you control the DNS for all subdomains? That seems like a reasonable assumption.
  - icebraining 9y ago
    To validate you actually need to create a specific subdomain (_acme-challenge.<domain>), so effectively you do control the DNS for subdomains.
- sofaofthedamned 9y ago
  I used to use the DNS challenge for my (few) sites. Unfortunately i'd had many problems so I switched to HTTP. These problems boiled down to: 1. Namecheap's API is rubbish - extremely rate limited so after doing 2 or 3 in an hour it basically stopped working 2. Propagation delays - I don't know if this was provider specific for Namecheap and Gandi, but sometimes lego would just hang waiting for LE to confirm propagation. HTTP challenge works fine and is far easier if punched into the load balancer rather than relying on each back end. Note note of these problems are the fault of LE from what I see. I'm going to see if any of the ACME clients support updating Google Cloud DNS which I use now, as their propagation time seems minimal. Thanks for your work btw in securing the internet.

ikrisztian 9y ago

What if id like to scan objects with my phone's cam, and use those in VR?

nvr219 9y ago

Can I get Windows/IIS support please?

mi100hael 9y ago
Looks like it'll use DNS-based verification, so it should work regardless of webserver/OS
tialaramex 9y ago
ACME is on the path to IETF standardisation, and all of Let's Encrypt is Free Software, so Microsoft absolutely could enable this in a future IIS version. If you're a customer it can't hurt to tell MS you want this. Meanwhile you're at the mercy of third party probably volunteers to make what you want possible.

a1exus 9y ago

thank you!

prdonahue 9y ago

Looking forward to using these at Cloudflare for our Universal SSL product. Our plan is let customers choose which CA they would like us to issue from, with sane defaults based on constraints imposed by other settings, e.g., CAA record prohibiting issuance from one of the CA choices.

taylorbuley 9y ago

In my best Oprah voice: "Subdomains for everybody! You get a secured subdomain.. you get a secured subdomain..." In seriousness, I pine for the post `~username`, pre-`/username` days where services would hand out subdomains for user management. It still happens -- viz Tumblr, etc. -- but I feel like it's less frequently then it used to. One reason I would avoid is that wildcard certs are pricey. Nice to see that will commoditize a bit come January.

SwellJoe 9y ago

Let's Encrypt is just about the best thing to happen to the web this decade. It really is huge to have encryption be something that can Just Work. It is, by far, the most popular feature we've added to Virtualmin in many years (and we had support from very early on due to the high demand for it). Wildcard certs have been a common request, but you can already specify multiple domains using SAN. And, since you can issue a new LE cert on-demand, it's actually not necessary for a lot of use cases that would have required a wildcard in the past. In the bad old days, getting a new certificate (even just to change details like adding a name to it) was time-consuming and often cost money. Most of the time when our users have needed a wildcard, it was just because they wanted to save a little money by having all of their subdomains on one cert; and not so much that they really needed to be able to spring up dozens/hundreds/thousands of new subdomains that could just automatically be secured. If you have a fixed number of names that need SSL with the same cert, you can already do that today with Let's Encrypt. Nonetheless, this is great. I'm just super impressed by how effective the LE folks have been at improving the state of security on the web, and for free! They really deserve every kind word and every donation dollar that comes their way.

mgkimsal 9y ago
Can I ask for a virtualmin feature here wrt SSL certs (and maybe specifically LE)? I know it's not the first request, but an easy way from the GUI to force all requests to be SSL would be great. The only way I see in GUI is a "redirect everything", but... that also redirects requests for ".well-known" which means renewal requests don't work (have been hit by this a few times). Some recommended ways of handling "always use SSL" with LE renewals would help. Thanks for VM work!
- pfg 9y ago
  > [...] that also redirects requests for ".well-known" which means renewal requests don't work What issue did you run into with this? Let's Encrypt follows redirects both to HTTP and HTTPS and accepts practically any certificate for redirect targets when validating via http-01, including self-signed, expired and mismatching certificates (which isn't a problem since the initial request is plaintext anyway).

_eqet 9y ago

Thank you so much for your efforts!!

hdhzy 9y ago

Wow, very cool. I wonder if elliptic curve certificates and intermediaries via certbot are also in the pipeline. P-256 can be issued via manual CSR and EC intermediaries are scheduled "before September" according to https://letsencrypt.org/upcoming-features/ https://letsencrypt.org/upcoming-features/

chtitux 9y ago

One great advantage of wildcard certificates is the privacy of the domains. If you use customer1.mycorp.com, customer2.mycorp.com, etc. the names of your clients is exposed twice : - if you issue one certificate with all the domains, all the domains are readable in the certificate (Cloudflare free cert. has this issue too) - all the LE certificates are published in Certificate Transparency logs. So you can detect if anyone issues a cert. for your domain, but anyone can view the certificates you issued. With a wildcard certificate, the subdomains used are not public. Note this issue applies to "internal" subdomains too. You probably don't want to expose the hostname of your backoffice (admin.mycorp.com) or your new top secret project (linux.microsoft.org).

overint 9y ago
Would you not be exposing those subdomains via DNS anyway?
- ec109685 9y ago
  That could be wildcard as well.
- chtitux 9y ago
  You can't enumerate sub domains via DNS (except if you use DNSSEC with NSEC algorithm, but nobody do that). It does not prevent people guesssing it tough.
  - tptacek 9y ago
    Correction: you can also enumerate through NSEC3, the most common (and default) mode of deployment; NSEC3 turns enumerable zone entries into the equivalent of a password hash file, which can be cracked. There's a hack to prevent this that seeds the zone with false entries, but it requires the server to operate as an online signer. Since this is essentially incoherent to the design of the protocol (which makes major cryptographic and usability sacrifices to enable offline signers), there's an "NSEC4" being worked on now. DNSSEC is silly.

gonmf 9y ago

This is great news!

e12e 9y ago

This is fantastic news. I just whish x509/browsers/other clients could be fixed with proper support/implementation for scoping, so signing a CA cert limited to a single TLD wouldn't be a big deal. That way, Letsencrypt could've just signed a CA cert that was authorised to sign certs for anything under example.com - but not for anything else - and we could bootstrap trust in internal/local CAs just as we now do with certificates.