Check out Caddy Server. It was only a few days ago when I was still managing my own certs and renewing them with a Cron job. Caddy now acts as my proxy for my various web domains and it handles certs automatically. Like literally you fill out a few lines in the config called a Caddy file and you do Caddy run and it gets the certs itself. And as long as it's running, it renews them automatically.

Giving an Internet-connected program autonomous write-access to system-critical filesystems is not considered good practice in production environments.

Much better to have a separate central cert management system that handles renewals and pushes the certs outwards to the DMZ systems.

This is true for enterprise, but for small business Caddy or Traefik is totally fine.

Caddy is good for enterprise use too because of its configurable, pluggable storage backends (doesn't have to be a file system). You can achieve the permission segmenting your company requires.

You can also use it as a certificate manager independently of a web server if you want.

Responsibilities have changed a bit. If you're going to host a website you are going to have to put a modicum of effort into ensuring that you are not harming others by doing so.

>are not harming others

How is HTTP harmful when you visit my website about amateur radio? An expired cert is no more harmful than bare http in this non-commercial non-institional personal context. It's the one being discussed in this sub-thread in case you missed it and assumed the normal HN business context.

The burden is real and completely unecessary for personal websites. This makes the web more commercial by imposing commercial requirements on everyone.

It's what killed off self-signing as a speed bump against massive surveillance and centralized everyone into the benign dictactorship of letsencrypt. But centralization will lead to problems when money is involved. Just look at dot org.

The real harm comes from this fetishism of commercial/institutional security models.

> How is HTTP harmful when you visit my website about amateur radio?

"Unharmful" HTTP sites are used to silently hack people's computers and keep them under observation for months. Every unsecured site contributes their small piece to keep the web unsafe for people who needs it to be safe.

https://www.amnesty.org/en/latest/research/2020/06/moroccan-...

This is exactly the same as blaming getting shot at a neighbor's BBQ on the neighbor for not hiring private security to deal with the government army specifically attacking you.

If your threat model includes nation state attacks you're gonna have problems no matter what. Change your personal behavior accordingly. Don't tell everyone else they need to wear bullet proof vests around the house and hire corporate security goons. They don't and doing so is burdensome.

You're right, today. But as everything, stuff that starts as very advanced tools only at the disposal of big agencies, with time ends up being reachable for more mundane users, or in this case, criminals.

So, in a way, it's probably just a matter of time that the kind of silent hack depicted in the Amnesty article is used for attacks targeted towards more general victims. I don't look forward to the day that just by reading an unprotected HTTP site is enough to get my phone compromised as part of a widespread scamming effort from someone trying to get credit card details or banking stuff... but it will propbably end up coming if we don't move all together for a more secure WWW.

I know complaining about it won't change the future course of things but these are all problems coming from treating the browser like the OS and exposing more and more low level functionality.

They aren't problems with security in HTTP versus HTTPS for a personal or small business static website.

Totally agree. The current situation with the complexity of browsers is crazy. Its implications are spoiling all around other technologies and causing all sorts of issues, like this one.

The problem with your analogy is that it downplays certain aspects and plays up others.

Attacks on HTTP sites are known threats that we have evidence for, they aren't ridiculous or unheard of. The defense is not "everyone where a bulletproof vest", it's get a certificate and set up HTTPS - a one time cost that will protect thousands of people.

You're making the choice for your users, who may not be as informed as you are, to not protect them. That's very different from asking them to wear a bulletproof vest.

Agreed. I'm sick to the back teeth of fscking with HTTPS/SSL on all the client static sites I manage. Certbot-apache was so flaky I had to switch every client to Nginx so that I could use certbot-nginx. The web has become a no-go zone for do-it-yourselfers. If I didn't setup my clients in VPSs I don't know how we would manage all the mailserver blacklisting and endless HTTPS/SSL requirements.

dehydrated is nice and painless.

These days, it's harder to set up a website _without_ SSL/TLS. If you're buying a domain name, they'll likely offer free HTTPS. If you're setting up a site via Shopify / Wix / etc, it'll use HTTPS. From what I've seen, sites without a valid certificate are either ancient and no longer maintained, or are built by devs learning the ropes of web development and haven't bothered to set up certbot on their server just yet.

There was already a fetishism of commercial/institutional security, and LetsEncrypt gave it quite the blow. Now companies that you used to have to pay a yearly fee for a certificate are offering their certificates for free.

It does stink that corporations have to be in the middle in the first place, but that's due to the difficult problem of "trust." I'm not sure it's possible to decentralize it, besides some sort of blockchain solution that would be unworkable in the real world.

> It's the one being discussed in this sub-thread in case you missed it and assumed the normal HN business context.

I did miss that but I did not assume a business context.

> The burden is real and completely unecessary for personal websites.

Users who visit your website are still at risk of having their connection hijacked - they could be phished, exploited, etc. This is maybe not something you consider important, it is certainly a sort of "boil the ocean" approach, but given the efforts put in up until this point I think it's already the case that most users are probably not visiting HTTP sites on the average day. Continuing that effort seems reasonable.

> This makes the web more commercial by imposing commercial requirements on everyone.

I'm not sure what you mean.

We have had this conversation to death: https://doesmysiteneedhttps.com/

I find some of the arguments on that page, uh ... unhelpful at best. Circular, even.

I guess I could see that for a small subset of the arguments presented, but that leaves all the rest. Honestly, "There's nothing sensitive on my site anyway." covers 90% of arguments I've seen against HTTPS and that answer is strong. The presence of weak arguments doesn't undermine the strong arguments.

There are injection tools that don't seek to steal data, but to weaponize your client.

It’s free to own a certificate today, so doesn’t matter.

This is silly to use as a blanket statement. There is nothing harmful about hosting a website. Especially personal sites, internal sites, or small businesses who use it as little more than a brochure that serves static content. My roof repair guy is not harming anyone by posting his information on a basic website.

What if I visit your roof repair guy's site and content is injected, informing me that they now take payments online? Or that I can download their special Roof Repair App to manage my bookings? Or it contains an exploit payload?

It is extremely uncommon for me to actually visit an HTTP website - I even have HTTPSEverywhere block them by default, so I'd know if I were. That means that I am relatively protected to such avenues until I visit your roof repair guy's website.

If I was the bad actor I would simply purchase google ads in the name of the target business sending traffic to my own site with wonderful green padlock - it's cheaper and has bigger reach than trying to hijack TCP/IP traffic.

More to the point - if I am running a collection of Karl Marx works it is highly unlikely that he would request payments.

You're describing a completely different attack vector, which is the entire point - to push attackers to different attacks. if we eliminate HTTP, we can focus more effort on the attacks you're describing.

Regardless of the content, hijacking is a danger to users.

It's worrisome that you injected yourself into the conversation between me and my users. How is this any of your business?

I don't really understand your point. You're upset because I am advocating for your users despite not being one? I... don't care at all.

It isn't my business so I've done nothing to reach out to your users or interfere in your website. We're having a discussion about technology on a technical forum.

It is the browser developers' business though since they are tasked with protecting users from these specific threats.

Because he might be a user too.

And are you blocking all Web traffic except from people who your users, somehow? If not, then everyone is your user.

One reason for these proposals was to put pressure on the SSL certificate ecosystem to provide (CAs) and adopt (hosting) automated SSL renewal practices. Businesses have had three years since Let's Encrypt first went live to adopt such practices, but many chose not to — not just hosting providers, but e.g. bigcorp load balancers too.

Guess what - not all websites are businesses. In fact not all websites are dynamically-generated so why the fsck do we all have to put up with this madness? Make HTTPS/SSL necessary for transactional sites but for simple static sites give me a break.

did you know there are ISPs out there that inject garbage code into the html of unprotected sites?

get out of here with this HTTPS is unnecessary tedium.

Better not do business with shady companies then.

or you could follow established best practices and secure your site with TLS.

Both. I am not responsible if you chose a shitty ISP.

But this makes no sense because the user has basically zero control of how their traffic is routed to/from you.

If we could trust the entire network we wouldn’t need TLS for any site.

There are lots of good options for low-maintenance SSL certificates, from self-hosted (Let's Encrypt) to CDNs (CloudFlare) to hosting platforms (Netlify).

Even so, this doesn't actually change much. I've never bought a certificate valid for more than a year. I'm not aware of any major player that sells certificates valid for more than a year. So this rule has existed for a long time in practice, but is only now being codified.

I genuinely believe that in 2020 the myriad of ways of getting automated TLS is easier than logging into a website and uploading a CSR and then placing that certificate somewhere.

Check out Certera https://docs.certera.io

It's PKI for Let's Encrypt certificates. Helps you issue, renew, revoke certs from a central place. Also get alerts so you know when things have changed, expired, failed to renew.

While a lot of places give you certs built in, there's a whole world of places you still need certs. Like FTP, mail, behind load balancers, disparate environments and systems, etc.

In the future, I'm planning on creating a way to automate the certificate exchange process. This should help with using and exchanging certs used in client authentication and things like SAML SSO. If expiration get down to a month or less, I see a need for a system to help do all of these things and more.

This looks interesting as a log of Let's Encrypt certificate operations, but is it more than that, and why would I want to use it?

To centrally manage all of your LE certificates, keys, alerting, etc. You can also more easily use LE certs in a wider array of scenarios too. Check out the docs to learn more.

I did have a look at the docs, but they more explained the how, rather than the why - I missed some kind of intro/overview explaining the value proposition.

I'm still a bit fuzzy on this - why would I want alerting, for example? Automation is a big part of LE, and my certs are configured to auto-renew. If that was to fail for some reason, then LE will send me an email - is it this part where this tool comes in, providing improved alerts where automation has failed?

That's great feedback. I'll update the docs to better explain the why.

To elaborate on the why for alerting, there are many situations that I've seen where things change and subsequently fail silently. Perhaps some dependencies, or maybe configuration changes, caused things to break. Also, alerting doesn't only have to be for your certificates. You can point to any endpoint to monitor as well. There are three aspects of alerting: changes to the cert (perhaps you care about a 3rd party certificate and its underlying key changing), failure to renew, and expirations. Each comes with its own benefits and use cases.

To expand on the why a bit further for the project as a whole, it's really as a way to help consolidate and centralize things. I've seen many disparate ways of using Let's Encrypt. From various clients to some hacks to better support more complicated scenarios. By separating obtaining the certificate from applying, it helps facilitate many things, like using LE certs behind load balancers & proxies, non-standard ports, things that don't speak HTTP, etc.

If certificate expiration continues to decrease in time, we'll need some capabilities to exchange certificates in an automated fashion as well. I'd also like to incorporate Certificate Transparency logs so you can be sure no one has issued certs for your domain(s). There are many cool and interesting scenarios but mostly the challenges come when managing things at scale. So, it's not really all that useful if you're only managing one or two certs.

You've got it backward. It is a boon for small players and troubles for large companies.

Small players can easily get certificates manually or automate. The platforms/tools they use often give certificates out of the box (cloudflare, heroku, wordpress, etc...).

Large players can't manage certificates. Developers/sysadmins can't use let's encrypt because it's prohibited by higher up and blocked. Even if they could use it, it's not supported by their older tools and devices. The last large company I worked for had no automation around certificates and the department that handled certificate requests was sabotaging attempts to automate, possibly out of fear of losing their jobs.

> that still takes some time to set up, manage and maintain over time.

I’d say it takes less time than going through a single paid certificate store… Assuming you already have a tool. If you don’t, then maybe it’s the same or 5 minutes more.

Can you describe the kind of person who hosts their own website but cannot easily set up Let's Encrypt automatic renewal?

There's no cert because there's no need for one in the first place. Mentioning that is pretty silly - it's obvious that there's nothing wrong with a static site with now cert, and no one is arguing against that.

> no need for one in the first place ... it's obvious that there's nothing wrong with a static site with no cert

Oh yes, there is.

https://doesmysiteneedhttps.com

> YES

> Your site needs HTTPS.

> there's nothing wrong with a static site with no cert

Not really. Google says "switch to HTTPS or lose ranking":

https://webmasters.googleblog.com/2014/08/https-as-ranking-s...

Good to note. But I think you're distracting from the article's talking point.

I disagree with "switch to HTTPS or lose ranking", but that's an HTTP vs. HTTPS issue with Google's search ranking, not about Chromium or Mozilla. This article is about Chromium & Mozilla making stricter rules for HTTPS certificates. That's not a bad thing, to hold HTTPS sites to a better standard.

The whole "Let's Encrypt should solve all your problems" attitude is arrogant and short-sighted.

1) In my experience the user experience even for technical admins is still flakey on at least some popular platforms. In other words, it's not as incredible as you think.

2) It's not available to a host that doesn't connect to the internet but does occasionally get connected to by a local browser (eg. IoT firewalled inside my LAN is one obvious such case; I'm sure there are others).

And most importantly:

3) You'd have to be insane or naive to accept an architecture that leaves you dependant on a single vendor (especially if you need that vendor more than they need you!).

