Let's Encrypt announces browser integration Let's Encrypt has announced that it's received cross-signatures from IdenTrust. The free-certificates-for-all venture, set up by researchers, the EFF, and a bunch of supporting vendors, says the cross-signatures mean the major browsers can now receive Let's Encrypt certificates without throwing an error. The cross-signatures …
And yet with all of this engineering resources, browsers still don't add a simple check of the SHA512 hash of the certificate matching the DANE entry in DNS.
Why wouldn't you do that? It's almost like someone powerful has access to a commonly trusted CA to spoof arbitrary identities on the Internet...
? What's that got to do with anything ?
Private keys always stay on computers. GP is talking about private keys of "trusted third parties" not staying where they "should" be. That is - hello Veris*gn I'm the NSA, sign this for me.
Or do you think that has never crossed their innocent little minds?
This post has been deleted by its author
Client a *fecking nightmare* to use.
Tried to install it on an Ubuntu 10.04 LTS server. Not a chance.
You clone from github which runs a Python program which is really a Docker-container (? I could be wrong here) which downloads its own set of dependencies which don't always work. Then you are told to do --help... you do that and the syntax in there is wrong and/or massively incomplete (unless you have a fully working Apache setup on the same machine - why would you sign certs on the web server itself?). Only in the wiki does it mention plainly that -d selects the domain.
The Apache setup didn't work for me on 10.04 or 12.04 LTS with default Apache (couldn't even find the default site). The standalone setup requires you to kill apache and/or otherwise have port 443 open. The manual setup involves copy/pasting a convoluted bit of key into a horribly convoluted named file publicly accessible on the website (much more than, say, a a google file verification or even a TXT record verification). Then if you get all that and battle through the junk, it produces only a test cert that you can't use yet or - if you sign up for their beta and are approved - might work.
It took me a LONG time to get a single cert out of the system and only worked by doing so manually (and then having to manually edit the Apache setups, etc. to use the key). I know free SSL certs are great and everything, but the amount of hassle is unbelievable given that it's supposed to have a one-click client.
They REALLY need to make a much simpler client to create these things, that doesn't try to BY DEFAULT mess up your Apache config to shove the keys in. Let's not even get into what will happen when you need to auto-renew etc. At this point, my old OpenSSL cert generation scripts and an upload to an SSL signer over the web are infinitely simpler.
"They REALLY need to make a much simpler client to create these things, that doesn't try to BY DEFAULT mess up your Apache config to shove the keys in."
No thanks for confirming my fears. Both control panels I use re-write the Apache conf includes every time something changes so anything not included in the control panel database gets overwritten as anybody who has tinkered soon discovers. I am assuming anybody who is going to run a production website on these control panels is going to have to wait until Let's Encrypt is specifically supported as a feature or they publish a workaround. Hello cPanel, ISPConfig?
Otherwise it may be a darn site easier to stick with our 'free' friends in Russia & China when installation is a 5 minute job and good for a year. Surely it would have been faster and cheaper for Let's Encrypt to have refined their processes a little and spent more time doing some great 'HOWTO' YouTubes for the lesser washed site admins? The 90 day thing is just ludricous.
They REALLY need to make a much simpler client to create these things, that doesn't try to BY DEFAULT mess up your Apache config to shove the keys in.
Precisely my concern with it actually. And not that the client is crap (going on your experience), but far more basic than that.
I don't want any automated script fuzzing around with my certificates. I've no issue with manually visiting a site, providing details and then configuring enabling the certificates once my CSR has been signed.
LetsEncrypt looks great in principle, but why would I trust any third-party script to take control of something that has a huge impact on the security of my visitors sessions (not to mention, as you found, the impact if your config isn't what they expect it to be)?
If/when there's a manual process, I'll be more than happy to use it (and might pull the client apart to create my own process in the meantime) but automatically installing, configuring and renewing certificates? Nah, that's a job best left to someone I trust - or at least can blame when they balls it up.
The best bit is that the install process as it stands is to git-clone a tree.
Then run a script.
That script needs privileges and then runs off and creates its own environment, installing Python packages and all sorts inside it. Sure, it "doesn't modify" your real environment, but it's not a nice thing.
And consists of a HUGE script that you have to execute after auditing. Then you're left with a script that auto-updates the install environment automatically (I fought with it for an hour because there was a mysql update that I'd put on hold and it refused to carry on installing the packages it needed despite not actually needing mysql!) every time you run it which is the PRIMARY INTERFACE to the certificate creation. Apparently you can only run as non-root for the manual mode because, obviously, the default mode is automatically playing with your Apache config.
And, I'll be honest, it looks like junk. They load up a dialog interface at one point. Agree to EULA. Select Auto (i.e. plug into Apache), Standalone (i.e. run its own daemon on 443!), or Manual (i.e. it creates a cert and you do the rest), Then it kicks you back to the commandline to view a horribly long copy/paste string which breaks across multiple lines, which you need to copy into a filename on your web server that similarly long and word-wrapped, before you press Enter on it and then it runs off and checks and says Yes/No. Sounds simple? If the mime/type isn't correct, it won't work even with the file in the right place with the right name and right data, and I had to use .htaccess and mod_headers to ADD a new mime/type just for that damn purpose and just for that damn folder.
Then, maybe, if you get the command-line right it'll churn out a cert for you. Currently signed by an un-rooted CA, but if you get on their Beta program or wait, you can make it work with a signed CA for a select set of whitelisted domains that you tell them. So you can imagine the amount of testing this has gotten in real life. In fact, you can see for yourself. They publish a list of every domain they publish a cert for (hope your weren't certing anything private!). There's not a lot on there.
I really, really, really, want and need for this to work. But the client is just junk. I'm hoping that in the first few weeks of proper release someone else will publish a tool that "just works" either online or on a command-line that you can use sensibly (why it can't be a bash-script, I have no idea).
And then rinse and repeat every 90 days. And by the looks of it, that period will only get shorter not longer
I love the idea of letsencrypt, but that thread gives the impression the backers (and at least some of the community) have a much more "dev" mindset than an "ops " one. Having to restart processes every 90 days just for a SSL cert is lunacy - even where the daemons support a reload instead, I'd still rather not be running around reloading services in production environments too regularly.
Standalone (i.e. run its own daemon on 443!)
Yeah, I saw that, it's on my list to tinker with and try to poke holes in....
If the mime/type isn't correct, it won't work even with the file in the right place with the right name and right data,
Out of curiosity (but not enough to go and look) what mimetype is it expecting?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
