HN user
I recommend updating the title to make it clear that only the Let's Encrypt client software has changed its name (and moved to EFF). The Let's Encrypt CA has not changed anything.
More information about this move can be found here:
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 sponsor@letsencrypt.org 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.
Windows XP support was rolled out March 25 2016.
You can find more information about upcoming and completed features here:
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.
Here is a more complete explanation of Let's Encrypt's views on the subject.
https://letsencrypt.org/2015/10/29/phishing-and-malware.html
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.
Let's Encrypt • Full Time • Remote • U.S. and Canada
Let's Encrypt is looking for a lead developer to work on our core CA software as well as the Let’s Encrypt client. This includes fixing bugs, adding features, and improving performance. Security is our highest priority, so be prepared to focus heavily on this aspect of the work.
As a leader you’ll help us to prioritize work and grow our community. You’ll help to create a welcoming environment for new contributors and set an example with your development practices and communications skills.
More information:
Checked with a sysadmin. I'm pretty sure it's a ciper suite mismatch. The helloworld site is configured with "modern" settings from this page:
https://mozilla.github.io/server-side-tls/ssl-config-generat...
We only issue DV (Domain Validation) certs. DV certs don't include ownership information.
Agreed, I don't understand why so many people use homebrew instead of macports. Macports seems to be immune to so many issues that complicate homebrew, and I love that it keeps everything in its own dir, '/opt'. Easy to see what it installed, and easy to uninstall (rm -r /opt). The commands are also easier for me to remember -- no awkward, overstretched analogy.
I often help people start hacking on open source projects and I can't tell you how many times they've made a mess with homebrew, nothing works. Replace homebrew with macports and their problems are solved, rarely to return.
Maybe in some cases homebrew installs something a bit faster, but it's rarely a meaningful amount of time and it doesn't make up for all the time spent fixing homebrew when it messes up.
When I was car shopping the VW diesel numbers, for tdi sportwagen in particular, were impressive. Nothing else came close to VW's combination of power, space, and mileage. Now maybe there are people who know more about cars than I do and can dispute that, but that was my perception a couple of years ago.
If I were the other car companies, I'd want to know exactly how VW was pulling that off. They must have looked into it, and surely they're not as easily misled as I apparently was (how would I know if VW was outright lying about the car?).
This suggests to me that the other car companies must have known that VW was doing something wrong. The fact that they didn't rat VW out suggests to me that they were either doing the same thing (maybe not as aggressively as VW) or they hoped to get away with the same thing. The former seems more likely, and if that's true then I expect this to spread beyond VW soon.
We need to demonstrate proper issuance under our root and gain confidence in our live systems before getting cross-signed. Issuing without a cross-signature for a bit is how we do this.
Fixed, thanks for pointing that out.
Let's Encrypt | Full Time | Remote
Let's Encrypt is hiring another sysadmin. Help us make HTTPS ubiquitous!
Looking for security-conscious systems administrators with the following qualifications:
- Strong familiarity with enterprise networking, such as firewalls, network isolation, VLANs, and data backups.
- Extensive experience implementing hardened systems with high capacity, high availability networking.
- Strong understanding of virtualization.
- Skills with git, saltstack, shell scripting.
- Excellent English communication skills, written and spoken.
Position is remote, can hire in the U.S. or Canada.
Email resumés to: it-jobs@linuxfoundation.org
The Firefox (Desktop) UI is already rendered using Gecko. It has been that way since the beginning.
Mozilla spends much more time optimizing HTML and other Web content tech than it does optimizing XUL and XBL. I wouldn't worry too much about this project slowing down Firefox. It might even speed it up a bit.
Some context that might help people understand this email...
There are two high-level components which make up Firefox. The first is Gecko, the rendering engine. The second is Firefox, the application itself, which uses Gecko to render Web pages and itself.
Firefox, built on top of Gecko, is written primarily in XUL and XBL (and JS).
https://en.wikipedia.org/wiki/XUL https://en.wikipedia.org/wiki/XBL
What's going on here is that Mozilla is considering getting rid of XUL and XBL and building Firefox with the same technologies that people use to build Web content.
There are at least three big advantages to doing this:
1. Eliminate the need to support XUL and XBL in Gecko.
2. Contributing to Firefox gets easier because there is no need to learn what are essentially Mozilla-specific languages.
3. Mozilla learns more about what it takes to build complex applications like Firefox itself using Web technologies.
The only real downside is the amount of work involved.
Glad you like the project!
Contributing to our software is one way to help:
https://github.com/letsencrypt/boulder
https://github.com/letsencrypt/lets-encrypt-preview
Also, if you work for a company that might be interested in sponsoring us, starting that conversation is another great way to help out.
HSMs can typically duplicate keys to other HSMs (though usually only other HSMs from the same vendor). All of the Let's Encrypt private keys are stored on multiple HSMs.
It's also on our website.
Maybe, but it's hard to get me too worked up about this mechanism when the government has people lined up to be killed.