How fortunate, then, that LE isn't the only vendor. Not even the only ACME vendor, nor the only free vendor (https://zerossl.com/features/acme/).

If your device never connects to the internet then how would any public cert work? It would expire like any other?

Me. I use shared hosting on a server that runs a reverse nginx proxy to my nginx server. I don't have root on the server. I have a LE cert that I need to manually fiddle with DNS settings every 3 months to get. If you know how to automate it I'd love to hear about it.

Why doesn't their nginx proxy /.well-known/ requests for your domain to your nginx? Then you could just use `certbot certonly --webroot --webroot-path /path/to/webroot/for/your/domain -d your.domain.name -d www.your.domain.name` once and put `certbot renew` and nginx reload in crontab weekly, and you're good to go.

If you can't use HTTP-01 and must use DNS-01 challenge, I would check whether the software that runs your host's DNS management panel has an API in addition to manual mode. If not, I would check for ability to automate HTTP requests to that tool (parse the HTML, submit the forms, basically). My hope would be that the tool is popular and someone already did the work and code exists to operate it as if it had an API.

If you can do that, you can write (or find one already written) a certbot plugin that performs the DNS challenge using your credentials to the host provided DNS settings. certbot has number of plugins for the big hosting providers: https://github.com/certbot/certbot

certbot is the most popular Let's Encrypt client, but it's not the only one. Maybe another client has support for your situation. I would maybe ask the support of your hosting provider, maybe they know something.

