SoylentNews is people
SoylentNews
Arstechnica reports
In July of 2017, the nonprofit certificate authority Let's Encrypt promised to deliver something that would put secure websites and Web applications within reach of any Internet user: free "wildcard" certificates to enable secure HTTP connections for entire domains. Today, Let's Encrypt took that promised service live, in addition to a new version of the Automated Certificate Management Environment (ACME) protocol, an interface that can be used by a variety of client software packages to automate verification of certificate requests.
[....]Many hosting providers already support the registration of Let's Encrypt certificates to varying degrees. But Let's Encrypt's free certificate offering hasn't been snapped up by some larger hosting providers—such as GoDaddy—who also sell SSL certificates to their customers.
(Score: 4, Informative) by TheRaven on Wednesday March 14 2018, @03:21PM (14 children)
Why is this a problem? I have acme-client in a weekly cron job, so my certs are renewed (re-signed) each week. The 90-day limit is ample even if that cron job fails for a few weeks. 90 days seems like a good compromise: It's short enough that you have to automate, sort enough that your revocation lists don't have to be very long, and long enough that you automated refresh isn't very urgent.
sudo mod me up
(Score: 2) by Whoever on Wednesday March 14 2018, @03:28PM (3 children)
Weekly?
It isn't too difficult to write a script that looks at the expiry date and renews the certs when they are about to expire. Alternatively, monthly is fine.
(Score: 2) by lentilla on Wednesday March 14 2018, @04:44PM
It's not that it's too difficult to write a script, it's just that it's so very easy to get wrong.
With cronjobs (and their ilk) there are so many failure modes to consider, and each further test you incorporate needs to be validated in its own right and adds another potential point of failure. Having an automated process isn't like having a personal assistant who'll pipe and and say "hey, boss, I couldn't renew our certificate this week" and has enough smarts to call you on the telephone if you don't reply to an email.
Like you said, it's not difficult, but writing cronjobs is an exercise in abundant caution.
(Score: 5, Informative) by bryan on Wednesday March 14 2018, @05:03PM
The ACME client itself will take care of this. You simply run the certbot command in a cron job as often as you want and it only renews certs that are close to the expiration date. Example output:
(Score: 2) by TheRaven on Thursday March 15 2018, @08:37AM
By default, acme-client will only renew certs that are within 30 days of expiring, so a weekly cron job means that it will typically have 3 attempts to renew that can fail before you actually suffer from problems. I realised that I'd left -F in my acme-client.sh from debugging, so mine was actually renewing the certs every week. I was still well below the threshold for rate limiting by Let's Encrypt, so there isn't really a down side of doing this.
Without the -F, there isn't really a reason not to run the cron job nightly - it will skip certs that are still a long way from expiring and you then have 30 attempts for the cron job to fail before your users notice anything.
sudo mod me up
(Score: 2) by zocalo on Wednesday March 14 2018, @04:47PM (9 children)
Note that we're just talking a bunch of standard certs here - we obviously don't need EV etc. on a closed network, just for things to work - so cost of the certificates isn't really an issue so much as the time and cost of deployment and management given the available resources and skillsets.
UNIX? They're not even circumcised! Savages!
(Score: 2) by NotSanguine on Wednesday March 14 2018, @09:15PM (6 children)
If it's not exposed to the internet, just use self-signed certs. That's not the use case that Let's Encrypt tries to address.
Let's Encrypt's advantage is that is that browsers and other *clients* on the internet will trust Let's Encrypt certs.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 4, Informative) by zocalo on Wednesday March 14 2018, @09:58PM (5 children)
Again, it's not the cost, it's the effort required to effect the change and manage the process. The least effort comes from certificates that are already trusted by the clients (e.g. from a well known CA - typically someone like Thawte), have a multi-year lifespan, and require as little in the way of additional PKI infrastructure, custom scripts, or manual processes as possible.
UNIX? They're not even circumcised! Savages!
(Score: 2) by NotSanguine on Wednesday March 14 2018, @10:36PM
Absolutely.
I was focusing my reply (and incorrectly in your case -- my apologies) on the use case where *all* clients and servers were members of the same organization. In that use case, everyone (including the various client applications) should already trust the internal CA certificate.
Once you bring in users whose devices/applications that are not owned/managed by the same organization, that goes right out the window.
For your use case, a widely trusted cert is likely not a bad idea.
However, if resources on the servers are sensitive, encryption isn't the only concern even if external parties are involved. If you need to do client *authentication* as well as encryption, Let's Encrypt would be much inferior to an internal CA and self-signed server *and* client certs, despite the issues around distribution and maintenance of the client certs.
There are ways around such a management issue of course (VNC/RDP access from internal hosts, etc.).
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 0) by Anonymous Coward on Thursday March 15 2018, @07:40AM
(Score: 2) by TheRaven on Thursday March 15 2018, @08:39AM (2 children)
Option 1: The network is only used by a fixed set of clients, so you can push out your signing cert to all of them easily.
Option 2: The network is used by clients that move from other networks to it. In this case, the air gap doesn't really buy you any security, because malware can infect one of the clients from the public network and can spread to your private network. In this case, you may as well set up a DMZ to push Let's Encrypt certs into the network.
sudo mod me up
(Score: 0) by Anonymous Coward on Thursday March 15 2018, @09:04AM
For your regular malware, you are right. However, there are other ways to prevent those (updates, not running as admin).
A directed attack, on the other hand, is a lot easier if you have two way communication, and can attack one layer at a time, rather than needing to prepare everything ahead of time to sneak your attack in. It can be done - Stuxnet is an example - but your regular ADHD teen out to do some random damage is not going to take the time to find out the exact structure of the layers of security before even starting to write their attack code.
(Score: 2) by zocalo on Thursday March 15 2018, @11:11AM
Yes, a lot of the clients are fairly easy to push a new CA to, others just need a current cert and don't actually validate the entire trust chain so they're easy too (and could be selfsigned), the real PITAs are the propriatary tools that are at least partly managed by the vendor and don't tend to make the process easy *and* make people in management very twitchy because you're proposing a change to something they don't really understand but know that it's very expensive and very mission critical. Again, it's all about the paperwork and potential risk, not the cost, effort, or level of expertise, involved. The easiest and least frequent hoop to jump through is to standardise on a set of commercial certs from a widely recognised vendor that will work across every client and server and only require updating as infrequently as possible.
UNIX? They're not even circumcised! Savages!
(Score: 2) by NotSanguine on Wednesday March 14 2018, @11:14PM (1 child)
That's not necessarily true. Certificate auto-deployment is widely used in a variety of use cases, with client and server certs issued by an internal CA.
There are also a variety of mechanisms to automate certificate renewal, depending on the management platform in use.
This is especially important on secure wired and wireless networks which use 802.1x certificate authentication for access to the network.
There's nothing especially complicated about it, as long as you have appropriate tools, and the CA and policies defined around certificate issuance/deployment/renewal are properly defined.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 1, Informative) by Anonymous Coward on Thursday March 15 2018, @09:23AM
You are mixing up his reasons.
Deploying official certificates (such as let's encrypt) needs to be manual, as the renewal requires an internet connection and the network is not connected to the internet. This makes the 90 day limit inconvenient.
Using an internal CA is inconvenient for different reasons.
Either way, buying an expensive three year certificate becomes the cheapest solution.