Wildcard Certificates Coming January 2018

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

It can be surprisingly tricky to get redirects right, because of how web apps behave and how web apps often take over early request processing in an htaccess file for things like nice URLs and special assets directories and such, and there can be surprising interactions between redirect rules, but I suspect we could make it work in the majority of cases pretty easily. I'll add it to my todo list.

However, it's still better than having expired certs and a team trying to figure out who owns the app, trying to get in touch with them, asking them to update the cert, finding out that they are no longer with the company...

It's even worse when the service is something that a small team created as a POC - which then became customer facing and mission critical, with the team having moved on to something else.

And it's funny how often this happens over a holiday weekend.

Yes, I know that the issues are deeper and more to do with large company process and bureaucracy than anything technical. But at least you can have secure services that don't fall over.

Go pull up your certificate authority list and ask yourself for each one of them if you trust that company more or less than let's encrypt.

Let's encrypt publishes auditable logs of all issued certificates, they're backed by some of the biggest names in online privacy and I trust them much more than other CAs.

I for one would be happy if I could delete all other providers from my browser.

CAs ultimately are centralized and too trusting, giving that same level of trust to less trustworthy companies just damages the overall security of TLS. There's no distributed trust model for CAs, it's pretty much all or nothing, so in the case of CAs, distribution is not a security benefit like it is in say Tor or Bitcoin, but a problem as it means the attack surface has widened.

Short of going to a new, completely decentralized solution like the proposed DNSSEC extensions or Namecoin, a single, very secure CA is probably better than a lot of not secure, often government influenced CAs.

Wildcard support is one advantage of ACME v2, but another advantage they list is "ACME v2 was designed with additional input from other CAs besides Let’s Encrypt, so it should be easier for other CAs to use" - https://letsencrypt.org/2017/06/14/acme-v2-api.html

So, in addition to this functional improvement to Lets Encrypt, the change should enable more automated CA options in the future.

Why is that? The damage from a CA being hacked is not proportional to the size of the CA - they are all equally (small number of exceptions notwithstanding) capable of issuing certificates for any domain which will be trusted by all major browsers.

Is there another aspect I'm not considering? While I see how it feels like a troubling thing, I'm struggling to actually come up with any real consequences of it.

I would use them if they turned this on and offered the service at a low cost.

There are several reasons that it could be good to have multiple publicly-trusted CAs out there, though most of them don't depend at all on the relative market share of the CAs at a given point in time.

Security risk If a particular CA is compromised through an attack and its intermediate certificates need to be revoked, it would be good to have other CAs already ready to continue issuance to the public. Even if the CA intends to resume operations after a compromise and user-agents are OK with that, it probably wouldn't be prepared to resume operations immediately.

Geographic risk It would be good for availability to have CA datacenters on multiple continents, not just one.

Jurisdictional risk The government of the country where a CA operates could try to compel the CA to stop issuing particular certificates, for example in order to enforce international sanctions, or to facilitate espionage by trying to make it harder for people to get authenticated encrypted connections to certain services. A government could even force a CA in its territory to cease operating entirely. (There's also jurisdictional risk in the other direction, of governments trying to compel misissuance, but this risk is strictly increased by having trusted CAs in more jurisdictions. In general, having more CAs increases the risk of misissuance, while decreasing the risk of certificates being unavailable to a particular site because people don't like that site or its operators for some reason.)

Continuity risk It would be safer to have CAs with more different kinds of funding for their operating expenses.

Institutional/governance risk A particular CA might some day decide to do things that relying parties find improper. Having more CA alternatives can give the relying parties more plausible leverage to get the CA to align its practices with their preferences. (As with the jurisdictional risk point, only a decision not to issue certain certificates can be directly addressed in the short term by having other alternatives. A decision to issue certificates that other people think shouldn't have been issued can probably only be addressed this way by removing trust from a particular issuer.)

Looking over this thread, I do want to emphasize again that misissuance risk gets worse, not better, when there are more CAs. If you're particularly afraid that CAs will be issuing certs improperly because they get attacked or coerced or do a bad job of validation or internal controls, you should probably want fewer CAs rather than more, at least as a response to that particular concern. This is because CAs in the X.509 PKI can't "contradict" another CA's issuance; every assertion about a binding between an identifier and a public key is cumulative and operates in parallel and in addition to every other assertion.

High profile sites can buy multiple top level certificates (with mutual signing, say); sites needing less security can fallback on a simplified consensus system (maybe like above).

Workable?

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.

Is having separate certs really that big of a deal? Operational overhead with LE is next to none and if you're scared of hitting limits you can contact LE to have the limits increased.

I'm not sure how up to date https://github.com/hlandau/acme#comparison-list-of-client-im... is.

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.

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.

It does not prevent people guesssing it tough.

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?

Strangely, our CA called our human resource department to verify a lot of the information. I guess its all in who you chose.

They do that at a minimum. OV and EV certs require more work and do verify who you are (for some definition of "who") and that's where the more expensive CA's add value.

I understand what the browsers do today and I don't believe this help protect people. It should be very clear what type of transport security is in use, along with a score and what type of identity has been verified and what that means. I honestly don't know the answer to this, but I do know the existing methods in browsers just doesn't give a clear picture to non technical people.