Letsencrypt is broken or an incredible pain in so many different setups its not even funny.

What are setups where it’s broken? Sincerely.

If you can’t accept inbound http traffic then you use DNS verification and if you never contact the internet then no public cert could work for you.

Devices with web based interface (KVM over IP, IPMI, etc).

iDRAC has a CLI tool that can be instrumented to install new certs regularly. I’m sure other vendors do as well.

That's me! I'm technical enough to self-sign for ssl for my sites (it and tor are what I do instead) but I run on lots of old hardware and old (>5 years) OSes. The tools for constantly re-updating letsencrypt simply don't work and all the containerizations didn't exist yet. I've tried nearly a dozen LetsEncrypt updates solutions, compiled from source, from debs, "standalone" only bash solutions, etc, there's always a catch that prevents it from working.

Are those >5 year OSes receiving security patches?

They probably receive more security patches than Centos 8 and by that I mean Centos 8 is lagging behind.

Shared hosting

Unless they set up LtE for their customers

(And as much as I like LtE I think it's complicate to depend in one issuer only)

Semaphor asks "can you describe the kind of person". Since when is "shared hosting" a person?

People who know how to set up a website on a shared hosting platform probably also know how to renew a LE certificate, I think.

Lots of people. Such arrogance from those who post on hackernews.

it takes absolutely no time at all to set up for an individual on their VPS, compared to the faff of going through the openssl csr process + buying from a CA

"On their VPS". What are you smoking?

It is not much harder to do this every year as opposed to doing this every few years. It’s just an incentive to streamline the process.

> It's possible and free for small players to use letsencrypt, that still takes some time to set up, manage and maintain over time.

If you want to run a webserver but are unable to set up a cronjob that does

  certbot renew

you don't deserve external users. Full stop.

If it's just you and you don't care about your own security, then do whatever you want in your own browser.

I have tried to look at the documentation for certbot and the amount effort they put into optimizing the fastpath makes it incredibly difficult to do things manually. The documentation is absolutely awful. Certbot uses .pem files which are practically useless to any JVM based application. So now you got to add your --deploy-hook and add a custom script to convert everything. Don't use any of the blessed DNS providers? Again write your own authentication and cleanup hooks. Suddenly your simple certbot setup involves 3 different scripts that have to be tailored to your specific situation. Sure there are nice blog posts that go through the entire thing but the official documentation basically pretends that your use case doesn't even exist because everyone is running Apache and Nginx, right guys?

> you don't deserve external users. Full stop.

It’s shit attitudes like this that killed the old internet we all loved

Don't feed the 5 hour old troll account.

It's not wrong to build whatever you want for yourself.

But if you have external users on your site sending data to your site, you have a responsibility to not treat your users' data as meaningless.