A few of these things, while not necessarily wrong, should be put into context.
E.g. "Hundreds of thousands of domains' certs expire after 2099". Yeah, but no publicly trusted certs. They're capped at a bit more than 2 years and there's a discussion to cap them even more.
The certs they're seeing are almost certainly mostly: "let's create a test selfsigned cert for this host. how long should it last? let's type in a large number so we aren't bothered by it any time soon."
Historically there were some certs that kept getting grandfathered in after lifetimes were restricted because they'd been issued before there were any rules - maybe ten years to expire or even more? I think the last of those probably went away because of the Symantec distrust (not that they were issued by Symantec, but they were issued by a CA which was bought by a CA which in turn was bought by Symantec before it was distrusted) and also of course they'd have either MD5 or SHA-1 signatures, which are not accepted today anyway.
There were still certs issued right up until the end of March 2018 with the old 39 month lifetime maximum. You can see them most easily in the annualised CT logs for 2021. A while back CT log operators realised that logs just get longer (of course) and so they would need to periodically make new ones and archive the old ones. Very quickly they struck upon the idea of annualising them, instead of running FooBar Log, run FooBar Log 2019, FooBar Log 2020 and FooBar Log 2021, and then require any submissions to use the log matching the year of expiry of the certificate they were logging. This way you can archive FooBar Log 2019 when people get back from holidays after celebrating New Year 2020, all the certs in that log are expired anyway now.
I guess that today the last of those 39 month certs will actually expire before a brand new 825 day cert, but they are still out there, so don't write software that assumes leaf certs can't last more than 825 days just yet.
The old certificates aren't a huge concern moving forward because the new standards for trust libraries is requiring that all certificates not be trusted if the expiration is too far out. Chrome and most other browsers have already implemented these standards.
The real concern is the percentage of people using browsers that are no longer supported and therefore do not implement on the new standards like Internet Explorer. Microst really needs to stop caving to pressure and get rid of these ancient applications like paint.exe and internet explorer. That or just make new applications and give them the same names.
I doubt ~75% of the self signed certs expire in this dataset expire 21-30 years from now. Surely the author is correct that there are a good number of public certs with a very long expiration. Would need to download and filter the dataset to know for sure though.
I doubt anybody has ever issued a "real" (Web PKI) leaf certificate (leaves are the edge of the tree, the certificates presented by TLS servers this work connected to) for 21 years let alone 30.
Back in 2011 when the Baseline Requirements were first written, they set 60 months (5 years) as the upper limit, with the intent to further restrict to 39 months in a few years and that eventually happened in 2015 or so.
Last year 39 months went down to 825 days and there's currently pressure to reduce it further in 2020.
Note that it's not just self-signed certs you'd be considering, many of the certs in this dataset will be issued by a CA but not a public CA. Could be an internal CA (e.g. Windows Server provides software to run one, so does RHEL) or could even be one of the private-use-only CAs run by the same companies that operate public CAs.
There were about half a million certs in that dataset issued by SomeOrganization with email address root@localhost.localdomain. Not technically self-signed, but obviously that's not a public CA.
With raising automation of issuance for certificates (I might work soon on a project to add an api to issue certificatates) I don't see any reason to not go any lower. Like just a few days or weeks.
That doesn't work if your running software supplied by a vendor that needs an SSL certificate. Often they have manual processes, that require shutting down the application and restarting, taking the service offline through the process.
These applications are also frequently heavily firewalled to the internet so security risks are limited, but not with smaller operations, you might not have PKI infrastructure in place to manage your own root certs (especially in BYOD orgs).
If a certificate rollover takes your application offline for an hour, your not going to want to do it every week.
This kind of centralization is not good. Even thought let's encrypt is non profit and has a very good service record. We desperately need more like it spread around the globe.
Even if this is true, nothing prevents another provider from rolling out a similar or better offer. Existing providers could do it today, but they are too busy spreading FUD to rake in profit.
Just so people don't get an oversimplified view of what it takes to start a CA from this comment, you will have much bigger challenges than access to application software. Your first issue will be securing millions of dollars per year for the staff that it takes to run the CA responsibly. Your next issue will be getting trusted by browsers.
Also, the open source Let's Encrypt CA software is tailored for how we do things. It's not an "off the shelf" component that you can easily run in another context and end up with a proper compliant CA.
What do you think is a realistic estimate to get a new CA off the ground? Just the minimal cost for hardware and audits and whatnot to create the required artifacts and get them into the three major root programs. Not including staff and ongoing operational expenses (I can estimate that myself). I’ve heard it can be done for as little as $250,000.
Also, timeline. It took Let’s Encrypt a couple years to get in root programs and have good penetration, right? Would it be faster or slower now?
If someone was willing to undergo this ordeal and could secure funding so it wouldn’t split the philanthropic community and affect LE, would LE be willing to cross-sign (once they’re in good standing) to get them off the ground, the way IdenTrust did for the ISRG roots?
It's not about the money, either. LetsEncrypt had their intermediate certificates cross-signed by IdenTrust, otherwise they wouldn't have the 30% market share.
It takes a lot of time with the CA application process. You will need to convince Microsoft, Apple, Mozilla, Java, etc that you will be a good CA with good practices. Multiple security audits (starting at about $40K... KPMG don't come cheap), hardware (HSM, servers for validation, OCSP, CT, etc) and people (needs to be trusted people, and often are paid top dollars).
It's easy to _buy_ a CA than creating one. You can get your new root certificates included later easily now that you have a root already, from which you can cross-sign until they are included. CAs are sold out more often than many of us think.
Yea I have a pretty good idea of what’s involved. None of that is impossible to do. Time consuming? Sure. Impossible? Far from it. The root programs have documented processes to get included and will (eventually) accept a legit new CA that’s passed WebTrust audit and has good practices (afaik). Hardest thing is finding someone to cross-sign to accelerate the process. That’s why I asked jaas if he would do so :P.
I run a company that does public key infrastructure stuff (smallstep.com) so I have the software and some of the people. I think I could track down some hosting and a couple operators from a partner or two. What’s left seems like maybe a few hundred thousand a year for audits and HSMs, mostly. Pretty sure I could scrape that together too.
Idunno though. Mostly it’s Friday night and this is a fun thought experiment.
Good thought on buying an existing CA. Are any currently up for sale, I wonder? If anyone who reads this knows, plz email me (mike at smallstep).
LE are pretty open about their expenses, ~$3.6m a year currently, if I remember correctly.
They got bootstrapped with a cross-signing from IdenTrust and so were able to get off the ground fairly quickly. That won't have been cheap, and I'd be very surprised if anyone would offer the same service now - there's some pretty big risks associated with it.
Getting a new trusted CA off the ground is slow and expensive, sadly, and of course you can't really issue anything 'trusted' until you get a critical mass of browsers and OSs to include and distribute the root.
Of course it's quicker now than it used to be, with automated updates and better update cadence. You'll still have problems in some areas (embedded devices, older Android devices).
Funny how a project can have problems because there's a ton of customers with 'smart' TVs that only support old roots and have no update mechanism...
Buying a CA or an existing root is the best way for now, probably. Not cheap. Amazon and Google both did this (roots from GoDaddy and Globalsign respectively).
Not sure if any are for sale at the moment, but it would never hurt to ask - although the pricetag might be scary!
(Disclosure: I've been doing this over 16 years, at one of the larger CAs. nick -at- sectigo -dot- com)
I would try contacting some of the lesser known CAs. Those who voted "No" on recent CA/B forum ballot to reduce certificate lifetime are probably having some hard time keeping up with ACME, and might as well sell the business. A root valid for next 3-4 years gotta do because Android updates are faster now and current shitty IOT devices and "smart" devices would be dead by then. In recent Symantec sellout to Digicert, it looks like the more pressure a CA has, more likely it would be to buy them out. It's gotta cost in millions though I suppose.
Yup, but no incentive. They are literally making millions of dollars for a fraction of a penny in CPU time to sign a cert. Why offer the same thing for free? Try to sell it as more secure and trick lots of people...
who ever said free? they could make a paid service like LE with automated renewals etc that integrates better with enterprise software, or that does better audit logging, or any number of things. let’s encrypt is a great service, but there’s still plenty of money to be made off overzealous corporate security policies
Right. What happens when Let's Encrypt is the only CA and they decide that they don't like you for some reason? All tech companies are under tremendous Twitter pressure not to serve the wrong kinds of people, and this pressure will only intensify. The window of acceptability narrow. Infrastructure diversity is an important check against the ability of vocal but small groups of activists to effectively censor the internet.
Getting caught up in what kind of censorship is most vexing is missing the point if we can agree that nobody should be able to silence people on the internet.
Competition is always good. For one, a completely decoupled and separately managed system on a different stack would improve availability of ACME-based certificates. It would also reduce the concentration of trust in one entity. While LE is awesome, the target on their back is only getting bigger.
For what it's worth, I'm pretty sure even Let's Encrypt wants to see competitors to Let's Encrypt.
I think you’re interpreting my comment about trust too literally. If you’re talking about “Web PKI root of trust” trust then yes, having two CAs just means you’re trusting two third parties without reducing trust in either. I was using the term more broadly and more narrowly... like, trusting them to be good stewards, trusting them with PII, and trusting them to not configure their DNS resolvers to use NSA-controlled DNS. They have more power and more control and become a more attractive target and more susceptible to corruption because the stakes are higher. Maybe I should have said “concentration of control”. If one CA owns 90% of issuances they’ll be able to push their agenda, for sure.
To be clear, all of the evidence shows that LE uses this power only for good. But that’s the threat. 30% market share is probably fine. 90% or 100% would be scary.
If you're working for profit, competition is awful. If you're not working for profit competition may or may not be good. Regardless, how you personally feel about competition isn't relevant here.
Limiting a bit the impacts if Let's Encrypt is compromised in any way.
If Let's encrypt is compromised, either by being able to issue certificate for arbitrary domains or if the CA itself is compromised, the impact would be huge given the current number of certificates signed by it and this number is likely to grow in the futur.
With several CAs in different organizations, you have a far lower risk of seeing all the CAs being compromised at the same time, thus limiting the impact of a CA being compromised.
Note that it doesn't mean a full decentralization, but rather a set of CAs (5 or 10) independent of each other and providing a service as conviniant as Let's Encrypt.
As a side note, an idea a colleague of mine suggested to extend and better the security model of CAs/certificate would be the ability to have a certificate signed by several CAs.
Let's say you are a bank or a security sensitive website, you could have your certificate signed by 4 or 5 CAs, and then, you could publish a policy, for example in a TXT DNS record, stating that you need at least 2 or 3 valid CA signatures. This way 1) your certificate doesn't need to be renewed in emergency if its CA is compromised, 2) if a CA is compromised (without people noticing), it reduces the overall impact as an attacker would have to in fact compromised several CAs to actually exploit this (MiM or impersonating websites).
If a CA is compromised critically (private key stolen), then it's removed from the set of trusted CAs you can find in browsers or at OS level (ex: ca-certificates package on Ubuntu/Debian), which in turn makes all the certificates the CA has signed invalid.
With multiple signatures, at least, your certificate is still valid as it has at least another valid CA signature.
Also, right now, if one CA is compromised and if this goes unnoticed, the effect is a bit catastrophic as it's possible to create valid certificates for any domain. With multiple CA signatures in conjunction with a security policy mechanism stating how many of these signatures must be valid, you mitigate this issue as it would require several CAs to be compromised and controlled by the same actor to issue valid certificates.
Good practice says that you should be renewing your certs when they have about 10% of their lifetime left, just in case this exact thing happens with whoever your provider might be.
It's unlikely they would be down for so long that certs would actually expire.
I don't think a percentage is the best way to think about it. There is a lot of variability in lifetimes and the time it takes to resolve issues is not related to the lifetime of the cert.
Just pick a discrete number of days before expiration such that you have a comfortable amount of time to deal with issues.
We (Let's Encrypt) recommend renewing with 30 days left, so every 60 days. If your system is automated like we recommend that shouldn't be burdensome, no reason to do it less often than that.
For what it’s worth, I’ve run into some issues with this guidance from you guys as I’ve been building out a private CA with ACME support. A lot of ACME clients have hard coded renewal at 30 days prior to expiration, which makes them pretty worthless for managing short-lived private certificates. Using a percentage might not encode a fixed SLA very well, but as a default it does accommodate various lifetimes well.
I can see pros/cons either way, just thought you might be interested in this feedback.
The recommended way to use LE is to run the renew command daily and it will do nothing until it finds a cert 1 month or more old. That way you have 2 months to solve an issue.
What happens if their private key gets exposed? A third of the internet being suddenly insecure is a really scary prospect. If everything is automated, a lot of smaller sites may not notice until the certificate expires, or even for some time after that.
Having more options means less fallout if a CA gets compromised.
You may be conflating HSTS with public key pinning. HSTS doesn't care which cert provider you use. CAA and HPKP do. If LE go away or get untrusted, you can get certs from another CA, albeit not free in most cases.
Improved security. So many sites are trusting Let's Encrypt and have cron jobs set to refresh data from them. If Let's encrypt were comprised or went offline, they are now a huge single-point-of-failure (or worse, single-point-of-exploit?) for all these domains. It's become a kind of monoculture. A more diverse ecosystem of offerings would be resilient to any single attack or failure.
On the flip side, more certificate authorities (who, remember, also have the ability to delegate intermediate authorities) also means more attack surface, because except in the case of key pinning (which is rare to my knowledge) any malicious authority or compromised authority's certs could be used to effectively intercept web TLS traffic. If let's encrypt was the only authority, yes that would be bad in many ways (and i'm not arguing for that) but it would mean less authorities to worry about. Anyone remember the bluecoat scandal? https://www.vice.com/en_us/article/78kkwd/a-controversial-su...
How would adding additional CAs improve security? By the very nature of the CA trust system, each CA is itself a single-point-of-failure/exploit (though certificate pinning and other measures improve this somewhat).
Yes we do. On what basis did you make that statement?
We comply with U.S. sanctions by not issuing to entities on the SDN list, but that doesn't prevent us from serving the vast majority of people in those countries.
indeed I misread it. you don't provide certs for the governments of those countries (still a limitation tbh). I got that from this post of one of your employees
When I registered my domain I got WHOIS protection and then LE just made sure I owned the domain. There was no asking about who I am or where I reside or what lists I might be on.
Some entries have specific domains associated with them, but we are obligated to not serve any domain directly associated with (i.e. controlled by) an SDN entity, not just those listed.
If we become aware that we may be serving an entity on the SDN list (often via someone emailing us) we have to conduct an investigation which may result in termination of service.
I haven't checked their TOS, but practically there isn't any limitations in getting certificates from Iranian IPs or for ir domains. If there is any problem, it is that browser vendors/root CAs/etc are not willing to trust CAs in those countries.
How are you going to trust that decentralized org? Is it just voting? Can we all vote to revoke anyone's cert at any time for no reason? What happens when someone performs a 51% attack and takes over google.com's cert?
CAs exist solely because you CAN trust them, otherwise what's the point? We'd just have every site self-sign and let the users choose who to trust.
As far as I am aware, the only organizations that aren't under the jurisdiction of any nation state or authority are those sponsored by/derived from the United Nations.
Sure, but it would be reasonable for an outfit to (seek funding for) a CA that isn't subject to US sanction rules.
Of course there's a question of where you should put such a thing. Even Russians apparently don't find the idea of a Russian CA trustworthy (they expect that Putin would have his thumb on it, and who am I to argue?), a European CA is certainly not free of American influence, so where would this alternative be based? I don't have a good answer.
They could pull a cloudflare and stop granting certificates to people that are out of moral alignment with them.
Or the government could lean in on them require them to not grant certificates to some foreign institutions. Even worse, they could be forced by NSLs to issue fraudulent certs (CT log verification isn't mandatory yet, is it?)
The GCP self-serving platform for certs is very welcome, but still kinda janky. You end up waiting hours for their batch jobs to run at unknown cycles.
Let's encrypt is awesome because it's instantaneous! You'd think Google would understand that aspect.
Edit: GCP people: Please give us a an explicit "retry" button to press when we've set up the DNS records. (I'm talking about the Google Cloud Balancing Service here. The UI was awesome up until the point it wasn't. The one thing lacking was a "retry" button.)
For GKE, in beta, you can tell the ingress to get a TLS certificate automatically. Google will manage the whole process. The weird thing is, it uses letsencrypt. Since Google has their own Root CA, that seemed like an interesting choice.
> The GCP self-serving platform for certs is very welcome, but still kinda janky. You end up waiting hours for their batch jobs to run at unknown cycles.
Have you noticed where they get the certs from? Let's Encrypt! So there's really no reason for that.
The stars were probably aligned for you. Given DNS TTL there's a bunch of uncertainty here. My main feedback to
Google is that having them periodically check back at an unanounced schedule, with no abilitity to force an an immediate check.. shows a total lack of understanding of customer needs.
I mean, like... Yes, I understand that by default Google does things at scale, but sometimes you need to do things by precision/on demand, too.
You list the ciphersuite that got chosen for each connection, but I think this could use at least a caveat explaining that the way this works means you'd need to do a LOT more work to figure out what the servers might have agreed to do for some other client.
What I mean here is that TLS up until TLS 1.2 goes like this:
Client: "Hi, I know ciphersuites A, B, C, D, E, F and G"
Server: "OK, let's do C"
And so you can't tell whether the server actually knows A, B, D, E, F, G or even I through Z. They just decided to pick C this time for some reason.
In TLS 1.3 it's sort of better (all of the ciphersuites you shouldn't use don't exist any more) and sort of worse because now it goes:
Client: "Hi, let's do method B, I'll go first, 123456 and a goldfish and the colour yellow"
Server: "Cool, method B works for me, I pick 567890, a swan and mauve"
Probably all TLS 1.3 servers today are willing to do anything method not just method B, since all the methods are shiny and new. But perhaps not, and you can't tell except by failing the connection which takes more round trips.
With regards to the supported SSL/ TLS versions you can get that information from Shodan. We do explicit handshakes using each version. For example, here is an overview of servers supporting TLS 1.3:
> Probably all TLS 1.3 servers today are willing to do anything method not just method B, since all the methods are shiny and new. But perhaps not, and you can't tell except by failing the connection which takes more round trips.
You can have a round trip all the time, or just in the case where the client chooses an ciphersuite the server doesn't support. TLS 1.3 makes the typical cases much better without hurting the worst case much.
Given that the population of browser useragents that only understand TLS1.0 and TLS1.1 is under 1% now, I've set all of my public facing apache2 httpd to only speak TLS1.2 and better. Have had things that way for about two years now and with zero reported usability issues.
When LetsEncrypt came out, I wrote a service (free) that monitors LetsEncrypt certs externally and sends alerts when they are close to expiring. It can be used as a backup to the automatic emails that are sent:
1. Why not integrate and let user monitor all their SSL certs for a domain in a single shot? Like retrieve all certs for a domain (similar to https://crt.sh identity like search result)
2. When registered, I did not receive an email confirmation/validation. So I am not sure if I will get an email before my certs are up for renewal.
They give away paid products for free. Products that Google penalizes you for not having. Then, many people needing or wanting that product used their free alternative.
I still don’t know if that vs version with more paying customers is a good thing in long run. Good for now, though.
In practice, most CAs are over-charging for what should be highly automated (like LE). Other CAs also push EV and other certs that cost more, but don't really add much value in practice.
In the end, the "free" version is good enough for most people. I would suggest if you're using it in a commercial environment that you consider setting up a scheduled donation. Which likely does help a lot for what they are doing.
The security aspects have been covered but there is another advantage. When people get a 2 year certificate they very often forget to renew it until their website becomes broken. With a 90 day expiry you are pretty much forced to add a task to crontab that renews automatically.
> They limit damage from key compromise and mis-issuance. Stolen keys and mis-issued certificates are valid for a shorter period of time.
> They encourage automation, which is absolutely essential for ease-of-use. If we’re going to move the entire Web to HTTPS, we can’t continue to expect system administrators to manually handle renewals. Once issuance and renewal are automated, shorter lifetimes won’t be any less convenient than longer ones.
>Almost 1.6M domains had a cert that had recently expired (in July, the month of the scan). Almost 3.7M domains had a cert that expired in 2019 (the year of the scan). Over 9.6M domains had a cert that expired in the 2010s!
This doesn't make sense. Even assuming you included the ones that had expired certs in "had a cert that expired in the 2010s", it would only be 1.6+3.7~=5.3M.
The thing that irks me about domain names is that registrars hold onto expired domain names and put them in their domain auctions. ICANN needs a new rule that registrars can't hang onto expired domain names for more than 30-90 days.
"If the domain name is not renewed, redeemed, or purchased through an auction, it is returned to its registry. The registry determines when the domain name is released again for registration."
can someone please share how they deploy/distribute Let's encrypt certificates with auto renewal on load balanced multiple EC2 servers for the same dns name. I had tried this a while but had to give up and just bought SSL certs which I then include in my EC2 image.
If your load balancers are AWS load balancers, you are doing it wrong. AWS provides their own free certificates that work the load balancer and they handle renewal as well. Let's Encrypt would be an unnecessary additional dependency and complexity.
(At least if you are comfortable terminating your SSL at the load balancer. If you plan to use SSL between the AWS LBs and your EC2 instances, then AWS certs don't work there and you'll need to provision them yourself using something like LE).
> (At least if you are comfortable terminating your SSL at the load balancer. If you plan to use SSL between the AWS LBs and your EC2 instances, then AWS certs don't work there and you'll need to provision them yourself using something like LE).
Interesting note - ALBs/ELBs (NLBs with SSL termination as well, I would assume, but I am not sure) do not perform validation of your backend certificate. You can terminate at the load balancer and use an expired self signed SHA1 cert for all AWS cares.
Elbs do support public key verification of the backends (search for Enable backend authentication). I believe you are correct wrt Albs and nlbs, and in neither case does it check the cert ttbomlk, just the public key.
I stopped using AWS load balancer as I found that it was costing me more than my server, which are cheap as I normally use a fleet of spot instances . Also this is not corporate funded but my own money -- so I am very cost sensitive
I have, I set it up around 6 months ago on a couple of my own personal sites, and it seems to work pretty well. It took a while to figure out the right way to configure it for multiple site hosting, but it has been pretty trouble-free. The cert registration and renewal was really slick. If you want to see it "in action" on a single EC2 instance: https://pythoneers.org/
I used an Ansible role to provision it, antonier77/caddy-ansible and it has worked nicely.
But, as another comment mentioned: If you are in an AWS load balancer, you probably want to use the AWS certificates.
This reminds me... we have an nginx config adapter started. Would you be willing to help try it when we get it closer to being done? It will let you bring your nginx config and converts it to a Caddy config.
I pick up the URL for validation request at the edges and pass it to a specialized backend that handles validation.
Certs/keys get added to a key:value store that is monitored by the edges.
Each edge know the timestamp of the current key:cert pair that the edge successfully wrote (if there was an update) or the timestamp of the current key:cert pair that the config-baker wrote during the edge built process if edge has never wrote a key key:cert pair. If the timestamp is newer, then the edge updates the key/cert and restarts itself with a new cert.
The key:value store for keys is also monitored by a config-baker. When a config-baker detects a change in key pairs, it writes a new initial configuration JSON with new keys/certs which is stored in the infrastructure management git. So when a new edge is built and launched by the infrastructure policy enforcer, it would immediately have the keys on it as soon as it comes into service at which point it will become just another edge following the same "protocol"
Edit:
Currently it manages 671 certificates on 16 different edges. After a new key:cert is published in a "go" mode it rolls out in ~1 minute to all the edges.
For our dev/stg environment we use certbot, and haproxy has a backend configured to pass the validation requests back to certbot based on "/.well-known/acme-challenge" in the path.
For production we are only using it, currently, for the cert at the backup location, and we couldn't use certbot because of the way it is packaged for Ubuntu, it wouldn't work with Route53 DNS validation. Because it's the backup site, HTTP requests aren't normally directed at the server doing the requests. So I switched to "acme.sh" and that's been really reliable.
We use Terraform to automate the actual generation of the certificates (it checks the expiration date and does a renewal request when you're 30 days away), but the basic approach we use is to generate the certificate with DNS validation, store it in a known location in S3, and then have the machines download the certificate on startup and refresh as a cronjob.
I don't know if that is a good practice or whatnot, but I just set up .well-known in my nginx config to redirect to an S3 bucket where I write the ACME challenge to.
If you just want to post a link, I'd rather you submit a story with a title than put a "see, this is concerning:" in the comments.
Moreover, I don't see how this article is relevant to Let's Encrypt's popularity. There are only two mentions in the article about LE, this is one: "These actors use Let's Encrypts, Comodo, Sectigo, and self-signed certificates in their MitM servers to gain the initial round of credentials." So they use normal public infrastructure to get certificates? That is concerning, how?
I have some tremendously bad news if you thought that publicly accessible services on the Internet are secret.
Several distinct outfits sell what they call "passive DNS" which is a feed of snooped DNS queries and their answers, minus any identifying information. So you don't need a certificate, if anybody, anywhere, looks up the name and it has an answer then these systems will tell you what it is.
Yes I do care, and I agree that they should be doing so: I expect that CAs share these to Certificate Transparency logs, it’s a requirement to so that we can accurately find misissued certificates.
That's not the point. In a decentralized system, every actor needs an incentive to mine new blocks in the chain. In cryptocurrencies, the incentive is the creation of new money attached to your name. But what if we're not dealing with a currency, but something else?
The whole point of providing an incentive is to give a bunch of decentralized miners a reason to devote a reasonable amount of processing power to securing the blockchain. If there's only a single non-profit mining the chain, because why on earth would a bunch of other people throw money away for no reward, then for an attacker it's substantially more feasible to perform a 51% attack.
For Bitcoin there's currently around $132,000 of incentive for mining given out every 10 minutes. In a race to the bottom that basically equates to a bit under $132,000 worth of compute resources expended for mining every 10 minutes. An attacker with enough resources to perform an attack on Bitcoin would have to spend more than that $132,000 every 10 minutes and keep it up for the duration of their attack.
"Blockchain" for random hip projects more often than not is just buzzword nonsense that does nothing to improve security. A blockchain without mining is just silly, mining only works when it provides sufficient incentive such that attacking that blockchain is much more expensive than any payoff of attacking it is worth.
that's the hardest part, but how is it proved now? by providing evidence. A nonprofit like letsencrypt could be the custodian responsible for onboarding a new cert, after that they dont need to provide anything else. It is a problem that appears exactly once in a blockchain, while cert renewals are their achilles' heel
E.g. "Hundreds of thousands of domains' certs expire after 2099". Yeah, but no publicly trusted certs. They're capped at a bit more than 2 years and there's a discussion to cap them even more.
The certs they're seeing are almost certainly mostly: "let's create a test selfsigned cert for this host. how long should it last? let's type in a large number so we aren't bothered by it any time soon."