What is the use case or benefit for the server admin?
as a server admin I wouldn’t want to keep renewing my cert.
can anyone help to explain?
Lets Encrypt certs tend to be renewed by a cronjob, anyway. The advantage is that if someone gets your cert without your knowledge, they have, at most, six days to make use of it.
If they get it without your knowledge, what are the odds they can get the new one too?
If they got it with your knowledge, can’t you just revoke the old one?
That makes little sense. If they can get my certificate then I have different problems that ,a 6 day turnaround isn’t going to solve
Presumably, you’ve patched up whatever hole let them in.
I understand their reasoning behind this, but I am not sure, this is such a good idea. Imagine Letsencrypt having technical issues or getting DDoS’d. If the certificates are valid for 90 days and are typically renewed well in advance, no real problem arises, but with only 6 days in total, you really can’t renew them all that much in advance, so this risk of lots of sites having expired certificates in such a situation appears quite large to me.
That’s true, but it would also have to be a serious attack for LE to be down for 3 entire days. There are multiple providers for automated certs, so you could potentially just switch if needed.
Most companies are not really suited for instant switching to a different cert service.
The attack would only need to last for a day or two, and then everyone requesting updated certs when it stops could push enough people outside the 6-day window to cause problems. 6 days is probably long enough to not be a huge issue, but it’s getting close to problematic. Maybe change to 15 days, which should avoid the whole issue (people could update once/week and still have a spare week and a day to catch issues).
I volunteer to help with IT at a makerspace, and I hesitate to go for 6 day expiration times. As volunteers, we can’t always fix problems in a timely way like paid IT staff could. We try to automate the hell out of everything, but certs have gone a day or two without getting updated before.
No one forces you to use let’s encrypt certificates. Can just quickly switch to another one temporarily.
Yeah, if you notice within that 6-day window before it expires. If you don’t catch it, your service could be down while you fix it, and that’s bad.
Yeah you might be on vacation when it happens
Yeah you might be on vacation when it happens
What the fuck is a vacation?
And then you forget about CAA records and wonder why it’s not working
When I look at the default list of trusted CAs in my browser, I get the feeling that certificate lifetimes isn’t the biggest issue with server certificates.
People who’d abuse trust into centralized PKI system are not real, they can’t hurt you, because if they abuse it, said system’s reputation will fall to zero, right?
Except it’s being regularly abused. LOL. And everybody is using it.
The sites I have most frequently have had to add expired certificates to use are US government websites. Particularly those affiliated with the military branches. It’s sad.
Yes X.509 is broken. If you’re a developer and not pinning certs, you’re doing it wrong.
Yeah, now imagine pinning certs that change weekly.
My first thought is that old school secure software (like claws-mail) treats a cert change as a minor security incident, asking you to confirm every time. Completely different school of thought.
You can pin to your own CA. Then it doesn’t matter if you want to update your certs frequently.
Right
What
What part are you confused about, and are you a developer?
Edit: why was I downvoted for asking this?
I’m a developer and would appreciate you going into more specifics about which certificates you suggest pinning.
I’m saying that if you’re a developer of software that communicates between two nodes across the internet, you shouldn’t rely on X.509 because the common root stores have historically been filled with compromised CAs, which would let someone with that CA decrypt and view the messages you send with TLS.
You should mint your own certs and pin their fingerprints so that your application will only send messages if the fingerprint of the cert on the other end matches your trusted cert.
OK, so cases where you control both ends of the communication. Thanks for the clarification.
And your software stops functioning after X years due to this.
Don’t do this, this is a bad idea.
Yeah, fuck the users. We can just slap “100% secure” on the box and who cares if some woman is raped and murdered because we decided not to follow best security practices, right? /s
Since I set up a https website (lemmy) and had to deal with the hassle of certificates, I do wonder why you need another entity to churn out what’s basically a RSA key pair?
Is it this you must trust the government again or is there some better reasons for it?
It’s to make sure you’re actually reaching your intended endpoint. If I’m visiting a site for the first time, how do I know I actually have THEIR certificate? If it’s self generated, anybody could sign a certificate claiming to be anybody else. The current system is to use authority figures who validate certificates are owned by the site you’re trying to visit. This means you have a secure connection AND know you’re interacting with the correct site.
Okay fair enough, but can I be a trusted entity and offer that service?
I don’t know what the process is like to become a certificate authority. I imagine the answer is technically yes but realistically no, at least not as an individual. You’d be providing a critical piece of internet infrastructure, so you’d need the world to consider you capable of providing the service reliably while also capable of securing the keys used to sign certificates so they can’t be forged. It’s a big responsibility that involves putting a LOT of trust in the authority, so I don’t think it’s taken very lightly.
Correct, though to be pedantic anyone can be a CA- you just generate a cert with the right bits to say it’s a ca certificate and then use it to sign any other certificate you want.
But the only devices that will consider your signature worth anything are ones you also install your ca certificate on. So it’s useful and common in internal networks but isn’t really what is being asked here.
The hard part is getting in the root CA store of operating systems and browsers. As far as I know they are all maintained independently with their own requirements.
Your browser and/or OS has a list of trusted certs called “certificate authorities”. When it receives a cert from a web site, it checks that it was signed by a CA. So what you’re asking is to become your own CA.
That basically means convincing Mozilla, Microsoft, Google, Apple, etc. that you know how to safely manage certs. It tends to be a pretty high bar. For example, many CAs have a root cert that they keep locked away in a safe that only a few people have access to behind several other layers of security. They have a secondary key that’s signed by the root, and the secondary key is used to sign actual customer certificates. That way, they can expire the secondary every year or so and only ever use the root when they need a new secondary. IIRC, Let’s Encrypt has two secondaries with overlapping expiration times.
So to answer your question, no, not unless you’re willing to go to great lengths and have a great deal of knowledge about TLS.
Sure, just convince the creators and maintainers of important software certificate stores to add your trust root. For example: Google, Mozilla, Microsoft, Apple, Linux, Cisco, Oracle, Java, Visa.
Question, if I can get free valud certs today (there atey sites that give you free ones, I use one for my lemmy site), where’s the security?
I mean it’s secure against man in the middle, but if my site is hacked, no proof is going to prevent the hackers to distribute whatever they want.
Certificates are to protect against MitM attacks, not prevent your site from getting hacked. You need to secure everything, this is one aspect of it
So why can’t I make my own cert? Give the caller my public key and on we go.
You can distribute your public key, and have people manually add it to their trust stores.
But OSs and browsers ship with preloaded trusted certificates. This way, the owner of a preloaded trusted certificate can issue new certificates that are automatically trusted by people’s OSs and browsers.
To become a preloaded trusted certificate owner, I imagine that there are stringent audits and security requirements. Part of that will be verifying the identity of the requester before issuing them a certificate.With LetsEncrypt, they either need to talk to a server hosted at the domain to retrieve a token (generated when the request is initiated).
This proves the requester owns/controls the domain and the server (the requester has correctly set up DNS records, and placed the required token on the server). This is HTTP challenge mode.
The other method is by a DNS challenge. The requester adds a TXT record to their nameservers with the token value, letsencrypt then inspects the DNS records for the domain and will issue a cert when it sees the token. This proves the requester owns/controls the domain.So, proving identity is required (otherwise anyone could generate a trusted cert for any domain). And trusted certificate issuers are required, so people don’t have to constantly import (possibly dodgy) public keys
Give the caller my public key and on we go.
And how does the client validate that your public key is actually your public key and not some attacker’s?
The idea of having a trusted 3rd party is to ensure that some impartial and trustworthy arbiter can confirm to the client that yes, this certificate is trustworthy, because they issued it to the correct party.
But you can absolutely self-sign a certificate. Works just fine, though not all clients accept self-signed certificates as trustworthy as anyone could have issued it.
You can make your own cert. To make sure your cert belongs to you (your site) it is signed by authority and the client then may verify that authority (which cetificate is preinstalled in their system) in fact had verified ownership of your site and then signed your cert claims with their private key.
Well it stands to reason, that TLS, i.e. Transport-Layer-Security, would secure the transport, and not secure the server providing the service against intrusion.
Also how is your hypothetical related to cost of certificates? If you use an expensive certificate with in person validation of your organization and its ownership of the domain name (these types of certs exist), then how does that change the case where your site is hacked, compared to the free certificate?
Don’t certs just create an ephemeral key pair that disappears after the session anyhow? What does cert validity period have to do with “This is a big upgrade for the security of the TLS ecosystem because it minimizes exposure time during a key compromise event.”
I mean, it’s LE so I’m sure they know what their talking about. But…?
compromising a keypair is a huge win. lets you impersonate the domain. shorter validation periods = smaller windows of compromised situations.
basically the smaller you make the window the less manual intervention and the less complicated infrastructure gets. currently TLS systems need a way to invalidate certificates. get them down to a day and suddenly that need just disappears. vastly simplifying the code and the system. 6 days is a huge improvement over 90 days.
Ok, I slid right by the “compromised” word. Makes sense now.
you mean you slid right on by an understanding of how security infrastructure works. since one always assumes credentials will be compromised.
I’m far from an expert on PKI, but isn’t the keypair used for the cert used for key exchange? Then in theory, if that key was compromised, it could allow an adversary to be able to capture and decrypt full sessions.
Im also not an expert but i believe since there Is still an ephemeral DH key exchange happening an attacker needs to actively MITM while having the certificate private key to decrypt the session. Passive capturing wont work
No. Perfect Forward Secrecy (ephemeral keys) prevents this type of replay.
Time for a dive, thanks.
Although this only was added in TLS1.2 I think. I had to switch it on manually for my server.
I think it’s default for TLS1.3.
Have you read about perfect forward secrecy?
The key pair you’re thinking of is just a singular key for a block cipher. That key needs to be generated/transmitted in a secure manner. Meaning that its security is dependent on the cert. The expiration time of that cert is what they’re aiming at.
Interesting. I use LetsEncrypt largely for internal services, of which I expose a handful externally, and I’ve been thinking of only opening the external port mapping for cert renewals. With this at 90 days, I was planning on doing this once/month or so, but maybe I’ll just go script it and try doing it every 2-3 days (and only leave the external ports open for the duration of the challenge/response).
I’m guessing my use-case is pretty abnormal, but it would be super cool if they had support for this use-case. I basically just want my router to handle static routes and have everything be E2EE even on my LAN. Shortening to 6 days is cool from a security standpoint, but a bit annoying for this use-case.
You can use DNS challenge to renew your certificates without opening ports! Have a look at acme.sh for automation.
Oh, awesome! I thought that was a manual process, so I’ve been using the regular method.
Looks like I have a new project for this weekend. My DNS is currently hosted at Cloudflare, so this should be pretty straightforward.
Caddy with the cloudflare module makes TLS with DNS verification insanely simple
Nice! I use Caddy, so this should be a snap.
certbot has modules for most DNS providers as well.
It’s kind of in line with their plan to get rid of OCSP: short certificate lifetimes keep CRLs short, so I get where they’re coming from (I think).
90 days of validity, which was once a short lifetime. Currently, Google is planning to enforce this as the maximum validity duration in their browser, and I’m sure Mozilla will follow, but it wouldn’t matter if they didn’t because no provider can afford to not support chromium based browsers.
I was expecting that they reduce the maximum situation to e.g. 30 days, but I guess they want to make the stricter rules optional first to make sure there are no issues.
Digicert, Sectigo, Globalsign: hold my beer, 1 day certificate, even better: on the fly certificate per client 😂
Which of them is free?
I wonder how short this could conceivably go…
Dynamic generation. There is no certificate until user request.
Perfect, let’s also bind the certificate to a user session that is derived from a user fingerprint. That way the CA can track users across all sites
I just want to serve https, not get someone’s dick permanently installed in my ass
deleted by creator
Increase how often the drones call the mothership, excellent.
