joshmoz

You don't have to change anything.

We would love to have Apple and Microsoft on board. If anyone works for them and wants to help get them to sponsor we'd appreciate it!

Email [email protected] to coordinate.

It's also worth pointing out that you can have up to 100 SANs in a certificate, so you can technically issue for up to 20x100 (2000) subdomains per week.

I implemented the native OS X notifications in Firefox/Gecko some years ago. The native OS X API limitations were pretty frustrating (at least at the time, iirc), just didn't line up with the Web APIs all that well. Not blaming Apple, they weren't designing with our use cases in mind, just saying I can understand Google's temptation to avoid integration in order to retain control.

In the end it's a tough call about what you value more.

I worked with Robert at Mozilla for many years. He might be the most talented software engineer I've ever met, and he's a strong candidate for nicest person as well. An absolute pleasure to work with. Mozilla will miss him dearly but some other project (apparently rr) just got really lucky.

Head of Let's Encrypt here.

We considered introducing a site seal because it's a common request but we've decided not to do it (at least for now) for reasons similar to many in this post.

It's hard to design a seal that accurately conveys the value added to a site's security by a CA, and the potential for abuse is high. A CA seal either means nothing or implies too much because having a cert from a trusted provider is just one part of what it means to be a secure website.

Head of Let's Encrypt here.

We were aware of the "google.com.mg" cert soon after it was issued. We didn't revoke the cert for the same reason we don't revoke most certs: as far as we can tell, the cert was issued to the entity properly controlling "google.com.mg". Whether or not that is Google (the company) is not really within our purview.

That said, in this case, as a courtesy, we did notify Google employees and made the decision to report the site to Google Safe Browsing. GSB and SmartScreen are the right places to deal with things like this.

IIRC GSB did block the site for a while, but that block seems to be gone now.

Head of Let's Encrypt here. Our #1 expense is salary/benefits (we are hiring, letsencrypt.org/jobs). Other major costs include hosting, auditing, hardware, and legal/administrative.

Head of Let's Encrypt here. I don't love the number of dependencies for our client either, we're going to work to reduce them.

Let's Encrypt is cross-signed by IdenTrust, not Entrust.

Head of Let's Encrypt here.

You nailed it. It's important that our certs be free because we can't automate a billing interaction. If we had to charge then sysadmins couldn't just type a command and be on their way. Automated renewal could fail because billing info was out of date. This stuff has to just work, reliably, if we're going to expect the entire Web to use TLS.

Let's Encrypt / ISRG ED here.

The official client is intended to have a simple mode as well as a "full-service" mode. That said, our client is never going to be ideal for everyone. We'd be happy to see others create clients that work well for them!

We'd also like to see support for Let's Encrypt built in to servers, so a separate client isn't necessary. That would really allow for the best, most seamless user experience.