13 ms·
Safari will no longer trust certs valid for more than 13 months
- superkuh 7y agoThere are two mutually exclusive views of the web. As a set of protocols to allow individual humans to share information about things they love and the web as a set of protocols to make a living. There are real reasons for the for-profit web to want to limited cert lifetimes since revocation doesn't really work in practice. In terms of browser dev the two views are mutually exclusive and the one that funds the coders gets it's way. Especially with the W3C marginalized and a mix of corporations and corporate-centric standards groups running things now. Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future.
- derefr 7y agoCAs have always been third-party services, though. Their APIs just used to involve humans talking to humans, rather than machines talking to machines. But that's no less of an operational dependency. In a systems engineering plan (e.g. a NASA long-term project), both kinds of dependencies are considered liabilities that must be engineered for long-term reliability, fault-tolerance, etc.
- superkuh 7y agoIn the past browsers did not scaremonger so much about self-signed certs and search engines would index sites that were just http and this didn't effect their ranking.
- gruez 7y ago>In the past browsers did not scaremonger so much about self-signed certs That's necessary because people tend to be fixated on whatever task they're doing, and that causes them to click pass any warnings regardless of risk or comprehension.
- benibela 7y agoSearch engines have stopped listing http sites? Since when? I do not have https for my site (unclear if sourcefoge allows https for custom domains)
- threeseed 7y agoI can't tell if you are serious here. You want self signed certs to be trusted and the web to move back to the days of HTTP where anybody could just intercept your traffic ?
- gsich 7y agoThat's not what he said.
- luckylion 7y agoIt's different if you can "buy" a cert and be "safe" for a few years vs needing to renew it every 90 days. If they choose not to renew your cert, you're out after what ever time is left on your cert. Let's lower that to 60 ... 45 ... 15 .. ah, let's just renew all certs every day, that's the only way to keep control centralized.
- jhoechtl 7y agoI am telling you there is a conspiracy going on to end the open and free web. We should fiercefully start to fight back otherwise those who made the internet great (the open source hackers working on LAMP) will loose everything.
- diminish 7y agoDoes apple try to kill the web? Does Google try to take it over? Why doesn't Apple kill a million sh.tty apps just trying to grab attention doing nothing useful? It's time to get rid of Apple/Google browsers really
- Reelin 7y agoI'll agree that modern mainstream browsers (and devices!) have an increasingly centralized security model that isn't at all conducive to an open web. But given the current state of the FOSS ecosystem, I'm not terribly concerned in the long term so long as the network layer remains open to all. (Consider: QtWebEngine, PinePhone, SiFive, OpenTitan, IPFS, DAT, Solid, ...)
- Mirioron 7y agoI think the web is already a lost battle. It'll just take time (a lot of it) for the control to fully sink in. But I think that once this control becomes mainstream then there will be something else with more freedom. Some form of an alternate internet that will have barriers to entry. Something like tor. It'll probably be based on p2p.
- dublin 7y agoGab's rework of Mastodon is starting to look like this.
- cutler 7y agoHow is the network layer open when legit SMTP servers with proper SPF records are blacklisted by Google and Microsoft with no accountability. The internet is owned by these organisations. It's a fait accompli. It's only a matter of time before sites not hosted on cloud platforms become blacklisted due to the pitfalls of self-hosted certification. Jeeezus.
- bad_user 7y agoWith Let's Encrypt it's cheaper than ever to host a personal website over HTTPS with a certificate that updates itself. Due to Let's Encrypt, free hosting services like Netlify or GitHub Pages are now providing HTTPS certificates and installing it on your own server is pretty painless, if you're into managing your own server. And if your hosting provider doesn't support Let's Encrypt, you can always put Cloudflare in front of it. So I don't really understand what you're talking about, when the price and ongoing maintenance of HTTPS certificates has gone significantly down for hobbyists.
- superkuh 7y ago>So I don't really understand what you're talking about, That's because you didn't finish reading my post. >Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future.
- threeseed 7y agoYou mean like how it has been for decades ? You have always needed at minimum hosting, SSL and domain service providers.
- WillPostForFood 7y agoYou definitely didn’t need, and most sites didn’t use SSL a decade ago.
- snek 7y agoYou already have to rely on a third party to get a domain (and to get an IP address)
- TeMPOraL 7y agoEvery additional third party is an extra problem. It's an extra relationship to track.
- jchw 7y ago> Expect to eventually be unable to host a visitable or indexable website without relying on at least one third party service in the near future. I mean... How do you expect to have a valid, trusted TLS certificate without a third party? Nobody says it has to be Lets Encrypt or Cloudflare or Amazon load balancers or ... so forth. Some certificate authorities even already have APIs....
- mikedilger 7y agoNo third party is strictly necessary. You have to know what the servers public key is in a reliable way. That doesn't necessarily mean a third party has to be involved. Maybe you call them on the phone and check the fingerprint. Maybe it's your server and you sneakernet the key to your client. And to appease the dumb protocol you wrap it up as a certificate (self-signed) and accept yourself as trustworthy (what a concept!). Even if you use a third party, it doesn't have to be some big company that everybody is functionally obligated to trust. It could be a mutual friend making an introduction. And certificates are not the only or necessarily the right solution to this problem in all domains. For example, if you have to go and check OCSP every time to see if the certificate might have been revoked, then you are relying on an online trusted source; but if you have an online trusted source, why don't they just tell you the current key and dispense with the certificate mechanism altogether? X.509 was designed for X.500 and concepts that were relevant for X.500 continue to plague us all. I deployed corporate PKIs back in the 1990s for Sun and Pfizer and worked with other clients. What I remember best from those times was how ridiculous the whole thing is, over-engineered by parties who clearly didn't keep focus on the fundemental problem that public key cryptography is meant to solve.
- greglindahl 7y agoWhat about people who want to share information about things they love with privacy and security? This change seems likely to enhance my privacy and security.
- est31 7y agoYou can always run your own company-internal or limited-to-your-home CA and add it as custom root CA to every browser in that domain. These maximum certificate validity rules IIRC don't affect custom root CAs you added. I agree with you that the web is being commercialized, but limiting certificate lifetimes isn't the problem. It's rather stuff like the .org domain sale, google amp, Chrome killing the file:// protocol (after all, html files don't have ads inside them, can't be indexed and they don't make any money for Google), FLOSS projects adopting discord, etc.
- jsjddbbwj 7y agoSorry if this sounds dumb but this is a non sequitur for me. How does the for-profit web benefit from being able to revoke certificates? And why does revocation not work in practice? I thought all major browsers check their own lists to see if certs are revoked
- hoistbypetard 7y agoThis paper: https://cseweb.ucsd.edu/~schulman/docs/imc15-revocation.pdf https://cseweb.ucsd.edu/~schulman/docs/imc15-revocation.pdf is slightly dated but gives a very good rundown of how revocation checks fail in practice along with different attempts to improve them.
- cutler 7y agoFsck certificates, period. Make an exception for ecommerce and banking sites but leave the rest of us alone. Certificates have become the equivalent of the UK's national policy of building road humps 50 metres apart to thwart speeding drivers.
- Santosh83 7y agoNo joint announcement with other industry 'leaders' like Google and Microsoft? What is their stance on this? Will they be making similar changes to Chrome/Edge? And Mozilla? And maybe I am wrong but compromised certs are game over very soon aren't they? Reducing their lifetime to 'just' a year is still plenty of time to do enough damage seemingly, so what exactly does this high-handed change bring to the table? Another reason stated that it will keep the cert management folks busy and alert also sounds like grasping at straws to prop up the decision. I wonder what the entire reasons are...
- reaperhulk 7y agoThe goal is to promote automation and continue lowering certificate lifetimes as operations get better. This ultimately will allow for lifetimes short enough to be useful. As for the other browsers, Google originally proposed SC22 (https://cabforum.org/pipermail/servercert-wg/2019-August/000894.html https://cabforum.org/pipermail/servercert-wg/2019-August/000...) last year and all the browsers voted for it. CAs voted it down at the time but there were rumblings via various back channels that several major CAs actually wanted the ballot to pass but for political reasons could not publicly support it. So while Apple is acting “unilaterally” here, there is universal support among browser makers and tepid support from CAs. You should expect Google and Mozilla to follow suit in the next 6-12 months.
- mamon 7y agoHow will that automation verify that certificate is issued to the legal owner of the web site and not a hacker? Are the challenges used by Let's Encrypt secure? For me, automating certificate issuance will lead to less and less verification, to the point where having a valid certificate will become meaningless. EDIT: to clarify - there are two bad things about Let's Encrypt: 1. It's automated 2. It's free The fact that it's automated results in less human intervention along the way, which on one hand lowers costs, on the other hand makes it detecting scams harder (unless they deploy some really Machine Learning that detects frauds). The fact that it's free means that there's no credit card number or other info that would help identify actual person that requested certificate issuance. Together those things make things less secure, not more. EDIT 2: Both types of Let's Encrypt challenges look like pushing down the responsibility to either web server owner or DNS service. Maybe that's a good thing, since at least there's one fewer party that can screw things up.
- stygiansonic 7y agoI understand the reasons behind wanting to shorten certificate validity periods, but CA or root certificates often have expiration periods far into the future. What’s the argument for this? Ease of use? Historical reasons?
- jakub_g 7y agoIt's not easy to (at least this was the case until a few years ago) to ship updates to an old device (think Android 4.x or Windows XP; even worse for embedded systems). Hence to avoid the devices become useless bricks even if otherwise fully functional, root certs need to have more than a decade cert validity at minimum. (That's my personal theory, I'm not in the industry).
- userbinator 7y agoI think the industry is very much trying to push for the exact opposite of that, with things like planned obolescence to ensure you keep consuming their latest products.
- gruez 7y agoBecause those certificates are much well guarded (HSMs), rather than an unencrypted .pem file sitting on a server or someone's computer.
- dtech 7y agoRoot certificates are special. They are shipped to the device out-of-band, e.g. with OS updates. This makes them much more difficult to replace than other certificates, especially on devices that do not receive updates often like embedded devices and mobile phones. For this reason root certificates have a very long validity and very stringent requirements in their security parameters, e.g. large key sizes, and how they are used. Usually the certificate sits in a well secured off-network physical device and is only used a few times during its lifetime to sign sub-certificates.
- jcranmer 7y agoThe two big reasons for short certificate validity periods are to manage revocation issues (expiry is the one guaranteed way to revoke a certificate), and to reduce the risk of forgetting to renew certificates (by having to rotate them more frequently, your IT is more likely to have better processes in place). There's a secondary concern of reducing the ability of CAs to backdate certificates (which happened when SHA-1 was prohibited). Neither of those really apply to the root certificate store. Updating the root certificate (to add or remove CAs) requires an OS/browser update instead of relying on CRL or OCSP queries which are flakier--and browsers have a variety of mechanisms to punish misbehaving CAs that aren't "drop you from the root store effective immediately." Meanwhile, the process for updating root stores is entirely different than regular certificates, and it takes months to years to add a new root certificate--and I believe you don't get a pass to merely update your new root certificate for an existing CA. The other risks with overly long validity times are ameliorated in large degree by the fact that CAs are regularly audited and have much greater scrutiny placed on their issuance.
- nicolas_t 7y agoWhile I agree that it is better from a security perspective not to issue long lived certificate and that automation would be best, I dislike the fact that the subdomain of any certificate I issue becomes public due to Google's certificate transparency project. By making every subdomain public, it makes the job easier for any attacker wanting to try and find smaller servers to target. It's not that I believe in security through obscurity but besides making sure all servers are as secure as they can be, I do believe in not making the job easier for adversaries. So, instead I use wildcard certificates, and for this automation gets much more annoying, you need to use DNS to validate it (route 53 or similar does provide an api that can be used) and then I'm not sure if I'm confortable having each server generate their own wildcard certificate, leading to 100s of wildcard certificates... This is why I currently use old style 1 year wildcard certificate which gets updated through chef but I'm really not sure if this is the best solution or not.
- iso1210 7y agoWithout certificate transparency how do you know nobody has issued a certificate for your server? Surely that's a far higher risk than knowing a domain?
- nicolas_t 7y agooh, I completely agree that certificate transparency is beneficial for that and we have an alert setup. But, that still leaves me not wanting to leak every single subdomain we use internally. Hence using wildcard certificates.
- lisper 7y agoIMHO, expiration dates on certificates are and have always been the Wrong Thing. The Right Thing is to have the certificate contain a time stamp of when it was issued. The client should decide whether the certificate is still trustworthy. The cert can contain a recommended expiration date, but the dispositive information should be the issue date.
- thefounder 7y agoAnd how are the CAs supposed to squeeze you of money?
- gruez 7y ago> The client should decide whether the certificate is still trustworthy. Great, now you need to constantly go to some site like caniuse.com to see what % of browsers thinks your certificate is valid.
- derefr 7y agoI mean, in a world with more than an oligopoly of browser makers, that'd already be true given that browsers each ship with their own trusted CA store. In the original conception of X.509, it was supposed to be an enterprise's system administrator (e.g. a university's IT department) that would define the set of root CAs that the enterprise's computers would trust. So there'd be literally no way to know whether a given user device would trust your certificate. That was supposed to be a choice that is up to them, not something you can pre-guarantee by making deals with third parties.
- e12e 7y agoYou have to do that anyway to check if the certificate is revoked. Or, we'll, you should. I'm not sure sure if there are any production tls stacks that actually handle revocation well.
- abdullahkhalids 7y agoCan someone chime in with the original intended purpose of the expiration date? The one that I can imagine (without research) is that the issuer knows the quality of their own security practices, and if they says that a certificate will expire by X date, they are saying that they can't guarantee that they will still be the only person with the secret key after that point. Any other explanation?
- dboreham 7y agoIs this an early April fool article?
- deleted 7y ago[deleted]
- X-Istence 7y agoI posted about this a couple of days ago: https://news.ycombinator.com/item?id=22373673 https://news.ycombinator.com/item?id=22373673 didn't get much traction then :-(
- Mister_Snuggles 7y agoI have my own mini-CA for internal stuff, built using the xca[0] tool with certificates and private keys distributed manually. I usually make the keys valid for two years so that I don't have to renew and redistribute very often. Most of this started as a way to learn how this stuff works, but it's now turned into a "production" thing as I've started using this to issue user certificates for VPN authentication. Is there any tool that I can use to help automate this in a reasonable manner? Ideally, I'd love to see a web version of xca that supports ACME with some controls on how ACME certificates get issued. Bonus points for supporting OCSP as distribution of CRLs is another upcoming pain point. [0] https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/
- tialaramex 7y agoIf you're moving Private Keys you are Doing It Wrong. This is very common in VPN setups (and S/MIME) but still a terrible idea and worth taking the time to figure out how you'll make sure you don't do this.
- Mister_Snuggles 7y agoI'm definitely open to learning how to do things better, and I have no doubt that some of what I'm doing is wrong - after all, this whole thing started as a homelab-turned-homeprod learning experience. I think the proper way to do certs is to have the server (Web, VPN, whatever) create a certificate signing request and private key on the server, send the signing request to the CA to sign it, and then install the resulting signed cert on the server. Is this correct? What I'm finding in some cases is that there are cases where this just won't work. For example, my QNAP NAS allows me to either create a self-signed certificate (I don't want this, I want it signed by my CA), get one from Let's Encrypt (same issue), or upload certificate, private key, and optional intermediate CA certificate files (and we're back to moving private keys). This is a limitation of QNAP's GUI for sure, but it's not unique to QNAP. Similarly, I'm not sure how I'd generate the certificate plus private key on an iOS device and submit it for signing (the VPN scenario). This one particularly bothers me because the .mobileconfig file ends up being the key to the castle. Ideally I'd like the client to be authenticated with both a user-specific certificate and EAP, but I don't think iOS supports this. I haven't quite gone very far down this rabbit hole, so it's possible that I'm missing something. When I finally secure my internal web server (which acts as a reverse proxy for all of my internal services), I'll try the CSR approach for the learning experience. This approach should also work fine on my VPN server.
- z3t4 7y agoI don't think certificates are a good solution for most websites. Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH. Also browser should send their public key to the server! So that we don't have to come up with a new password for every damn site.
- jaywalk 7y ago>Instead have the browser store the public key first time you visit the site. Then ask the user every time it changes, like with SSH. The vast majority of users will not understand this. Also let's say you go to a site one day, and you get a prompt that their certificate has changed. Is this legit? How can you know? >browser should send their public key to the server! This already exists (HTTPS Client Certificates) but it's a huge pain in the ass so it's barely ever used. When it is used, it's generally within a controlled corporate environment.
- z3t4 7y agoThere could still be a trust chain. But most websites don't need it, just like most websites only use the basic level of certification today, all they really want is encryption. (or the green padlock :P) Client certificates has kinda been deprecated by browsers. Which is why it's such a PITA. Also handling signing certificates by itself is a PITA. But most website's wouldn't need signing, just encryption. Automatic SSL certificate signing is not that secure, if an attacker would be able to mess with DNS, or access the HTTP server, they could also create a fake certificate via Letsencrypt. Or if the attacker has access to the client, they could sneak in a root certificate. Most nation states and ISP (those who would like to spy on it's citizen) already have root certificates. All that SSL certificates do is to create extra work for site maintainers. We can have encryption without certificates. If you would for example side-load a list of public keys for the main sites you visit, that would be much more secure then SSL certificates are today.
- tingletech 7y ago> Also browser should send their public key to the server! That would make fingerprinting even easier?
- j1elo 7y agoAnybody knows why Safari on iOS will reject using self-signed certificates for WebSocket connections? (doesn't happen on desktop) This is a major annoyance since it is the only browser that does this and won't work with "wss://" URIs even after accepting the mandatory certificate exception. Accessing the page rightfully shows a warning on all browsers, to which the user can click on "Continue" or similar, to ignore this and start the demo, except if they try with iOS (this is for simple one-off tutorials or demos [1], so maintaining good certs or requesting users to install a custom root CA in their devices is out of the question). I know, this seems like a StackOverflow question... but the only 100% relevant one I found [2] didn't get much love, so I thought maybe someone at HN knows more about this [1]: https://github.com/Kurento/kurento-demos-js/tree/master/player2many https://github.com/Kurento/kurento-demos-js/tree/master/play... [2]: https://stackoverflow.com/questions/36741972/using-a-self-signed-certificate-with-safari-and-websockets-osx-ios https://stackoverflow.com/questions/36741972/using-a-self-si...
- castillar76 7y agoApple recently (last fall) introduced a change that rejects all certificates that are valid for more than two years, whether they're public or private. I would double-check whether the self-signed certificates are valid for longer (many default self-sign processes make ten-year certs, for instance). Failing that, you may have to create a proper private PKI and get users to install the CA, or else use something like Let's Encrypt for certs.
- j1elo 7y agoThanks! you gave me one thing to check. The certs are indeed made for 10 years validity, the idea being that they should just make the demo work for a long time, even if it is with a certificate warning. I don't think it's worth the effort of setting up all the automatic renewal process with Let's Encrypt for what amounts to a quick static code example... so in principle I wanted to avoid having to set that up. The contents of this article means that soon this 2-year maximum will become a 13-month maximum, right? Is there any way to create these specific-purpose certs with some kind of "private use" or "development use" flag that allows not having to re-create them so soon? 13 months looks too short of a time period, I'm afraid nobody will remember to refresh the fake certs and the demos will break... for really no good reason (related to the code itself)
- enigmabridge 7y agoApple Drops SSL/HTTPS Bomb - Forget Long Certificates https://keychest.net/stories/apple-drops-sslhttps-bomb-forget-long-certificates https://keychest.net/stories/apple-drops-sslhttps-bomb-forge...
- mooibos 7y agoI develop for Apple platforms, and it's absolutely mind-boggling how frequently and regularly they break your code for no tangible benefit. Hopefully their influence doesn't spread to the web too.
- threeseed 7y agoThere is a tangible benefit. For users. 64-bit only, Project Catalyst, BitCode, HTTPS only connections etc are examples of initiatives which definitely has caused pain to developers but has immensely benefited users as a whole. And if you don't passionately care about users then frankly find another platform to develop on.
- gsich 7y ago>64-bit only how has that benefitted the user? Directly and measureably, no "it's 0.3% faster now" excuses.
- diebeforei485 7y agoNot having to load both 32-bit and 64-bit libraries into memory is an efficiency (and battery life) improvement on the system as a whole.
- gsich 7y agoThat would fall into the "it's 0.3% faster now" category.
- kevingadd 7y agoHow does it benefit the user for half their software to break, or for them to have to pay a vendor (rightfully) for a massive update/overhaul just so the software keeps working? 64-bit Only benefits Apple because they don't have to maintain the 32-bit stack anymore. Any perf-sensitive software that needed to be 64-bit transitioned a long time ago.
- ericd 7y ago
- OrgNet 7y agoGoogle doesnt trust my password for a gmail account that I last used 6 months ago (I had to also provide one my previous password to be able to login). It is getting ridiculous... Now I gotta keep an history of passwords, just for Google...
- gsich 7y agoSafari market share ... so who cares. I am not talking about mobile usage.
- moneromoney 7y agoApple's browser is already called "the New Internet Explorer": https://fabiofranchino.com/blog/css-height-parent-flex-safari-issue/ https://fabiofranchino.com/blog/css-height-parent-flex-safar... https://dev.to/nektro/safari-is-the-new-internet-explorer-1df0 https://dev.to/nektro/safari-is-the-new-internet-explorer-1d... https://arstechnica.com/information-technology/2015/06/op-ed-safari-is-the-new-internet-explorer/ https://arstechnica.com/information-technology/2015/06/op-ed... ... and millions similar articles I developed widgets for web developers and I had to change it to stop using the 'fixed' positioning anywhere, because iOS is the only browser that interpret it differently on all touch enabled devices. They have many other issues as well. I have to spend half of my time to fix their buggy browser!!!!!!!!! Not even the old internet explorer causes that many issues as safari. They torpedoed progressive web apps and many important web standards. Why? Just because they want you to use their apple store, where they can take 30% from every transaction without doing anything. I hope Apple will go bankrupt and stop hurting the web community as they successfully did in the past years.
- Christain855 7y agoGreetings everyone Christian Thornton, Last Year I applied for a loan but proved negative. My goal was to start up a business but due to my bad credit history I was unable get a loan. My credit score was 458 I had lapse in payments from states, so some stuffs went to collections some got charged off some 30/60 day late all credit card got maxed. While I was digging online for possible ways to get my credit fixed, I came across some article talking about this great credit specialist Ghost virus I was impressed. I quickly contacted him to get more understanding how it works we had a chat I was impressed from the details and he gave me. He requested some info from me which I provide, the process lasted for 2weeks they got my credit fixed with an excellent credit score I really appreciate you thanks. If you’re seeing this and you need a credit repair specialist then here’s the man to contact (GHOSTVIRUS7890@ GMAIL.COM +1 205 418 0498)
- wbond 7y agoApple is the reason I just switched a handful of certificates from Let’s Encrypt to basic 2 year DV. To support Apple Pay on the web, you have to go to your developer account on the Apple website, and under certificates generate a custom ASN.1 authentication file and upload it to the `/.well-known/` folder on your domain. Once uploaded, you have to click a “Verify” link, to check the file and mark the domain as Apple Pay approved. The issue is the verification only lasts as long as the certificate expiration, and if a new certificate is installed, you have to re-verify the domain with a newly generated authentication file, for each domain. A fresh certificate with an old authentication file does not work. This means if using Let’s Encrypt, you have to manually step through the verification process for each of your production, staging and development environments every three months. There doesn’t appear to be any automated way to handle this. After two cycles of this I opted to purchase 2-year certificates just to save the hassle of re-authenticating my web environments on a rolling basis by hand. This announcement just means more frequent manual processes once again. What a pain.
- cyphar 7y agoThere is some argument for this kind of certificate pinning (though I'm honestly not sold on the idea), but I think that this example is a further argument for scriptable certificate renewal. Most ACME clients allow you to run scripts after the certificate is renewed, so you could (in principle) trigger a script that does this Apple-specific verification process for you (maybe you could even trigger the "verify" button click by messing around with cURL -- though it'd be pretty annoying for there to be no API for this process). By manually getting 2-year certificates you're setting yourself up to forget part of the renewal process. This was the main argument behind Let's Encrypt having such short expiration windows -- it encourages people to script their entire deployments.
- maxgashkov 7y ago> maybe you could even trigger the "verify" button click by messing around with cURL Good luck with that—some time ago Apple locked down pretty much everything related to developer accounts with 2FA requirement that, of course, works on their proprietary platform via sending codes to logged in Apple devices. Maybe you can snatch it via some Automator kung-fu but I seriously doubt that.
- cutler 7y agoJust look at the state of the "modern" internet with it's certification wars, 2-level auth, Google SMTP gatekeeping, mandatory HTTPS, Letsencrypt v2 & certbot renewal fsck-ups. What hope in hell does the ordinary user have of navigating all this? Do we all now need to be experienced sysadmins just to use the internet?