but unlike us google essentially signs their own certs, making stuff a lot easier
1 Like
The point being that they’re brought up as an example because it’s good security, not because they’re the target market.
Also, I don’t buy into there being a huge difference between having your own CA: true certificate you use to sign your webserver certificates with, or using something like Let’s Encrypt. Sure, you’re relying on a third-party dependency, but that’s about it. You will need monitoring for either solution, and manual intervention if something goes wrong. The truth is that it’s quite likely Google has some similar mechanism to ACME internally to issue certificates and protect their root (they wouldn’t get a CA: true cert from any trusted CA otherwise).
1 Like
well it might be better if if automation is really the target why not just make 24 hour certs because if anything is really compromised 90 days should be more than enough and there’s stll the revocation…
also maybe it’s simpler as you think. instead of the webserver asking for a cert it might just be that a cronjob makes a new cert on the server, puts it in place and lets it restart which is far easier to make than this whole acme thing which runs with a self-updating potentially insecure/unstable client (what happens if their gitgub acc gets compromised? there’s no signature or anything that lets the user verify that the client is okay and in an automated environment no one is going to check the source of each update…
also even if 90 days might be a bit more secure I think there should be an OPTION for manual mode users to get longer certs.
3 Likes
Because even though it has been a stated LE desire that level of automation is only a goal and at this point nothing more than a pipe dream. Very far from reality.
1 Like
With the amount of nonsense on the internet I never put it passed anyone what they could actually mean seriously. Further more I don't try. I take them at what they write. It they are joking their are emtionicons that can be used to indicate that. If they don't use them then I have no way of know. And I'm not going to try mind reading over the internet with someone I don't even know.
1 Like
but well I am on the side for longer certs, so there’s no way I would seirously want them to make certs that are valid for a day, well the die-hard ultra-security people could maybe make it with an option but I want to be able to make longer certs in manual mode.
1 Like
[quote=“My1, post:239, topic:264”]
instead of the webserver asking for a cert it might just be that a cronjob makes a new cert on the server, puts it in place and lets it restart which is far easier to make than this whole acme thing which runs with a self-updating potentially insecure/unstable client (what happens if their gitgub acc gets compromised?
[/quote] isn’t that essentially what Letsencrypt webroot authentication does and can do (regarding cronjob) ?
That’s what I am doing with my integration of Letsencrypt client (via webroot) and automating renewal every 60 days via a cronjob (that is auto generated at Nginx vhost domain creation time)
1 Like
well not exactly, google doesnt need any verification and google could set an access from the “CA Server” to the webserver so the “CA server” SCPs the cert into its location and restarts the webserver via SSH which is doable in less than 20 lines.
to line it out:
CA signs cert -> access to webserver -> puts cert in place -> restart/reload webserver
these 4 steps get cron’ed and make a pretty short script which can be easily audited
while the whole acme implementation has a python script with iirc more than 10k lines and more than enough dependencies (why create a vm environment?)
while with acme you have to do a verification and you are dependent on a pretty large software with probably quite a list of dependencies (takes half an eternity to start this thing because it updates itself at every start)
1 Like
not if you run ./letsencrypt as opposed to ./letsencrypt-auto command for webroot authentication
1 Like
but still the Google has it’s own CA males it a lot easier since when the CA is on a server with one-directional access to the webserver to copy files and execute commands automation is quite easy and doesnt require a large-scale software as le-auto which probably has enough failure points (one of them being the compatibility)
even I might be able to write a bashscript that creates a key, CSR and sign that and push it over to a server and I have not much knowledge with bashscripts.
when DANE is a thing I might even use my raspi as CA-server…
1 Like
Well in real world, you make do with what you have to work with and we are no Google in terms of man power or $$$.
It takes 7.8 seconds to run a cronjob to auto renew a Letsencrypt SSL certificate via webroot authentication - I timed it http://centminmod.com/letsencrypt-freessl.html#autocron 
1 Like
wow, when I invoke the command in the email plus -a manual it takes MINUTES for it to start asking for sudo and again some minutes for the virtual environment ojn my raspi.
1 Like
i don’t use letsencrypt-auto command for cronjob this is my webroot authentication commands in the cron file at /usr/local/nginx/conf/ssl/le11.http2ssl.xyz/letsencrypt-le11.http2ssl.xyz-cron
/root/.local/share/letsencrypt/bin/letsencrypt -c /etc/letsencrypt/webroot.ini --user-agent centminmod-centos6-webroot --webroot-path /home/nginx/domains/le11.http2ssl.xyz/public -d le11.http2ssl.xyz certonly
/usr/bin/nprestart
1 Like
well for you it’s still easier, I have compatibility issues, my Win-PC with xampp aint compatible with LE, making automation useless for that one.
1 Like
yeah windows not sure… maybe virtualbox or vmware linux guest OS ?
1 Like
well I use my raspi to get the cert but I have to do the validation manually…
especially coz my domains have different roots and I want a SAN.
1 Like
I'm not sure if 'pfg' is speaking officially for LE or not but I reply to him as he quoted me. If he is a regular supporter then some of this is not directed at him personally even though it might sometimes seem like that, apologies for that.
Sorry just a quick note here so others don't misunderstand as well. I was (and am) comparing LE with Zimbabwe (1) . I was comparing potentially compromised LE administrators to the dictator, Robert Mugabwe would regularly tell his people what was good for them. Your reasons wondering why LE would be the target of compromise are sadly EXACTLY the reasons that it would be the target. It is free, perceptively light on client details and provides a service that non technical people could integrate in standard software. Now if I was the NSA and wanted a means to inject certificates into small independant sites that wanted to fly under the radar who would I approach, LE is just the ticket, it bullies customers to use a user interface that is a single point of failure for a large number of users, it has a recurring mechanism for monitoring activity, there (may or may not, I don't have a full understanding of these things) be traffic to the co-signing authority at some stages of preparation or use. All these things lend themselves to being a lovely CA to compromise and are THE MOST IMPORTANT reason that LE should be so open and transparent about why they RECOMMEND the 90 days and be the most willing to accommodate reasonable requests from end users who have LEGITIMATE or PERCEIVED security concerns.
I am making exactly that claim so you can believe it, it has been made by at least one other (perhaps more) on this thread so I am not hallucinating, I am guessing that the thought has crossed a few more minds. Misreading my comment and making it sound like I am trying to make LE out to be bad is not justified, I lie awake at night hoping for a free and open CA (no not relay but I would learn to use it is I trusted it) I want LE to succeed, a cloud of suspicion does not count as success in a security application.
I was not here at the start but again what I have read and what has been written on this thread lead me to believe that this was not the published brief at the start, this is why I and others have justifiable and unanswered cause to say that LE administrators are [quote="pfg, post:236, topic:264"]
"ignoring" the feedback
[/quote].
Plenty of 'empty' feedback that amounts to 'my way or the highway' and using words like 'push' to motivate your target market are far from a misunderstanding, it is a reasonable assumption to make unless something more clear comes up. We have heard LEs reasons and the replies here have offered some (well) reasoned workarounds to some of the concerns and may even have changed some poeples minds about some reluctance in some cases. But the big one keeps coming up, where is the cost to LE to let the certificates last longer unless it is pushed from upstairs.
Every reply I see supporting the LE way makes me MORE convinced it is a honey-pot because each one is just getting more entrenched with the party line instead of trying to support the STATED target users, those that want a free adjustable lifetime certificate. After all it is so easy to prove me and all the other critics wrong, it is just a constant in a file somewhere, not an optimised or justified ideal that has to be protected at all costs and don't for a moment think that everyone will dismiss all this dialogue.
As has been advanced by a few others I can only suggest that the way to solve the problem with goal 1 in a robust way is to have a change of heart, (say a security expert recommended it if you want to save face) and make the lifetimes selectable so people have trust in LE and the use of certificates grows.
Then to support the added secondary goal of systemic automation for reasons that are not even all totally clear or universal the LE team will work (probably with enthusiastic support from many volunteers and testers) to make the user interface so easy, secure, open, simple, practical, universal, robust and desirable that people crave to use it. Also publish all the security experts research that shows WHY 90 days is better and how it is so easy to implement.
Just in case the business case is clouding judgement, recall there is no loss of revenue to consider here, something else is at stake.
(1) My apologies to those that are not that altogether familiar with the Zimbabwe case. It was called the bread basket of Africa at one time with huge maize, tobacco, mineral and metal exports. It had one of the highest literacy rates in Africa, the press was free and tourists came to visit. Post Mugabe and hyper inflation the country is a basket case. I hope LE does not take the same direction. We just have to remember what dictators can do, dictate, the reasons do not matter so much in the end if the results are unsound it is a bad ship to sail on.
2 Likes
... stopped reading here ...
Congratulations! You have just lost the right to talk to me!
... and up to a few minutes ago I was actually glad that no one tried to prove Godwin's Law right!
1 Like
So one last technical point below, since I don't want to attempt to convince you of anything else, you obviously have your own belief system and I'd rather just agree to disagree on the rest (and hope this is all just some elaborate trolling attempt).
"injecting certificates" doesn't make sense. Historically, the CA system is built in a way that essentially means if one CA is compromised, the entire trust chain is broken and you can forge certificates for any site. This is getting slightly better nowadays (key pinning etc.), but NSA and friends really don't need Let's Encrypt to be able to do that, they can just go to any of the other trusted CAs.
Furthermore, Certificate Transparency means that all issued certificates (that's including the domains they were issued to) already get published to a public, append-only log. It's expected that all CAs will have to implement Certificate Transparency in the near future. This is in reply to your fear of "monitoring activity" - publicly trusted certificates already are (and should be!) transparent and public.
1 Like