Let's Encrypt Hits New Milestone: Over 100,000,000 Certificates Issued (letsencrypt.org) 164
Josh Aas, the executive director of Internet Security Research Group (ISRG) writing for Let's Encrypt: Let's Encrypt, a free, automated, and open certificate authority has reached a milestone: we've now issued more than 100,000,000 certificates. This number reflects at least a few things: First, it illustrates the strong demand for our services. We'd like to thank all of the sysadmins, web developers, and everyone else managing servers for prioritizing protecting your visitors with HTTPS. Second, it illustrates our ability to scale. I'm incredibly proud of the work our engineering teams have done to make this volume of issuance possible. I'm also very grateful to our operational partners, including IdenTrust, Akamai, and Sumo Logic. Third, it illustrates the power of automated certificate management. If getting and managing certificates from Let's Encrypt always required manual steps there is simply no way we'd be able to serve as many sites as we do. The total number of certificates we've issued is an interesting number, but it doesn't reflect much about tangible progress towards our primary goal: a 100% HTTPS Web.
Value? (Score:2, Insightful)
I'm not sure that one of these certs is any better than a self-signed cert...
Re:Value? (Score:5, Insightful)
It's trusted by the browser by default, so it has that going for it.
Also, unlike self-signed certs it demonstrates that the person requesting the cert has control over the hostname(s), which is pretty much all I ever had to do when I paid for a non-EV certificate.
Re: (Score:2)
Also, unlike self-signed certs it demonstrates that the person requesting the cert has control over the hostname(s), which is pretty much all I ever had to do when I paid for a non-EV certificate.
How does it demonstrate that? Can you explain specifically what makes this better than self-signed certs? What is the basis of trust used to establish ownership? What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
Re:Value? (Score:5, Informative)
Im not that poster but I do have to look after a lot of servers with sites that have letsencryprt certs.
Basically it requires the same level of domain validation as any standard, non EV cert (including revocations) and provides the same level of protection for on the wire data interception with the disadvantage that certs are only issues for 90 days instead of 1+ years.
Look here for a overview of the the process, its pretty simple and the same as any other non EV cert:
https://letsencrypt.org/how-it-works/
Re: (Score:2)
Re: (Score:2)
How does it demonstrate that? Can you explain specifically what makes this better than self-signed certs? What is the basis of trust used to establish ownership? What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
Public key cryptography. The client has to satisfy both the domain control challenge, and sign a nonce provided by the CA. The domain control challenge establishes control over the domain. The signed nonce provides client identity verification.
https://letsencrypt.org/how-it-works/ [letsencrypt.org]
Re: (Score:2)
How does it demonstrate that? Can you explain specifically what makes this better than self-signed certs? What is the basis of trust used to establish ownership? What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
Public key cryptography. The client has to satisfy both the domain control challenge, and sign a nonce provided by the CA. The domain control challenge establishes control over the domain. The signed nonce provides client identity verification.
This isn't about the basics of PKI it's the basics of establishing TRUST that's the heart of my question regarding LE.
The basis of any secure system is TRUST not alphabet soups of cryptographic jargon. It's asking the basic question "WHY SHOULD I TRUST YOU?" and receiving a reasonable, verifiable response.
How does LE vet ownership to even assign certificates in the first place? What makes this process secure and trustworthy? If there is no good answer to that question all the cryptography in the world me
Re:Value? (Score:5, Insightful)
This isn't about the basics of PKI it's the basics of establishing TRUST that's the heart of my question regarding LE.
The basis of any secure system is TRUST not alphabet soups of cryptographic jargon. It's asking the basic question "WHY SHOULD I TRUST YOU?" and receiving a reasonable, verifiable response.
Trust whom, the site owner? LE? Their CA? If you don't trust root CA, then you are SOL. Better unplug your computer. Otherwise, there's your trust chain: root CA vets LE to a level sufficient to grant them an issuing certificate, LE vets the site owner to a level sufficient to grant them a hostname certificate.
How does LE vet ownership to even assign certificates in the first place?
Ownership of what, the hostname? The client requesting the certificate has to satisfy a challenge, for example placing a file with specific contents at a specific location controlled by the hostname, or populating a specific DNS record with a specific value for that hostname's zone. If the client is able to satisfy those challenges, then it already has complete control over the hostname and the content it serves.
What makes this process secure and trustworthy? If there is no good answer to that question all the cryptography in the world means nothing.
If you aren't willing to engage in a discussion about public keys and cryptographic signatures, there's no way to answer this question for you. The cryptography is how the process is secured, and the public key nature (combined with satisfying the challenge above) is how the CA establishes trust.
Re: (Score:2)
Ownership of what, the hostname? The client requesting the certificate has to satisfy a challenge, for example placing a file with specific contents at a specific location controlled by the hostname, or populating a specific DNS record with a specific value for that hostname's zone.
The concern being if you are launching a man-in-the-middle attack and you are near the server side of the connection, then you could pass such a challenge as well. Sure, in the overwhelmingly more likely case that you are close to the client side, you can't do this sort of thing, but it is possible particularly for small domains for an attacker to be close to the server side.
Now this may be no weaker than the status quo, I can't speak to that.
It's probably not good for https to pop up the word 'Secure' for
Re: (Score:2)
The concern being if you are launching a man-in-the-middle attack and you are near the server side of the connection, then you could pass such a challenge as well. Sure, in the overwhelmingly more likely case that you are close to the client side, you can't do this sort of thing, but it is possible particularly for small domains for an attacker to be close to the server side.
Not quite -- the client generated a private-public key pair when it first contacted LE, communications between the client and LE are encrypted, and the client answering the challenge is required to sign a nonce provided by LE using their private key. The MITM near the server side of the connection does not have the private key, and so cannot read what the challenge value should be, and cannot sign the nonce.
Re: (Score:2)
Not quite -- the client generated a private-public key pair when it first contacted LE, communications between the client and LE are encrypted, and the client answering the challenge is required to sign a nonce provided by LE using their private key. The MITM near the server side of the connection does not have the private key, and so cannot read what the challenge value should be, and cannot sign the nonce.
Are you referring to a legitimate domain owners client or an attackers client?
Re: (Score:2)
Are you referring to a legitimate domain owners client or an attackers client?
I was referring to MITM attacks on the certification process itself.
For an attacker to initiate the process and successfully complete the validation, they would either need control of the server (or be able to impersonate it), or control of the authoritative DNS records. In either case, the certification is logged publicly by LE. In the former case, you point your DNS somewhere else and generate new certificates. In the latter case, the "attacker" actually does control the hostname*, so the certification is
Re: (Score:2)
For an attacker to initiate the process and successfully complete the validation, they would either need control of the server (or be able to impersonate it), or control of the authoritative DNS records.
The assumption here is that it would be difficult to MITM LE themselves when doing authoritative DNS lookups.
You don't have to MITM LE's infrastructure. All that is needed is to MITM your victim's wire which may well include DNS traffic toward their (authoritative) DNS server.
Re: (Score:2)
You don't have to MITM LE's infrastructure. All that is needed is to MITM your victim's wire which may well include DNS traffic toward their (authoritative) DNS server.
This is one of the reasons I use a separate DNS provider.
Re: (Score:2)
Also keep in mind what an LE certificate actual says: https://en.wikipedia.org/wiki/... [wikipedia.org]
If the attacker controls the domain, then the certificate is valid.
Re: (Score:2)
If the attacker controls the domain, then the certificate is valid.
The problem is an attacker does not need to control the domain. They just need to control packets to and from it.
Re: (Score:2)
The problem is an attacker does not need to control the domain. They just need to control packets to and from it.
If they control all packets to and from the domain for all users, then they effectively control the domain. If they only control packets to and from the domain for a small subset of users that does not include LetsEncrypt (an assumption of the security model, and why LE likely uses several distributed servers), then they cannot successfully obtain a certificate.
Re: (Score:2)
Trust whom, the site owner? LE? Their CA? If you don't trust root CA, then you are SOL. Better unplug your computer.
My remarks are limited to establishing domain ownership.
Ownership of what, the hostname? The client requesting the certificate has to satisfy a challenge, for example placing a file with specific contents at a specific location controlled by the hostname, or populating a specific DNS record with a specific value for that hostname's zone. If the client is able to satisfy those challenges, then it already has complete control over the hostname and the content it serves.
DNS is insecure.
HTTP is insecure.
The routing infrastructure of the Internet itself (BGP et al) is insecure.
Both DNS and HTTP are subject to trivial MITM attack by anyone with access to a victims wires.
If the answer is it depends on responses from any of these protocols then one might as well implement RFC3514 and roll out a mission accomplished banner.
Re: (Score:2)
Re: (Score:2)
Sounds like your problem isn't with Lets Encrypt, it's with the entire concept of issuing encryption certificates, regardless of issuer.
My problem is with lets encrypt and every other CA automatically issuing certs using methods they know damn well to be completely insecure subject to the very same forms of attack certificates being issued are intended to prevent. It's a breathtakingly idiotic and dangerous practice.
I don't have a problem with the underlying technology. PKI is awesome when deployed properly. When deployed with the level of fail LE and other DV CA's are currently bringing to the table you damn well better believe I have a
Re: (Score:3)
The CA is not verifying that you are not doing anything bad, just that you control the web server. The same is true for LetsEncrypt certificates.
Re: (Score:2)
The CA is not verifying that you are not doing anything bad, just that you control the web server. The same is true for LetsEncrypt certificates.
If this were true there would be no problem. Unfortunately the assumption CA is verifying administrative control over a web server is provably false.
The entire point of having CAs issue public key is prevention of MITM attack from those with access to packets to and from a victims network.
HTTP traffic from any web server is trivially vulnerable to MITM attack. If I can access Internet traffic from my victims network I can go to any DV CA on the planet using completely automated means have a CA assign me
Re: (Score:2)
Let domain registrars handle it, so they can charge $99 a year for a secure certificate? That artificial barrier to entry and clear predation of consumers is precisely why Let's Encrypt was formed. A commercial CA doesn't give a fuck what happens to you as long as you paid for the cert.
My belief is one or both of the following must happen:
1. Domain registrars should be required to assign certs automatically as standard part of domain ownership or everyone should just drop the current system and switch to DANE. Registrars must not be allowed to treat it separately as an "add-on".
2. Domain registrars should be required to provide domain owners authorization tokens consumed by CAs and other entities to securely provide proof of ownership/control to existing DV CA's and or LE for verificatio
Domain verification (Score:2)
Can you explain specifically what makes this better than self-signed certs?
Self signed certs don't certify much (beyond the cryptographic validity of the key pair).
That means, on your first visit, that it's YOUR burden to check it that certification really belong to the domain, before trusting it and adding it.
(It could be a Man-in-the-Middle with their own self-signed certificate).
On the other hand non-EV certificates and Let's encrypt, all require some proof that the certificate requestor has a control of the server
(depending on the entity issuing the certification: requestor ca
Re: (Score:2)
The attacker would *ALSO* need to have access to the server they are trying to impersonate in order to successfully pass the validation. (And by that point, if the attacker actually controls that server, there's no need to fuss around with man-in-the-middle attack).
An attacker could use LE to setup a MITM attack, if they can hack the website.
1) Take control over the website.
2) Get a LE certificate for the domain
3) Export the certificate, and install onto their own malware site.
4) Phish a user into going to their MITM site, which has a LE signed certificate, that your browser trusts.
5)...
6) Profit!
Not worth the effort (Score:2)
The attacker would *ALSO* need to have access to the server they are trying to impersonate in order to successfully pass the validation.
(And by that point, if the attacker actually controls that server, there's no need to fuss around with man-in-the-middle attack).
An attacker could use LE to setup a MITM attack, if they can hack the website.
As I've explained in the quote you're replying to, if the attacker has control of the website, they can do pretty much everything they want.
At that point, getting a LE certificate is spending needless time on useless stuff that won't bring you much access beyond what you do.
1) Take control over the website.
At that point, the attacker has access to everything they could dream of. :
You can straigth jump to
4) Phish a user into going to their MITM site, which has a LE signed certificate, that your browser trusts.
Why MITM site ? The attacker has access to the real deal.
They could steal data straight from the actual site if they want.
Why LE signed c
Re:Value? (Score:5, Informative)
Also, unlike self-signed certs it demonstrates that the person requesting the cert has control over the hostname(s), which is pretty much all I ever had to do when I paid for a non-EV certificate.
How does it demonstrate that?
Because one must create a file under a name specified by LE, with contents specified by LE.
Only one with control over the webhost has access to create files on the webhost.
Can you explain specifically what makes this better than self-signed certs?
Anyone can create and sign a self-signed certificate with any domain(s) in it they wish.
You can not easily verify the website owner is the creator of the private key, and in fact the only one way to do so is to compare the certificate signature/hash you see with the website owner, which requires another form of secure out-of-band communications.
With LetsEncrypt, you personally for example can not issue a certificate for my domain.
I personally can not issue a certificate for your domain.
Additionally with self signed certificates, you would need to have end-users install your self signed public key in their browsers manually, and to actually be secure it would have to actually be the one you generated.
As an attacker I can provide my own public key to your users to trust, with your domain in it, and there is little chance they wouldn't know it was my key instead of yours.
Certificate Authorities have their public keys in the browser already.
What is the basis of trust used to establish ownership?
Access to a web servers files or DNS zone for the domain in question is required.
This is the exact same identical process any other CA in the world uses for class-1 certificates.
In other words, if you know how any CA handles class-1 certs, you know how LE handles them. It is identical.
What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
What prevents a person with control over the domain from requesting a certificate for that domain?
The exact same thing that prevents an attacker from getting a certificate from any CA issued for that domain - nothing.
If I was an attacker in that position to have control over a victims web host or DNS, I could get a certificate issued from Lets Encrypt, or GoDaddy, or ICANN, or any of the many hundreds of certificate authorities out there.
Re: (Score:2)
You can generate a certificate for any domain right now and install it anywhere. That's self signed. It's also why it's not trusted in a browser by default.
This authority is trusted by default. How does it prove you're the owner of a domain? Easy: it checks. The process is simple: Run a script on the server, server generates API request for a key to Lets Encrypt, that key gets dropped by the script on your server, another API request causes the Lets Encrypt server to check your server to see if the key is n
Re: (Score:2)
Re: (Score:2)
Let's encrypt is an issuing authority only. Issuing authorities don't have their certificates listed in the browser. The chain of these leads back up to a root authority. The certificate you're looking for in Chrome is IdenTrust's DST Root CA X3 as per the above poster.
Re: (Score:2, Insightful)
It's considerably better than a self-signed cert. Browsers don't accept self-signed certs by default, throwing up big nasty warnings. Lets Encrypt is a fully-accepted CA.
It also costs as much as a self-signed cert. That is, nothing. Higher utility at the same price is higher value.
Re: (Score:2)
1. There is no pretense of identification.
2. Learn the basics about certificates and what they ACTUALLY mean rather than what meaning you give them for whatever reason.
Re: (Score:2)
Actually these certificates are far better than a cert you'd buy commercially. The only way to get one is to control a server within the domain name. This is more verification than you get on anything but an EV cert.
Re: (Score:2)
Google started giving higher rankings to websites with HTTPS/SSL than websites without a certificate. Since Let's Encrypt is a free option at my hosting provider, I got certificates for all my domains and subdomains.
http://searchengineland.com/google-starts-giving-ranking-boost-secure-httpsssl-sites-199446/ [searchengineland.com]
Re: (Score:2)
Let's Encrypt is a shadow entity of the CIA so you have given them free run over all your domains.
Why do you think I work in government IT? :P
Re: (Score:2)
You aren't following the rule if you are using Let's Encrypt certificates on government systems. Yep, I work DoD IT.
Re: (Score:2)
Yep, I work DoD IT.
I work for a three-letter agency. Slashdot's favorite guesses include FBI, CIA, NSA and GPO.
Re: (Score:2)
Silicon valley, TLA, IT guessing you work on old Onitzuka.
The Blue Cube [wikipedia.org] got decommissioned in 2011 and demolished in 2014. My father and I did a construction job there in 1988, where we were locked inside the construction area for the duration of our shift and armed MPs with snarling guard dogs patrolled the perimeter of the chain link fence.
Re: (Score:2)
So you were 17 when you worked construction at an Air Force Base, while at the same time you went through your health issues?
I was 16 when I got a new bike and lost 70 pounds that summer from riding my bike all over the county. The health issues I had before then disappeared. I started working in construction when I turned 18 and went to college when I was 20. I rode a bike until my mid-30's and then switched to the gym for working out. Too many soccer moms were trying to run me off the road.
Very confused; please clarify.
https://www.cdreimer.com/slashdot.html [cdreimer.com]
Re: (Score:2)
Because you're too stupid and lazy to get a better-paying job elsewhere?
Fully funded, five-year contracts are a bit hard to find in the private sector. :p
Re: (Score:2)
You'd be fired within two weeks for any number of reasons.
The only time I was ever fired was when I worked my father and I punched the boss's grandson in the mouth. That was 27 years ago.
Re: (Score:2)
What happened? Did he reach for your sandwich?
He found out the hard way that I don't start fights but I do finish them. That always surprised people. Just because I'm fat doesn't me I'm a pushover.
Re: (Score:2)
Come on, I am 5'8'', 160 lbs and I can beat the shit out of you anytime.
Let's organize a contest so we can both add to our revenue streams...
Re: (Score:2)
Did you shoot him?!
Oh, no. What I did to him was much worse: I enrolled in college and started my technical career. Last I heard he was still a drug addict and living on welfare. His father shut down the family business after three generations when he retired ten years ago.
Re: (Score:2)
Come on, I am 5'8'', 160 lbs and I can beat the shit out of you anytime.
I'll gladly let you beat the shit out of me — and watch the police haul your sorry ass away. One guy thought I was joking about that, but I explained the situation to him: 1) he would rot in prison, 2) his wife would divorced him and marry the man that she's having an affair with, and 3) his daughter would have an excellent stepfather to take care of her. His bravado disappeared in a hurry. Last I heard he wasn't in prison but his wife divorced him, married the other guy, and his daughter loves her st
Re: (Score:2)
You're an abject failure.
If I was an "abject failure," I wouldn't be getting up at 4:30AM to go to my day job that pays the bills, come home and work until 10PM on my side business that brings in the cash flow.
Re: (Score:2)
You're working 18 hours a day to pull down 50k per year.
Nope. The day job that pays the bills is $55K per year with benefits. I've never stated how much cash flow that the side business generated. But don't let a lack of information stop you from speculating how many extra half-cents I make.
Meanwhile, the successful people are working 40-50 hours a week, and spending that extra time with their families, friends, and doing things that foster their spiritual, social, mental, and physical growth.
You mean when I was working 60 hours a week as a lead video game tester, attending two programming classes at the community college, going to church and teaching Sunday school? I'm not as young as I used to be. I'm taking life at a much slower pace these days.
Re: (Score:2)
A successful YouTube channel can generate 50K-60K Australian dollars per year, like EEVBlog.
That isn't Dave's only source of revenue. He sells electronic gear and t-shirts, affiliate links for products he reviewed, and accepts donations from viewers. A successful business should have at least 30 sources of income. YouTubers who rely exclusively on YouTube for income are screwed by the advertiser boycott and plummeting ad rates. I saw my rate go from $1.00 per 1K views to $0.70 per 1K view for one of my channels.
You're making MAYBE 150$ a year given your approximately 1000 hours you put into it.
Sorry, mate. That's how much I made this month for traffic-related ad revenues from Sla
Re: (Score:2)
Re: (Score:2)
I'm not sure that one of these certs is any better than a self-signed cert...
The value is that you don't have to pay some shifty dude $10 for the same level of verification, and it is auto renewing.
Re: (Score:2)
Other than not blocking people, or throwing a hissy every time you visit a site with any modern browser it's not different.
Re: (Score:2)
The value is that all the fake Paypal sites and banking sites are now secure! See the https? Secure! Like we taught everyone to trust the lock! Never visit a financial site unless you see the lock symbol in the corner of the window. It's the surest way to tell a fake site from a real site!
(Yes, it's a sad fact that a good majority of certificates are issued to phish users. We have to train users how to tell a real site from a fake site - no more relying on the lock).
Re: (Score:2)
Kind of like how SSH always treats your initial connection like a telnet connection? And warns you that unless you have authenticated the remote identity you should treat it as though unauthorized individuals are monitoring your traffic.
I am going to assume you meant it's always been stupid how browsers handled unauthenticated HTTPS certs. At the very least its necessary to warn about unauthenticated connections for all browser users, uneducated and experts alike. However, power users should be allowed t
Re: (Score:2)
I am going to assume you meant it's always been stupid how browsers handled unauthenticated HTTPS certs. At the very least its necessary to warn about unauthenticated connections for all browser users, uneducated and experts alike. However, power users should be allowed to enable a switch to avoid glaring popup messages about SSL certificates. Ultimately this is solved via extensions since this is not a use-case for the typical browser user, so your complaint is really one of personal inconvenience.
Everyone's personal convenience, not just mine. There's no reason the typical browser user should see any warning for self-signed HTTPS that would not also be displayed for an HTTP connection, it's in no way more dangerous. Browser developers are effectively giving handouts to the CA industry and hindering adoption of HTTPS by halting with an error when encountering self-signed HTTPS certificates.
Re: (Score:2)
Wait until your IA folks decide to flip the little switch making it so you cannot accept the unrecognized or self-signed certificate and continue on to the site or device. Some devices use self-signed certificates and make it impossible to replace the certificate with one from and internal or external CA. I'm looking at you Equallogic.
Re: (Score:2)
They're a little better in that the fact that they come from a cert authority gives you some assurance that you're not being MITM'd. But it has always been stupid that browsers treat an HTTPS connection with a self-signed cert differently to an HTTP connection.
All lets encrypt does is move the point of MITM vulnerability from establishing a connection to obtaining the cert. A functionally equivalent MITM opportunity to untrusted self-signed certs persist regardless.
The fact that end users see a padlock icon in their browser and *assume* their connections are secure when in fact there is no rational basis for such a belief is a far worse reality than doing nothing.
My own view is that ALL DV CA's including LE should be shuttered immediately. All responsibly tran
Re: (Score:2)
Re: (Score:2)
We could have had that.but DANE is worthless without DNSSEC and everyone is too lazy to implement DNSSEC.
DNSSEC should not be deployed until DNS amplification countermeasures are fully deployed. This can be RFC7873, TCP, (D)TLS... I don't care which... To go ahead with deployment of DNSSEC knowing DNS infrastructure will be leveraged to launch massive DDOS attacks is massively irresponsible.
Re: (Score:2)
That was more than you needed to write.
There should have been (and should now be) two separate icons: a cone of silence icon that indicates session encryption, and a second Alex Trebek icon that indicates that th
Re: (Score:3)
I agree with you, but I think browsers should treat HTTPS connections with self-signed certs the same as HTTP connections, as in not halting the connection with a giant warning page and forcing the user to jump through hoops before getting to the site. Let them through with the same little warning symbol now displayed for an HTTP connection. An HTTPS connection with a self-signed cert is in no way more dangerous than an HTTP connection.
Re:Value? (Score:5, Insightful)
The point being you connect to http, and no worries, it's all cool. It's warm and fuzzy and not at all something to fret about.
You connect to https with self-signed cert, *IT'S THE END OF THE WORLD*, you are horribly insecure, it's dangerous, you shouldn't even *try* to talk to the server, if you really want to you should click through 2 or 3 dialogs, and also you should be forced to do that every time you reconnect to the same server, without even a hint of whether the certificate changed from last time.
It's just such a strange disconnect. I have seen web server operators opt to prefer http rather than https so as not to scare off users, even if they may be handling potentially sensitive information.
Self-signed certs should be treated more like ssh keys in general.
Re: (Score:2)
Re: (Score:3)
It demonstrates that the one holding the cert also holds the domain name. Nothing else. And nothing else is implied by the whole deal.
Contrary to popular belief, a certificate isn't a government ID. All it means is that whoever claims to be www.whatever.tld is actually www.whatever.tld, and that no man in the middle attack is happening.
And once people learn this, we could maybe start establishing some sort of security. The fact that https:/// [https] isn't crossed out by your browser doesn't mean that www.bank0famr
Re: (Score:2)
It demonstrates that the one holding the cert also holds the domain name. Nothing else. And nothing else is implied by the whole deal.
Not quite: the key exchange happens over HTTP and doesn't always use DNSSEC, so all that it actually proves is that the person issuing the certs was able to receive and reply to TCP packets going to the IP address that the Let's Encrypt server's DNS reported was associated with the domain name. That's a somewhat weaker guarantee (though no weaker than most non-EV certs).
Let's Encrypt also logs all certs with certificate transparency and so you can check (by grabbing the CT logs or using a web search [crt.sh]) w
Re: (Score:2)
For example, I can look at my old university's computer society's CT log [crt.sh] and see that they switched from StartCom to Let's Encrypt when everyone stopped trusting StartCom last year and see that their last three certificates all have different public keys, which implies that either someone is rapidly rolling over certs for no reason and is a numpty, or that someone else is playing silly buggers.
That seems pretty reasonable: all of the listed certs from 2016-09-23 to the present (except on 2017-05-21, I have no idea what's going on there) have been replaced at 2-month intervals, which is in line with the recommendations and when the reference implementation of their ACME client (certbot) renews certs (the certs are valid for 90 days and are renewed after 60 days). Each renewal involves the generation of a new public/private keypair. All in all, seems pretty reasonable.
Re: (Score:2)
My certs expire every 30 days... (Score:2)
Re: (Score:3)
No! It expires every 90 days and you can renew after 60 days. RTFM.
Re: (Score:3)
No! It expires every 90 days and you can renew after 60 days. RTFM.
I stand corrected. After double checking my configuration, I have a different set of certs (five or so) expiring and renewing each month.
Re: (Score:2)
...expiring and renewing each month
You seem to be missing an important principle: You have to renew a cert before it expires, hence the 60/90 days schedule.
You don't renew a cert "when it expires".
Re: (Score:2)
You don't renew a cert "when it expires".
I get a handful of emails every month from my web hosting provider that my expired certs are being renewed automatically.
Re: (Score:2)
You don't renew a cert "when it expires".
I get a handful of emails every month from my web hosting provider that my expired certs are being renewed automatically.
Well, change provider if yours renew your certs only once they have expired! I begin renew requests for my certs 30 days before they expire. Again RTFM.
Re: (Score:2)
I begin renew requests for my certs 30 days before they expire.
That's the point you keep missing. I don't have to do anything because it's done automatically. I set it up once and forget about it.
Re: (Score:2)
My god! I am not missing any point. Do you think that I renew my certs manually and that your provider is the only one to automate the process??? Of course not, I have a script in a cron job that takes care of it.
Again RTFM, here you go since that seems hard to understand for you:
https://letsencrypt.org/2015/1... [letsencrypt.org]
Re: (Score:2)
Re: (Score:2)
The emails you are getting are pretty useless. I only get emails if the automated process fails. Then, I would get 30 days to monitor/fix it if it ever occurs. This is pretty standard for a Let's Encrypt setup. You would know about it if you actually ever implemented the process yourself.
Re: (Score:2)
The emails you are getting are pretty useless. I only get emails if the automated process fails.
According to the provider TOS for Let's Encrypt, I authorized the sending of renewal and revocation emails.
You would know about it if you actually ever implemented the process yourself.
It takes 15 minutes to set up a dozen websites using the provider's webpage. Setting up multiple cron jobs will probably take a bit longer than 15 minutes. I got too many items on my to do list to dive into the cron job rabbit hole.
Re: (Score:2)
Setting up multiple cron jobs will probably take a bit longer than 15 minutes. I got too many items on my to do list to dive into the cron job rabbit hole.
1 cron job for ~90 websites. No need to modify the cron job to add a new site, duh.
here you go:
https://github.com/srvrco/gets... [github.com]
Just as fast as your provider and I hate web management interfaces. As a matter of fact, it is probably faster than it is at your provider because all you need to do is edit text files.
Re: (Score:2)
oh, and my mod_security reverse-proxy routes all Let's Encrypt challenge requests to the same folder for the ~90 sites so no messing around with the websites content.
As a matter of fact, my customers don't need to do anything or touch their website. I guess it beats your setup because you say that, as a customer, you must set it up on you provider "web page".
Re: (Score:2)
[...] the same folder for the ~90 sites so no messing around with the websites content.
My provider does the same thing. Is this supposed to be significant?
I guess it beats your setup because you say that, as a customer, you must set it up on you provider "web page".
As an end user, I just want to set it up and forget about it. I did it six months ago. I haven't looked it at until today. I'll probably won't look at it for another six months.
Re: (Score:2)
As an end user, I just want to set it up and forget about it. I did it six months ago. I haven't looked it at until today. I'll probably won't look at it for another six months.
hmmm... reading comprehension?
My point was that my own customers never have to set up anything.
Re: (Score:2)
OK, here I go: what is your security clearance level?
Re: (Score:2)
My point was that my own customers never have to set up anything.
Your customers have you. I have myself and my provider has a web interface. What's the problem?
Re: (Score:2)
Bragging from the start about things you don't master?
Re: (Score:2)
Bragging from the start about things you don't master?
My business doesn't require that I master every little detail. Some details I leave to others to free up my valuable time. A web interface that allows me to set up my domain and cert at the same time Is quite efficient.
Re: (Score:2)
Yes, your "business", singular, down from the 30 businesses you had three weeks ago.
My business has 30 revenue streams. Many of which don't require my personal attention and I still get paid whether I do anything or not. It's called passive income.
And your valuable time ... spent on Slashdot.
I'm currently on the express bus. I pay an extra $70 per month to take the express bus and free up 40 hours per month to do other things while someone else does the driving. Like responding to emails and Slashdot comments.
Re: (Score:2)
BTW, this song plays every time I read your comments:
Here's my theme song when I comment on Slashdot.
https://www.youtube.com/watch?v=C_Dywv-dfws [youtube.com]
Re: (Score:2)
There's no way you're making any appreciable money from the utter horseshit I've seen from you.
According to the Slashdot consensus, I'm making a lot of half-pennies.
Re: (Score:2)
Express bus, this is pure genius.
Why didn't I think of it before?.
Re: (Score:2)
The link looks nice but I didn't bother to click.
Congratulations! ;-)
Re: (Score:2)
Still 5 cents in the US or is this specific to states?
Re: (Score:2)
While at it, for very sensitive customer internal stuff, use a sub-domain with self-signed certs. You never know.
Re: (Score:2)
Re: (Score:2)
True enough, I have renewed several times in the same day when setting up automation. 60/90 days seems like good default values for now with a concern to not overload the system for nothing. This is what is recommended here:
https://letsencrypt.org/2015/1... [letsencrypt.org]
Also 60/90 is fine for me because I always manually restart apache (apachectl restart) at least once a week so new certificates should always be loaded on time. I don't want the automated script to restart my server for stability concerns.
On a side note,
Re: (Score:2)
On a side note, most clients seem to have way to many dependencies. I found a pure bash one without any dependencies
acme-client [kristaps.bsd.lv] has no dependencies and is implemented as a small set of privilege-separated programs, so the thing that handles your private key and the things that makes network connections are entirely separated and the thing that an attacker might compromise runs with very limited privileges.
Why so many negative comments? (Score:3, Insightful)
Wonder... (Score:2)
What is the respomse from commercial xert businesses about Let's Encrypt?
Re:Wonder... (Score:4, Interesting)
Re: (Score:2)
What is the respomse from commercial xert businesses about Let's Encrypt?
Probably not fussed. Lets Encrypt can only provide non-EV certificates, which make them essentially useless for anyone you need to trust, e.g. bank, site which handles payment or sensitive information, etc.
non-EV certificates were never too expensive anyway.
Over 100,000,000 certificates issued... (Score:2)