There's nothing magical about automating certs, just ask codex to do it for you if you really can't.

[-]

thortgot@reddit

Until you come against the several dozen scenarios in cases where it can't be done.

[-]

throwawayPzaFm@reddit

Sure. Then you send an email to management and they can decide on whether to implement something better or pay you or someone else to keep doing it.

Costs for legacy crap come up all the time. Your flair tells me you're aware of this.

[-]

thortgot@reddit

The frustrating thing to me is the incremental security between 90 days and 49 days for a cert being compromised is fairly pointless.

If the argument is we need unique keyed certs to avoid compromise attacks then we should be focusing on DANE which actually solves the problem instead of ugly solutions like max expiry length.

I'm sure CA attacks have happened but they are largely theoretical risks rather than practical.

PQC attacks are a much more practical risk but we don't see remotely the same pressure for everyone to update algorithms.

[-]

NH_shitbags@reddit

Well yes, clearly the most uber-secure way of doing it for sure!

[-]

JwCS8pjrh3QBWfL@reddit

TLS-OAUTH lol

[-]

skyb0rg@reddit

I mean this is essentially what OCSP stapling is.

[-]

NoSellDataPlz@reddit

Exactly. Take the horseshit arguments of “security” to their natural endpoint… certs that are created and destroyed on-the-fly… but then that eliminates a need for certs because if someone’s login gets compromised, then the cert doesn’t do anything to protect them. Reasonably, certs are fairly useless and pointless. Instead of punishing us grunts who’ll be doing the work, how about building a better way to prove trust and authenticity? But then the CAs would have to take responsibility for it, and that’s costly. Nope! We’ll push the cost on to the consumer and make it mandatory! Know what that’s called? Antitrust. “You can’t live without the Internet, but you can’t use the internet services unless the service has a certificate which only we can provide… oh, and it costs money to get a certificate so… pay up”.

[-]

Cyhawk@reddit

Instead of punishing us grunts who’ll be doing the work,

TBH Thats your fault for doing actual work beyond configuration. Certbot is free, automation is free, reverse proxies are also free. The only part of certs that aren't free and automated is the domain name itself.

TLS certificates were originally sold to imply both encryption and trust... but a certificate only proves domain control at the time of issuance, which is a fundamental flaw. They tried to solve it with CRL (Certificate Revocation Lists), which, depending on the cert issuer, had serious capacity and reliability issues. They tried to solve the CRL problems with OSCP (Online Certificate Status Protocol). Shortened lifetimes seems to be a duct-taped solution: we haven't solved the underlying problems, so the best we can do is shorten how long those problems persist.

DANE solves some of these problems but it's not widely supported yet.

[-]

Yeseylon@reddit

Since you actually seem to know things... Which "random people" decided 49 days was best practice for SSL certs? NIST? PCI?

[-]

Virindi@reddit

It's decided by the CA Browser forum. The membership list is reasonably long, but there are some big names there: Apple, Amazon, Cisco, DocuSign, GoDaddy, Google, Microsoft, Mozilla, Sectigo, Visa. The membership list is split into "Members" (Producers of certificates) and "Consumers" of certificates so that the conversation has representatives from both halves (cert creators and cert consumers).

Ballot SC-81 v3 maps out the timeline:

Year / Date	Cert Lifetime	Domain Validation Reuse
Today	398 days	398 days
Mar 15, 2026	200 days	200 days
Mar 15, 2027	100 days	100 days
Mar 15, 2029	47 days	10 days

They want 30 day certs; the extra 17 days is to give people a buffer for two consecutive weekly update failures, plus a couple days. They're also shortening how long CAs can "cache" domain validation. Today, they only have to do it once for the lifetime of a 1 year certificate. In 2029, they're only allowed to cache for 10 days. That doesn't mean they're required to constantly validate every 10 days though, it just means when you try to renew your 47 day certificate, if the last validation was >= 10 days ago, they're required to re-validate.

If you crystal ball the future, I think it's clear they're abandoning the idea of CRL and OSCP and leaning into using certificate expiration as the "control" for compromised certificates. If I had to crystal ball it, they'll keep proposing shorter and shorter lifetimes, perhaps ending up with 24 hour certificates in 10 years (but that's not official and not even being discussed, just my guess).

[-]

ocdtrekkie@reddit

The CAB is an organization structured to ensure complete unaccountability: Each organization's leadership generally assumes their CAB rep is the expert, so nobody will question them at each company that employs them, and at each organization can largely fall back on "everyone else voted for it".

But it's also important to understand the CAB only has three members that matter: Google, Microsoft, and Apple. Because what they decide to implement (often unilaterally!) must then be followed by the entire CAB, and is approved by the entire body. I believe in this case Apple unilaterally decided it was going to start rejecting longer lifetime certificates, which meant everyone else had to fall in line if they wanted to sell certificates that worked on the iPhone.

The CAB is full of people who have a hammer, and think everything in security can be solved with a nail, and structurally there is nobody out there that can tell the CAB no.

I'm actually glad they're doing this 47 day nonsense, because it is going to accelerate Internet breakage so badly, the CEOs of Google, Apple, and Microsoft will have to find out what happened, find out they have some person in charge of that who voted for it, and finally promptly fire them for costing their customers billions of dollars in damages.

[-]

CandylandRepublic@reddit

If anything that's a collusion lawsuit, but nobody is going to get fired for any of this. It's working like intended, by the big guys.

[-]

PowerShellGenius@reddit

I agree it's broken. But what other system do you have in mind?

Keeping in mind pervasive surveillance is one of the top threats TLS is designed to withstand, and a government based solution would NOT revoke CAs caught issuing certs to spooks for domains spooks don't own...

[-]

ocdtrekkie@reddit

First of all, the entire Let's Encrypt/ACME system is an insane way to work around using DANE just to keep the CA/B in a position of control over the web. It's already DNS authenticated but most people don't realize their DNS/domain registrar is actually their most important account to secure. We should be using DANE.

Second, we need to reestablish support for EV certificates with clear country of origin indications and improved policies for validation and criteria for notability. (Not everyone should need one, it's okay to make them unavailable to most customers!)

The fun part is that these two things are both outright unsupported in the browsers which control the CA/B!

Certificate lifetime needs to go away as a critical signal, it is at best a warning we should put a small indicator for in the address bar, not a realistic reason to ever block access. HSTS mostly needs to be deleted, but CAA records need to be much more heavily promoted.

[-]

PowerShellGenius@reddit

I agree with a lot of that, but the one issue with DANE as compared to ACME DNS-validated certs is: what replaces CT logs?

Currently, you are entirely correct that if you control DNS you can get a cert for a domain anyway, so from a basic "security is just about preventing an incident" view, it is already security equivalent to DANE with needless complexity and expiration thrown in.

But when you recognize that there will always be incidents, cases where someone can trick, hack, game, or coerce the system - and that ensuring incidents will be detected and responded to is also a key part of security - you see that CT logs serve a critical role.

All of the following are legal entities, some of whom are subject to coercion from [insert your least trusted countries here], as well as full of social engineering susceptible humans and other security holes:

Your DNS registrar
The holders of all DNSSEC keys including the root
Network transport providers (ISPs)
Each country/state/province's entity responsible for maintaining a register of corporations and business entities

So whether you are verifying domain ownership (by ACME, or DANE, makes no difference), or legal identity via OV/EV, the system is not perfect. It can be tricked, hacked, coerced or otherwise subverted. Someone can hack your DNS registrar, be a malicious insider there, do a large scale DNS poisoning attack like foreign threat actors can, or have an unconstitutional secret warrant for your DNS registrar, or even impersonate you to your secretary when telling them to accept the EV cert validation call at the front desk.

However, the current web PKI ensures that these incidents will be caught and brought to light.

Under your proposed replacement of DV certs with DANE, how would I as a website operator know that the public DNS has (due to technical, social engineering, or coercive reasons) lied to a client about what my site's key is to facilitate a man in the middle attack against a user of my site?

Under today's ACME+DV certs web PKI, if the MitM cert was published in the CT logs I would know, and if it wasn't, browsers would reject it.

[-]

ocdtrekkie@reddit

Sure there are CAs, who charge $$ per-cert, and their automation is (mostly) abysmal.

[-]

Privacy_is_forbidden@reddit

Why is 47 days enough? shouldn't it be only valid for a nanosecond or even less?

It does have some logic:

the base interval on which one should count on the certificate is one month
after that, the certificate should be reissued, within at most 2 weeks; that corresponds proportionally to the way LetsEncrypt has been operating (90 days and should be renewed at 2/3 through the interval)
plus one day to catch issues like misconfigured time zones causing triggers to fire late, daylight savings time, and other time shenanigans

[-]

iamabdullah@reddit

It's to manage failure (2 weeks + a few extra days).

[-]

SnooDingos72@reddit

Digicert is nothing but Verisign passed down from Versign PKI/SSL to Symantec to DigiCert. Digicert has been loosing the market share & never had any innovation.

Interesting_Yam_3230@reddit

Remember when browsers turned the the address bar green for a site running an EV certificate? Mozilla and google killed that off too

[-]

retornam@reddit

EV certificates were unnecessarily expensive and not worth the effort. This was because Certificate Authorities (CAs) used the "green bar" to charge more for certificates that were technically identical to regular ones, except for some background check validation that the CAs themselves performed poorly.

[-]

chris77982@reddit

You'll find that a lot of corporate proxies won't re-encrypt traffic with EV certs, they'll just leave the connection encrypted. Mean important stuff like online banking isn't being compromised

[-]

retornam@reddit

I think your understanding of TLS and the CAB Forum requirements for TLS certs is flawed because none of that you said is true.

If you are certain it is link me to a line in the CAB Forum baseline requirements or any TLS RFC that makes this claim.

[-]

chris77982@reddit

It's my experience in various jobs over the last few decades. The corporate proxies would inspect most ssl/tls traffic, and re-encrypt with a corporate signed certificate. They wouldn't be configured to inspect and reencrypt EV certs.

[-]

retornam@reddit

There is no standard that prevents TLS inspection of EV certs like normal TLS traffic.

[-]

chris77982@reddit

No one said there was a standard. You'll find I said "a lot of" not "all"

[-]

retornam@reddit

I’m not sure why you commented then or what you wanted to point out. Extended validation certificates (EV certs) are quite similar to traditional certificates, except for the extended validation bits. They are not more secure and are not impossible to inspect with TLS.

TLS certificates were originally sold to imply both encryption and trust
This only applies to DV certificates.

You're right, and I should have reworded that slightly. People generally associated the "lock icon" and use of SSL at the time to mean the site could be trusted, even though only DV certs actually went through the basic verification process.

[-]

RBeck@reddit

The problem is 49 days is not a lot for a valid cert and a whole lot of a compromised one.

[-]

CubesTheGamer@reddit

Yeah kind of ridiculous you ask me. They need to just use CRLs and suck it up and accept connections will take a little longer.

[-]

I presume the initial rule is meant to be transitional: just short enough to force people to eventually automate, but just long enough that you could get away with not automating right away if there's some big problem in the way of your doing so.

Once the majority of SSL issuance is automated, there'd be no reason to not crank the expiration interval down lower.

Put those behind a reverse proxy that does support automating the cert update.

[-]

shulemaker@reddit

Front it with a reverse proxy or LB that can.

[-]

Internally? Absolutely. Some old taxi software bullshit. I only managed the server itself. Swapped the hardware before it failed. In 2021 I stopped almost all side gigs and made them migrate to a cloud solution. The Websphere server was Netware 5.1 and there was remote IP-KVM so I could at least VPN in and do everything remotely. There were also NW6.5 file servers with ancient GroupWise versions.

News flash for you, then 90% of companies are broken...

I agree with you, IT/Security should be in the initial conversations, not the Execs or sales people or whoever only, as they get sold on shiny marketing slides.

But again, reality is, most companies do not actually listen to IT and what they have to say. This comes from 10+ years working in MSP's across many industries, as well as in house roles early in my career. New tool comes along, it gets throw over to IT to implement ASAP.....and then we get to deal with it...

Luckily now, where I am, everything comes across my desk, so to speak, because I built that trust and can clearly explain why IT needs to be involved and they get it.

[-]

pixelpheasant@reddit

This is the way.

And what are the vendors supposed to do?

We have devices out in the field and don't own or control the endpoint workstations. We don't have or want admin rights to them.

Our current plan is to set up our own CA that they'll have to trust and then generate long term certificates. It makes them less secure because if our CA is compromised through an external 0 day they are wide open but I don't see any other alternatives.

[-]

streetmagix@reddit

You have devices on your network that you have no control over? Not even via a secured VPN?

If so, you have bigger issues that a short SSL time out.

[-]

klauskervin@reddit

It sounds like they provide devices to others that require a cert and have no actual control over access to those devices.

[-]

s32@reddit

Doesn't the cab forum ruling only cover server certs though?

[-]

Beznia@reddit

Also reminds me of SCADA networks

[-]

RememberCitadel@reddit

I feel like you are jumping to conclusions. They didn't say they weren't isolated or restricted in anyway, just that they didn't have admin rights.

That's super common all over the place. People have all sorts of weird devices for various required purposes, and the normal response is to just throw it in its own little dmz with restricted outbound communication, and no specific inbound allowed, sometimes your own staff need to be able to get to it however. That doesn't mean it doesn't need certs though, hence the issue.

[-]

gonewild9676@reddit

Devices on client networks.

Think something like a badge reader. It comes with a driver that is a small web API with a cert on it and our web application talks with the driver via https calls to tell it to read the card and send the card number back.

We have to keep a valid cert on that small web API without having admin rights on clients that we don't control.

[-]

Because a lot of the local sites don't have admin rights either. It requires intervention from their IT departments to get admin rights. Many remote assist apps block admin level changes so often this is an in person visit.

It takes us about a month now to get everyone updated with either a standalone exe or a deployable MSI that just installs the exe and calls it as part of the install.

The original plan was to use a Windows service to do the updates but then it would need to run as an admin and someone would have to maintain the password for it and be able to handle things if it doesn't work.

This is over thousands of sites and hundreds of IT departments of various sophistication.

[-]

mixduptransistor@reddit

I don't know the details of what you're doing but it sounds like whatever you've got out there in the field is convoluted as it is, so yeah I can see where this new requirement could be a problem

I'd probably step back and rethink the whole process. If you're managing certs for software that is installed on Windows machines that are not managed by an IT staff, I'm curious why you need certs at all. It's a little insane to be deploying little web servers out there that are not under the direct control of an organization's IT team

[-]

original_nick_please@reddit

Keep your CA offline and use an Intermediate CA with name constraints, problem solved.

[-]

Shot-Bag-9219@reddit

the expiry window will only keep going down. Should use something like Infisical to automate: infisical.com

[-]

DonFazool@reddit

Routers, switches, legacy hardware. You can’t put these behind a reverse proxy

[-]

rockmanbrs@reddit

I had this issue because the service was whitelisted so that only a specific internet IP could access it but this is where certbot becomes tricky because certbot needs to be able to access the web service to install the certificate automatically.

Internal devices/services are handled by an internal CA with working CRL etc.

your certs need to be public and working or stuff breaks

using self signed certs breaks that

using PKI makes things safer and more trustworthy than a random CA nobody knows

None of that is true really. There is no inherent trust of public CAs for EAP authentication, so every unmanaged Wi-Fi client will prompt the user to verify the server certificate, whether it's from a public CA or an internal one. And since the certificate cannot prove ownership of your SSID (unlike with domain names), in order to be secure users would have to manually specify a domain name to validate the certificate against, or anybody else able to get a certificate from your trusted CA for any domain name would be able to impersonate your server.

So in order to make sure your users connect securely you're going to end up with some sort of Wi-Fi provisioning profile anyway, and then you may just as well use your internal CA.

No point using a public certificate if you can run your own CA.

eduroam documentation: https://wiki.geant.org/spaces/H2eduroam/pages/121346323/EAP+Server+Certificate+considerations

[-]

KingDaveRa@reddit

Which is great IF the end users install the profile. Which they don't, generally. I'm not aware of any other institutions running private certs, but I'd like to be wrong.

I'd like to know what the uptake on the geteduroam app is, but I'd hazard a guess it's not that high.

yeah but what about the things you cant?

This policy is for public CAs which are part of the CA/Browser Forum only.

Self-signed certs, and certs from internal CAs (like ADCS), do not have this restriction.

[-]

bkrank@reddit

And sooooo, What about things you can’t? You know there a more than plenty of systems that you can’t automate that are public facing that require public CA’s to function. This decision is really a nightmare at this time. Sure, some day every appliance, firewall, SBC, etc will support automation of carts, but there are plenty of existing systems that just don’t support it today.

[-]

Whitestrake@reddit

This decision is really a nightmare at this time.

throw0101a@reddit

And sooooo, What about things you can’t? […] Sure, some day every appliance, firewall, SBC, etc will support automation of carts, but there are plenty of existing systems that just don’t support it today.

No doubt there seem to be, but I'd be curious to know specifics. Because there are (now) ACME clients that are specifically written so you get the certificate on one host, and use various protocols to push things to the device that the cert will actually live on, e.g.:

Get certificates for remote servers - The tokens used to provide validation of domain ownership, and the certificates themselves can be automatically copied to remote servers (via ssh, sftp or ftp for tokens). The script doesn't need to run on the server itself. This can be useful if you don't have access to run such scripts on the server itself, e.g. if it's a shared server.

https://github.com/srvrco/getssl

Post-issue hook scripts could push things the bits via Ansible or SNMP/APIs/SSH(expect).

[-]

It's not binding.

For things like mutual TLS you can still do what you like for certificate lifetimes and accept the risk.

The 49 day standard is to force the public CAs to adhere to best practices. The worst case scenario would be having widespread MITM attacks against all the customers of a specific CA because they decided that they wanted to have long-lived certificates and they all got brute forced. A CA which is lazy enough to want long-lived certificates is also the kind of CA who won't have their revocation process in order either, as we've seen in the past.

[-]

BlowOutKit22@reddit

it's much less harmful if a 47 day certificate gets leaked

what does medical IT care?

the dozen air gapped XP, NT, and mac classic machines will still be fine air gapped.

[-]

DonkeyTron42@reddit

Yes, there are many situations in medical and other industries that use MSPs and will consider this an unnecessary upsell. Even in fortune 500 technology companies I've seen situations where they still keep around Windows XP systems because they still have critical Flash/Java based systems and don't want to invest the capital to replace them.

[-]

da_chicken@reddit

Actually, I have. For 5 years. And I know you have the money to staff it out even if you don't like being a mechanical Turk.

If it's wholly internal, which almost everything should be, you can use your internal CA and sign them with a lifespan however long you want. You just have to deploy your root certificates. But if you don't have an internal CA in 2026 where you're already doing that, then I'm curious how you're managing your Joint Commission accreditation. And if you're not large enough to care about TJC, then you definitely have time to staff it out.

This is only a problem for the devices accessed by third party systems for exactly web traffic. That's almost entirely web servers.

[-]

OMGItsCheezWTF@reddit

At an old job we had a bunch of KVMs (like, a datacentre full of them) that used MD5 self-signed certs, baked in at the hardware level.

ThatOnePerson@reddit

Go old school and pay for yearly certs again.

[-]

tdhuck@reddit

I like how they are doing this because certs can't properly be revoked and hoping the 'bad guys' won't pay for certs/the process to automate, but we all know they will pay to automate because they make lots of money from these scams.

There was nothing wrong with 1 year, 2 year and 3 year certs imo.

[-]

TheDarthSnarf@reddit

It's more the case that the revocation lists are getting HUGE. Which is causing logistics and processing issues to do the cert verifications. Some vendors just aren't even bothering with the revocation checks.

Revocation lists get much smaller, and checks much faster, when there is a much smaller list because you only have to check revocation back to the expiration date of the cert.

From a technical standpoint it makes sense... from a sysadmin standpoint it's a real PITA.

[-]

HJForsythe@reddit (OP)

here's an idea. put the revocation in a TXT record in DNS of your domain for the certificate. lol.. omg why are we so stupid.

[-]

GoofyCum@reddit

How is a CA supposed to do that for a relying party, as is their obligation under the CA/BF Baseline Requirements within 24 hours upon discovering a key is compromised?

The point of shorter validity periods is that webpki certs have become the default for lots of things that don't need to be publicly trusted and can't be safely rotated in 24 hours, which we've discovered over the past few years and has already resulted in Entrust being pulled from root programs' trust stores. Microsoft itself has failed for 9 months to rotate a bunch of misissued certificates because of technical limitations on CRLs.

If you (the general you) are installing a public cert on something you don't control to the point you can't update for more than a week if it gets revoked, then the only practical solutions are use a private CA of some kind or invest as an industry in automating webpki cert rotation, which is ongoing work.

It sounds like a lot of sysadmins are having trouble making the business cases to their management about this, and that's the whole point of having this decision made by the CA/BF and imposed on them: suddenly it becomes a case of "companies won't issue us long-lived certs anymore, so we need to prioritise one of these two things." Much the same way that 3-year certs died to get people to adopt the basics of a certificate lifecycle management process, so too must the 1-year die so that compromised certs can be retired in a timely fashion.

[-]

The vast majority of OCSP implementations don't get rid of the CRL, they simply act as an abstraction layer for the CRL.

This simply shifts a heavier burden to the systems hosting the CRL as they now have to process the OSCP response after querying the CRL.

The CRL is still being appended for every revocation - it's just that the response is only a subset.

Meaning that OCSP is really just kicking the can down the road.

[-]

neoKushan@reddit

It has nothing to do with bad actors not wanting to pay for SSL certs and everything to do with improperly secured systems leaking their private certs that bad actors can use to spoof things.

It's trivial to get free certs from Let's encrypt today, even manually. That's not the issue.

[-]

ditka@reddit

People might be surprised, then, that acme.sh does not rotate the private key by default (https://github.com/acmesh-official/acme.sh/issues/1308). It just reissues the cert. So the short issuance policy doesn't help with stolen keys in that case.

[-]

neoKushan@reddit

That's a forward secrecy issue (As in, bad actors being able to decrypt the encrypted comms), the issue the short lifespan is trying to solve is a separate one around certificate revocation. Different problems.

[-]

ditka@reddit

If I have your private and public keys, I can spoof your website. Rotating your public (signed) key frequently doesn't help because I always have access to it (assuming your webserver is publicly accessible, I get it via TLS handshake).

[-]

neoKushan@reddit

You can't spoof the site with the private key of the cert because you don't have the private key of the signer (Let's Encrypt).

One key is for encryption, the other is for authentication. Different keys, different purposes.

[-]

tdhuck@reddit

If they leak their certs, they should be responsible and change them, not make the rest of the world pay for their mistakes/poor housekeeping.

[-]

neoKushan@reddit

You obviously don't understand the problem here. Changing a cert doesn't stop the bad guy using your old cert to do bad things. That's why you must revoke the cert.

[-]

tdhuck@reddit

I never said it did. I also never said you shouldn't revoke your cert.

[-]

neoKushan@reddit

So what exactly did you mean when you said "they should be responsible and change them, not make the rest of the world pay for their mistakes/poor housekeeping"?

Because the rest of the world does pay for it by having to deal with massive CRL's. The poor housekeeping is not having your certs automated in the first place.

[-]

tdhuck@reddit

If they 'leaked' anything then they should fix their mistakes. That's what I meant.

I never said anything about not automating. I'm talking about the duration.

[-]

It sounds like just one more way that things can be compromised. What happens when the process is hijacked because you know it will be at some point.

[-]

Sudden_Office8710@reddit

Dude quantum computing is coming it will obliterate anything that’s not TLS 1.3 they are not making it uncomfortable so that you automate it they are doing that because it’s the only to protect your environment. You all have the wrong mindset on this it just blows me away

[-]

Koxiaet@reddit

TLS 1.3 is also not quantum-resistant unfortunately. Hopefully we will see a transition to PQ cryptography in future TLS versions.

[-]

HoustonBOFH@reddit

"They are trying to make it uncomfortable enough that people will automate it."

Or just turn off https. I am seeing that more and more. Not everything needs to be encrypted, and the lazy factor often wins.

[-]

scotsman3288@reddit

We have our ingress(nginx) internet certs from Lets Encrypt automated with certbot(RHEL)....pretty pain-free process. 80% of our systems are internal though so everything else is self-signed for 10 years...

[-]

HeKis4@reddit

Yeah it's going to be a bit of a pain for airgapped services but there's nothing preventing you from spinning up your internal CA that is trusted internally. The venn diagram of stuff that is airgapped and stuff that needs a "publicly" trusted cert is almost two separate circles.

[-]

dustojnikhummer@reddit

Well, doesn't Safari already limit to like 825 days or something even for self signed?

Yeah… problem is the companies pushing this new lifetime window are also the ones selling automation tools…

[-]

STGItsMe@reddit

Yup. People have been doing this basically the same way for 30 years now. There’s no reason to do manual cert rotations.

[-]

BoringLime@reddit

Somethings are just hard to automate. The issue that stands out for our company is our rds servers. The actual updating the server is not that bad. It's the updating of the gpo for rds trusted sha1 thumbprints signature hash, comma separated list, in some automated way, that's secure. We aren't the only ones using it, so a internal ca is not an option. I just hate having to create high level service accounts that are basically domain admin powers, for things like this. We have other update automation issues as well, on our erp side. If it doesn't have the hash pushed down, it still works, but you get a do you trust prompt, instead of seamless launch of a rds app.

[-]

Erok2112@reddit

Can't wait for automated bad certs due to various reasons. That will be so fun.

[-]

bluesky34@reddit

49 days! You had it lucky.

[-]

sodiumbromium@reddit

I get it. It's fucking annoying.

The problemo is that, hey, there might just be some POS thing that needs a cert that you just can't automate for whatever reason. Don't have easy access, the things fragile as hell, the owners are a PITA.

Same concept.. force is needed sometimes.

[-]

NoSellDataPlz@reddit

“SHOULD be easy” is the problem here. It’s taking a hope and a wish and turning it into action. That’s stupid and irresponsible. In the meantime, I guarantee you that what’ll actually happen is everyone is going to let certs expire and just shrug when someone challenges them on it. “Accept the risk or don’t use the VPN”. “ Accept the risk or don’t get on the internet through our content filter”. “Accept the risk or don’t use an app to manage the HVAC system”.

[-]

CrotchetyHamster@reddit

We have a couple of decades now of nobody bothering to act when it's just a best practice, though. The reality is, causing pain is sometimes the only way to effect change.

Take it from someone who's worked at a few of the companies involved in these changes - they use this same approach internally, and they know it to be effective. Sometimes, when people refuse to make important changes, all you can do is make them required changes.

[-]

NoSellDataPlz@reddit

Even a large organization of a few thousand people is easier to address than literally every Internet accessible organization currently in existence being forced to change. Again, irresponsible and stupid.

[-]

CrotchetyHamster@reddit

The point here is that vendors won't change unless they're forced to, and while it will cause pain, the most common outcome if vendors refuse to update at this point is that IT departments will find new vendors who support automation.

And, look... I've worked in gnarlier cert-update environments than just about anyone here. As in, I've worked in major cloud vendors' air-gapped (JWICS) environments, where there's an entirely bespoke PKI infrastructure which none of the deployed software expects, and where you become intimately familiar with how various tools and programming languages provide their own CA cert bundles. I was part of an AWS classified region buildout that necessitated rotating every single secret in the entire region. And I've also been a one-man, small-business IT department, lest you think somehow AWS's internal tooling saved me from pain (though I assure you, it did not). I'm the goddamned Roy Batty of PKI infrastructure - I've seen things you wouldn't believe!

ecnahc515@reddit

Couldn't you issue your own certificate from your own CA for this? If it needs to exposed publicly use a reverse proxy to expose it and have the proxy handle certificate renewals with ACME.

[-]

tankerkiller125real@reddit

Her's a solution that I've found works on around 90% of systems so far (including raw TCP protocols), HA Proxy, self-signed long expiration on the legacy shit to HAProxy, auto-rotating short living certs endpoint/public facing.

[-]

accidentlife@reddit

The idea is that if you can’t manage your systems to meet this requirement, your system should not be on the internet.

If you want to meet it manually, that’s up to you. But Google expects that if your certificate is compromised you (and everyone else) are well practiced in reissuing a certificate and can issue one quickly.

They especially want to force change at large institutions that place certificate issuance behind multi week approval processes.

[-]

sodiumbromium@reddit

Note: I'm specifically referring to internally developed applications. At least in the places I've worked, IT gets caught in the middle between security yelling about best practices and the devs just not caring or not existing anymore.

[-]

discosoc@reddit

Do those things need trusted certs? The renewal times are only really about browser cert. Most everything else can just behandled with your internal CA.

[-]

gramathy@reddit

Internal certs do not need to meet the requirement, only public DNS based certs.

Just... 3 years ago? I was fighting with Barclays Bank in the UK for their business service because - whatever package we were using - they demanded Firefox ESR so they could load an NPAPI smartcard software from Gemalto to allow the smartcards to read in the browser for verification.

That place put MILLIONS of £'s through their accounts and it all had to be verified with that shite. We had that in place for TEN YEARS and despite asking for all that time, they said there was no alternative. It started with IE. Then we were made to use Edge (old IE-based version). Then we were made to use Firefox. Then Firefox ESR.

Then even Firefox ESR deprecated that shite and we were told to use an older version of Firefox ESR.

I was so glad to change to a rival company that didn't have that nonsense. I've been here 3 years, they have a different UK bank, and their authorisation smartcards just work in their default browser (Chrome or Chrome-based Edge) and we don't need to do a damn thing for them. My entire team have literally never had to deal with that side of things for the finance department at all in the time I've been here.

That's like complaining your you have a hard time getting a modern browser up and running um windows 95 and blaming javascript for it.

If you are using a dinosaur as a vendor, that's on you.

Just automate your shit, having certificates automatically renewed every 49 days is less effort than doing it once every 2 years manual.

[-]

HJForsythe@reddit (OP)

Okay but if the whole reason that the certificates have to expire every 47 days is because the technology itself is inadequate then what do we gain by automating the renewal of an inadequate technology? Do you not understand the concept?

[-]

schorsch3000@reddit

its not certificates / tls that is inadequate, it's people not being perfect while administering ther systems or random software with security holes that create a problem.

the same certificate would be good for years, but how would "the technology itself" make sure no one gets access to a server on a different way and just takes the private keys with them?

bringing down the lifetime to a time that makes stealing certificates/keys useless is the best thing you can to from within, or do you have a better idea to fix that?

[-]

AFlyingGideon@reddit

I've somehow picked up the idea that brief validity periods balance the lack of use of CRLs.

[-]

schorsch3000@reddit

which is a flawed workaround for insecure systems, yes.

throwawayPzaFm@reddit

Yes it can. Been doing it for years. Yes it required some glue.

[-]

Shadow591@reddit

If your vendor sucks, get a new vendor or use a FOSS alternative.

[-]

bwick29@reddit

Lol what? You new here?

[-]

HJForsythe@reddit (OP)

Also F5

[-]

WDWKamala@reddit

Meanwhile cert validity and revocation could be a simple DNS query. This whole thing is so stupid.

[-]

mixduptransistor@reddit

Okay, no one has said that isn't valid, or that the approach the CA/Browser forum chose is perfect, but it's what it is and if you can't automate certificate renewal the answer isn't to bitch about certificate renewal, it's to learn how do do IT in 2026

[-]

WDWKamala@reddit

I mean I’m dealing with it like everybody else. You can automate it or hide it behind a proxy while still birching about it.

[-]

HJForsythe@reddit (OP)

Wait you mean you can use DNS for checking the validity of things? SMTP would like a word with you young man ;)

Cant you just use the .pfx as a keystore? Atleast in tomcat you can

[-]

bondguy11@reddit

Unsure, I can tell you the last 5 years this is how the previous sysadmins where instructed to do it and it worked

[-]

Le_Vagabond@reddit

drop caddy or any reverse proxy in front of it and stop struggling. takes all of 2 minutes.

[-]

bondguy11@reddit

BACnet traffic will not respond well if we change any type of configuration with this server involving networking.

[-]

Le_Vagabond@reddit

drop the reverse proxy directly on the server then? change the ports the java app listens on, then proxy to them.

Unfortunately SSL bundled together two goals, one of which has been almost completely abandoned:

1) identity verification

2) transport encryption

Unfortunately what happened is people overwhelmingly wanted SSL for 2, and the requirements around 1 were overkill for like 98% of use cases.

The identity verification part has been weakened to the point of "did the DNS record of the domain for this cert check out when the cert was issued 3 days ago?" which is, honestly, pretty meaningless.

Your connection mechanism probably already depends on the DNS response for the domain right now, and there are a million better ways to establish DNS authenticity of an SSL connection's credentials with no central issuing authority at all if that is the limit of how much identity verification an SSL cert is going to offer.

We're in this weird middle place where, for historical reasons, a "self-signed" cert was considered insecure, yet now a "automatically signed cert that does nothing more than check DNS" is perfectly acceptable?

We could have just had DNS-backed SSL certs from the very beginning with none of this other renewal and central issuing authority overhead.

[-]

cheese-demon@reddit

it's not just historical reasons that a self-signed certificate is untrusted. your connection is encrypted, but to whom?

so browser vendors trust cas (who may trust subordinate cas) and eventually a cert is issued that the vendor trusts. there wasn't widespread dnssec support, and really there still isn't, so they've settled on "controls dns for a hostname, across a wide view" and that last phrase is relatively new since MPIC is now mandatory to be trusted. the end result is that certs are issued to entities that have proven they have at least done a full takeover of a dns zone.

[-]

nezroy@reddit

Yeah but I don't need a central authority if ultimately all I'm doing is verifying DNS owernship. I could check a cert pubkey against a DNS record in real-time, or consult distributed registries of my choice that track historical cert pubkeys over the last 60 days, or even just keep a local history myself, to check for suspicious changes.

The current system of trusted CAs and automated renewals is massively overly-complicated for a validation no stronger than "this cert was issued to the owner of the DNS within the last 49 days".

If that's the limit of my identity validation there are far easier ways to achieve that. Trusted CAs and cert issuance is an artifact of a time when identity validation was supposed to be considerably stronger than that.

[-]

cheese-demon@reddit

domain validation has never been that strong - an email to admin@ has always been accepted and is still allowed for another two years. remember whois? that was allowed! hell, your registrar could ask for certs on your behalf

the system that exists is the way it is so that browsers can validate a certificate against their own or the user's system's own set of trusted authorities, without requiring additional lookups from the browser. some of that's historical and not as needed since there's a lot more bandwidth than there used to be, but it's still reasonably nice that you can validate whether you're being mitm'd without needing anything more. historically CAs would be harder to MITM though it wasn't impossible, which is why MPIC is mandated now so someone would have to MITM multiple disconnected systems to get a cert issued without controlling DNS. that wasn't just a theoretical threat, KLAYswap users were successfully attacked by a BGP hijack of routes to a CA, then BGP hijacked to use their quite legit cert to direct users to their own servers

if you're not using a browser, or you control your infrastructure, there are definitely other ways you can go. you can trust your own self-signed certs, the browsers just want to chain to a trusted CA. so trust yourself as a CA and issue your own certs, browsers all accept this (with a big asterisk for Apple not trusting TLS certs with a duration longer than 825 days, but at least they're the only one).

Citrix netscaler

https://docs.netscaler.com/en-us/netscaler-console-service/networks/ssl-certificate-dashboard/automated-certificate-management-environment.html

What is this?

[-]

asmokebreak@reddit

You must be a god, my entire staff can NOT find a kb article on this and Citrix support was useless.

I bow to you. Now I gotta migrate off network solutions, but it was time anyways.

[-]

gex80@reddit

I just googled it. "citrix netscaler letsencrypt automation". Literally the first link on the search results.

https://i.imgur.com/xuOrae1.png

[-]

OddAttention9557@reddit

Claude and ChatGPT can both answer this question and provide guidance in a matter of seconds; if you're not already using these tools you really should be!

[-]

OddAttention9557@reddit

In fact, fire your entire staff; it's literally the first result in Google. God alone knows what else they're failing to find...

[-]

Joshposh70@reddit

Azure Key Vault certificates can only be automated if you pay Digicert, they don’t support any other CA.

You can script it if you want to spin up additional infrastructure and fancy maintaining a K8 or similar for the rest of eternity. But it’s not just a case of installing Certbot and walking away.

[-]

Mike22april@reddit

Theres various CLM products allowing you to use any supported public CA with Azure Key Vault

[-]

Long-term it's usually easier than not automating them. *shrugs*

[-]

50DuckSizedHorses@reddit

What are you using the certs for? Public web server PKI is already automated, and is not fairly comparable one to one with private infrastructure certs generated from a private CA where you can set any renewal time you want. If you’re talking about networking, wlan controllers, and private infrastructure servers, the vendors are way behind this idea of 49 days. They need to figure out a more complete and flexible way to give us all options other than manually replacing certs all the time, other than figuring it out on our own with APIs or bespoke automation.

[-]

whitemice@reddit

Yes.

So much of working in IT is now participating in Security Theater.

[-]

50DuckSizedHorses@reddit

Security Theater. I’m gonna use that.

[-]

Iriguchi@reddit

I find it so funny that a lot of answers here are about automation, but never answer the actual part of your question.

So first and foremost: yes, automate it all, "problem solved" is kind of the short term correct answer.

However, I do feel you have a point, and I share your sentiment about the second part. Namely, the reason for said timeframe and the entire validity of certificates.

So they want to shorten the lifespan because they say "we cannot be sure that the private key is safe for such a long period of time like it was before". I wouldn't even object to that statement, except for the ridiculousness off what it is becoming. We went from 5 years to 2, to 1 year. Now some standards are already at 6 or 3 months.

So the actual question is still standing: are certificates not obsolete? The answer today is: no, but only because there isn't something better that is widely supported. I think if there was an alternative, we would all jump ship and never look back at the cluster fuck that certificates are.

So yeah, for now, I hope you can automate it all, but I share your sentiment about certificates and look forward to something better, whatever and whenever that may be...

[-]

Centimane@reddit

Certificates aren't that complicated. A lot of people lack the fundamentals of what they are and how to use them, but are forced to manage them anyway, I think that's where a lot of the frustration comes from.

Certs are basically just a one-way hash of a private text file. The holder of the private file is the only one who can perform that hash, and you trust they are who they say they are as a result. (this is a simplified explanation)

Certificate authorities are just someone you trust to check someone out before the certificate is handed out.

The trouble is you can't revoke certificates effectively, and there have been attacks in the past that compromised private keys, so then that attacker could effectively impersonate someone else. Maybe a way to do that would be to force you to contact the CA when you consume a cert to check if it's still valid, but that would slow down all HTTPS traffic noticeably. Storing the "trust" locally is better for performance.

[-]

Iriguchi@reddit

The main issue for me is that they are not newbie friendly. I have, for the tasks I'm responsible for never been able to request a cert, download it and just click install or import. Every freaking system either needs them in a different format, needs a different order for the chain, needs you to implement weird names and so on.

So every new appliance/application you always need to trial and error because the vendor documentation is awful when it's not just a simple webserver.

And don't even talk about java keystores.

I think part of the reason for these changes is it will pressure everything so hard to conform to the norms.

Things that don't conform are annoying but manageable with the once per year frequency. But with 47 days you will conform or you will be dead to the internet.

[-]

TheFluffiestRedditor@reddit

I implemented my first CA/PKI system in 2004. It was a complex nightmare back then, and honestly it's only got a little better since then. Certificates themselves are not complicated but the PKI system is, and it's very easy to get things wrong if you don't understand it. I've met very few people who truly understand PKI. Very not enough people.

[-]

zero_cool09@reddit

Do you think the industry may eventually move to certs expiring within a week or day even? Since our industry seems to continually become faster paced, especially with AI/bots being able to accelerate this. It leads me to thinking, what stops certifications from going this way.

[-]

Centimane@reddit

I wouldn't be surprised. The shorter the lifespan, the less impactful shortening it is.

The 47 days is already "too short not to automate". On that premise everyone will be heavily pressured to automate cert renewal. The issue I could see with shortening it further would be the load on the CAs - they're already going to see a big uptick in traffic when people have to renew certs nearly 10 times more frequently. Going from 47 to 1 would be almost 50 times more traffic for the CAs, and they'd probably struggle to keep up.

[-]

The unilateral trust method is an issue.

Surely we would be better off with long lived certs that incorporate a form of cert pinning.

Oh ha, I thought you were talking about remote apps.

If you are talking about Entra app proxy you will need to use the Graph API.

You could also choose to issue a certificate from your own PKI with as long of a lifespan as you want, apply it to the app proxy, and use GPO/Intune to push the cert out to your endpoints as trusted.

[-]

skipITjob@reddit

Thanks. I'll have to check how to get the certificates applied via graph API.

We are working on using Ansible* to automate SSL cert management for this very reason.

or whatever configuration management tooling you use here.

[-]

HJForsythe@reddit (OP)

Yeah, for me the point isn't really how long does it take to copy one file and then restart whatever daemon. It's more about how it's a huge problem and that huge problem isn't being solved by expiring the certificates faster.

[-]

BarracudaDefiant4702@reddit

I don't see many that answered your question about certbot with other cert providers.
Yes , certbot can work with other cert providers. We use it with https://zerossl.com/ in addition to letsencrypt. It's not free, and we have more certs under letsencrypt because it tended to be more reliable last time we had an incident but we have our automation setup that we can easily switch the source per domain and the price doesn't have a limit of 90 day certs and can also do 1 year certs but we don't make use of that. Letsencypt has generally been reliable, but we have over 350 certs and don't want to be dependent on something that critical without a backup plan and there has been a few cases of letsencypt being down or rate limiting...

[-]

Zero_SSL@reddit

Would you like to share with us, why you are using Certbot configured with ZeroSSL, and not acme.sh or other 3rd party clients?

[-]

BarracudaDefiant4702@reddit

Did the setup over 5 years ago and it still works, and certbot was setup years before that for letsencrypt. Was easiest to modify our call to certbot with --eab-kid ... --eab-hmac-key and --server and keep everything else 100% the same then to look at something else.

[-]

dakruhm@reddit

If internal PKI, the limits do not apply.

If external, cloudflare. Takes 5 minutes. See you in 15 years.

[-]

remember_this_guy@reddit

Expect alot of jobs poping up on indeed with titles like senior Cert Admin or SSL admin, what a day

[-]

Ok-Measurement-1575@reddit

I suspect it will get a lot shorter than 49 days at some point.

[-]

HJForsythe@reddit (OP)

sweet

[-]

buthidae@reddit

Yes 100%

[-]

TCB13sQuotes@reddit

My point is that if the technology is already proven to be inadequate

This is plain wrong. Millions of certificates are renewed by let’s encrypt, zero ssl and some other providers with that technology and with works perfectly fine.

If we want to get real the lifetime of a SSL cert today is 12 minutes.

it was obvious 10 years ago ¯\_(ツ)_/¯

[-]

retro_grave@reddit

FWIW, ACME spec was defined ~12 years ago [1] and I think the client is at least 10 years old.

Totally with you.

And even worse, when a hacker gets on your system, instead of getting 1 cert that’s good for 1 year, they get the login from your cert renewal script that allows them to make as many certs as they want until you notice and change it.

[-]

HJForsythe@reddit (OP)

I didnt even think of that.

[-]

ItsNotGoingToBeEasy@reddit

SSL was about to go unfunded in…2012? That company I worked for did a diving catch with Red Hat I think. The thought of all SSL going dark because everyone assumed someone else was paying the guy in his basement was kind of fascinating. /hij

Yeah, honestly certbot sucks. It's bloated and unreliable in my experience, usually trying to update itself and failing when renewing a cert.

acme.sh is the way to go.

[-]

Zero_SSL@reddit

Any features you like the most on acme.sh ?

[-]

Frothyleet@reddit

My problem with certbot is that the maintainers desperately want it to be a "it just works" kind of tool - you go to the website and it's like "here, select these dropdowns for what you need to use it for!". And in implementation, for specific use cases, it will "just work" if they've built the scripting for it into Certbot.

Benefit of the doubt, that's helpful for novices whose use cases luckily fall into the Certbot pre-designed scenario.

But for me, a more ~~advanced~~ intermediate user, it made things more confusing. It was a pain in the ass to even find the documentation (on the main certbot website, it's buried at the bottom - or otherwise you have to click through its little wizard saying "I'm doing something different").

Didn't help that I'm not super *nix savvy, but once I finally got there I found the syntax info I needed for the challenge (syntax for using DNS and the Cloudflare API) and the logic for actual certificate installation (understanding deploy hooks).

[-]

Zero_SSL@reddit

Thanks for the mention.

You are absolutely right that automation is the key. We are currently in a transition phase. While many CAs, including us, still offer commercial plans that cover up to a year, certificates themselves are capped at a maximum lifetime of 200 days since March. That means at least one renewal is required to span the full period.

Starting next year, this becomes much more relevant. With 90‑day certificates expected to be enforced globally, manual processes simply stop being practical. At that point, the operational cost and risk of manual renewals is far higher than investing in proper automation.

In practice, you are looking at roughly 5–7 renewals per year, depending on how much safety buffer you want to maintain.

For anyone interested in the background, here is a detailed explanation of the 200‑day certificate lifetime and what is changing: https://help.zerossl.com/hc/en-us/articles/34330849350173-SSL-TLS-Certificate-Validity-Changes-New-200-Day-Limit-Explained

[-]

BOT_Solutions@reddit

Honestly, I think people are talking past each other on this. I can automate certificate renewal, that is not the issue. The issue is whether forcing ever shorter expiry windows is actually good engineering or just pushing more operational churn onto everyone else. If your security model depends on turning a routine task into a permanent treadmill, that does deserve criticism.

As for Certbot, I would not think of it as only a LetsEncrypt thing, but it is definitely most associated with that world. The real question is whether the CA supports ACME and how cleanly they support it. If they do, then automation is realistic. If they do not, then vendors telling people to just use Certbot feels a bit like waving at the problem from across the room.

[-]

When it comes to automating certificates, ACME is ACME. Doesn't matter if the CA is Lets Encrypt or anyone else. What's a supported or out of the box configuration for a given tool is another matter, though.

I am also very cynical about this change. There's certainly such a thing as a compromised certificate, and certainly such a thing as an unavailable CRL, but these factors are being blown up beyond any reasonable assessment to justify a change that's actually about keeping the money train rolling.

Regardless, it is happening. The 3 month period is already basically unworkable for manual certificate management and there's nothing anyone can do about it except automate. Yay.

[-]

cyh555@reddit

SSL certificates need to expire every 49 days

[-]

gehzumteufel@reddit

FWIW the 398 to 47 has some steps in there too. It's 200 days as of March 15th for certs issued March 15th and later. Next year on the same date it goes to 100. And in 2029 it goes to 47.

[-]

FloridaIsTooDamnHot@reddit

This response needs some major love. This is the most salient point I’ve read about the certificate life changes.

[-]

uptimefordays@reddit

Thanks!

[-]

elatllat@reddit

If a particular piece of software doesn’t support [automation]

Automate it anyway with something like SikuliX

[-]

Stonewalled9999@reddit

Have clients with 10 year self signed for RDS GW. And I kinda like it as a domain joined PC gets the cert via GPO and a non agency PC, gets SSL warnings and gets booted out.

[-]

koolmon10@reddit

Yes but none of this requires the cert to have a 10 year expiry. You could just as easily make it 30 or 90 days and it would be the same. Domain joined would still get the cert via GPO every time it is rotated, and non-domain still get booted.

[-]

Stonewalled9999@reddit

we do 10 years because no, its not automated and my client doesn't like hiring me to to do stuff properly so I do it their way

[-]

koolmon10@reddit

client doesn't like hiring me to to do stuff properly

For one thing, you don’t have to follow that rule

I think this is actually unlikely to be viable. The browser organizations (Apple, Google, etc.) are actually the ones who were lobbying for this.

OPs post makes this seem like it was a decision by some random asshole. It wasn't, it was voted on by the consortium that sets the standards for SSL internationally.

[-]

Opposite_Bag_7434@reddit

Yea this really is stupid

[-]

Witty-Culture-5978@reddit

Yea pain in the ass

[-]

chris-itg@reddit

If the technology itself is inadequate then change the technology itself.

I think if you meant to swap out process for technology. It’s 2026, certificate automation is something your team should have implemented years ago, the technology isn’t broken the manual process is.

schrombomb_@reddit

We're moving to zero trust. That's just the way it's going. This is really only for public sites, browsers are gonna know if a certificate is signed by a private ca and will not apply these restrictions to those certificates. It doesn't make me want to retire because I've already had any public facing sites automated for 10 years now.

[-]

PaleoSpeedwagon@reddit

Don't suppose you have a reference you're using? stares mournfully at field of public sites

[-]

flerchin@reddit

Do you want curl -k everywhere? That's how you get curl -k everywhere. Stop breaking ssl people!

[-]

PaleoSpeedwagon@reddit

Also, ants.

gif

[-]

No_Resolution_9252@reddit

The tech has been out there to automate it a long time. The fast rotation solves the issue of checking revocation lists that keep getting larger and larger and the complexity of things like implementing OCSP. In practice, too many apps just never check revocation status and revoked certs could be used for years.

Some things can't be automated, and it's going to be very frustrating....

The slow decrease down to 47 days will help force devs to react, but until then it's gonna be annoying for the 1% of things that can't yet be automated.

[-]

S3xyflanders@reddit

I’m hoping someone sees this—apologies for the long post.

I’m a Network Engineer, and for whatever reason, our team owns the certificate lifecycle. That means we’re responsible when other teams don’t rotate their certs on time. This originated from a former coworker who centralized everything around NetScalers, and even though they’ve been gone for a while, the responsibility stuck—now it’s mine.

Our current internal CA is managed by another team and is frankly a mess. I understand the basics (issuing certs for things like RDP to avoid warnings), but I’m not deeply experienced with ADCS and I'm afraid if I try digging into it, it now becomes my responsibility

Right now we’re juggling three vendors: GoDaddy, DigiCert, and Sectigo. We manage about 90 certs, mostly wildcards. The process is inconsistent—GoDaddy supports auto-renewal, but Sectigo requires reordering with a new CSR, which is frustrating.

Our workflow is manual: download the cert, convert it to PFX, upload to NetScaler and Azure Key Vault, and let pipelines handle Azure deployments. The actual work is quick—10 minutes or so—but gathering certs, passwords, and coordinating everything takes most of the time.

Long term, I’d like to rebuild our internal PKI and limit external certs to public-facing services. Right now, we’re overusing external certs because our internal CA environment isn’t in good shape and no one wants to own it.

Has anyone implemented something like Venafi? I’m interested in moving toward a self-service model where developers can generate their own certs, with integrations into NetScaler, Palo Alto, etc.

Well they're a non-profit, so if they were going to rug-pull and start trying to make money they'd have a hard time. They are sponsored by the EFF, Linux Foundation, University of Michigan, and then grants from Mozilla, Cisco, Facebook, Google, and AWS.

They are very well funded at this point and have done a lot of technical work lately to increase their efficiency so that they can handle significant increases in usage without having to scale up their infrastructure. I would not be worried that they are going to start charging

[-]

bitslammer@reddit

HJForsythe@reddit (OP)

I think cPanel widely uses letsencrypt doesn't it? So isn't that already in theory automated? I don't know about RD gateways because luckily I haven't encountered that.

[-]

shokam_scene@reddit

There is an autossl plugin but that's not reliable wherein it will renew ok a few times but fails randomly which is why we pivoted to 1 year certs via namecheap. Namecheap ssl manager plugin fails to install as its shared hosting and we dont have root. Hosting support is clueless and trying to push another solution costing 10$ p.m.

[-]

I hope one day it’s real, but for now it’s still vaporware

[-]

tha_passi@reddit

From that very blog:

Staging rollout is planned for late Q1 2026, with a production rollout targeted for some time in Q2 2026.

Also see https://github.com/certbot/certbot/issues/10549#issuecomment-3929824817:

we're aiming to release Certbot support for DNS-PERSIST-01 in conjunction with Let's Encrypt's rollout!

[-]

pixel_of_moral_decay@reddit

Duke Nukem forever was targeting the early 90’s.

[-]

tha_passi@reddit

Sure ok. Luckily this is about LE, and so far they've had a pretty good track record of staying on schedule.

[-]

Cyhawk@reddit

Most DNS providers for example don’t have ACL’s granular enough for just certbot validation.

True. This is when you need to write up a business proposal that your current DNS provider doesn't match evolving business needs and lay out exactly why using the current provider is costing X amount of man hours every week and why switching to say Cloudflare is a better choice, saves money and saves time and potential future cyberattacks by having fast and easy access to their anti-ddos platform and so on.

We don't always have to do things the hardware. You just have to justify the changes in a way that a business guy can understand.

[-]

Frothyleet@reddit

Most DNS providers for example don’t have ACL’s granular enough for just certbot validation.

Well, OK - that's solvable by using a provider who offers modern features. I don't like Cloudflare's overwhelming market share, but it's hard to say no to very robust functionality that's also free.

Compromise the host, and you have the API key to control DNS of the victim, and that’s been a problem for years now.

Sure, if your infrastructure gets owned, you've got a problem. That's always gonna be the case.

In this situation, you have to treat that API key as Tier 0 - that means in a proper setup, it's not being stored on anything facing the internet (like, you don't need Certbot running on your actual webservers), and even behind your DMZ there are all sorts of just-in-time PAM solutions to let your scripts retrieve sensitive secrets.

The workaround is having monitors for any DNS changes to alert you to changes you didn’t want.

Well, yeah. That's just good practice period - your MDR should be watching your DNS.

Genuinely not throwing shade at you, I know how SMB life is, and many things that suck in our environments are not by our choice.

However, this and other complaints largely boil down to "it's a pain in the ass that we have to make our infrastructure better align with industry best practices" (see also: M365 basic auth deprecation).

[-]

pixel_of_moral_decay@reddit

The problem is one compromised host should never compromise your entire domain.

And most DNS providers simply have come to the conclusion that it’s not their problem.

[-]

Frothyleet@reddit

The problem is one compromised host should never compromise your entire domain.

I mean, that's the status quo for a massive amount of infrastructure. Like anyone using on prem AD.

But like I said, it is not a difficult endeavor to layer your sensitive secrets - like DNS API keys - behind multiple layers of security, such that even a compromise of the host that is running your ACME scripts doesn't expose the key.

And most DNS providers simply have come to the conclusion that it’s not their problem.

OK, I guess? Just... use the ones that don't suck? Again, Cloudflare is literally free for this functionality. And it, and other good DNS providers, are cheap even if you need to pay for them.

I know that migrating nameservers can have varying levels of complexity depending on the scale and functionality of your environment. But 9 times out of 10 it boils down to "export zone file. Import zone file. Update NS records with registrar". Not a huge undertaking.

[-]

MairusuPawa@reddit

Certbot is fine, but judging by the comments in this thread, the humans simply aren't.

[-]

Metalfreak82@reddit

Yes, this is what I expect too. And because it has been over a year ago that you set it up, you first have to dive into how it worked again... And always this stuff happens at the wrong time.

[-]

wtathfulburrito@reddit

Happens all the time. “It’s on a task that hasn’t failed in a year, I didn’t know it was broken til today”.

[-]

lynsix@reddit

All CA’s will be introducing ACME challenges for renewals. You can use other tools such as Azure KeyVault for example supports DigiCert and can be used to help replace old certs and manage access to them.

This is ultimately a good thing. Initial headache for some but massive time saver in the end.

The biggest problem is going to be bad software with archaic ways to replace certs, or ones that can only be done by vendor support teams.

[-]

stromos@reddit

Ding ding ding the automation is a breeze for normal stuff Cloudflare can automate sites by itself. It’s the crap like appliances and legacy software that makes it a nightmare. Then even worse vendor controlled.

[-]

GreatGreenGobbo@reddit

I'm an application level PM. I did not know this was some global standard.

Last year I had a few projects impacted because our DEV env certificates would expire and it wasn't on EMs radar. Somehow it was supposedly on the software dev team to know and keep it updated.

[-]

Frothyleet@reddit

Somehow it was supposedly on the software dev team to know and keep it updated

I mean, setting aside the reality that so many developers have no idea how PKI works...

Why wouldn't it be on the software devs to know how the certificates in their environment work?

[-]

GreatGreenGobbo@reddit

Project based, not in house devs large corporate insurance provider. We don't own the envs just given them. This 100% needs to be on Env Management/Middleware. We're there to code, test and deploy.

[-]

Direct-Expert-4824@reddit

Looking forward to having to deal with the fallout from compromised certificate automation solutions. /s

[-]

robreddity@reddit

Puts a ton of power into the hands of the CAs.

[-]

im-feeling-the-AGI@reddit

I’m working on a tool specifically for this issue. It’s free.

certctl - Self-hosted certificate lifecycle automation platform. Any CA, any server, zero human intervention. Full REST API, web dashboard, and agent-based deployment where private keys never leave your infrastructure.

https://github.com/shankar0123/certctl

[-]

ferrybig@reddit

Can certbot automatically renew certificates from other CAs than LetsEncrypt?

Let's encrypt documented their standard as ACME: https://en.wikipedia.org/wiki/Automatic_Certificate_Management_Environment

There are 2 certificate providers I know that work with this:

Zero Tier
Let's encrypt

[-]

chris-itg@reddit

There are tons of providers that support this with certbit via different methods not just zero tier or let’s encrypt. I’ve done cloudflare, sectigo, google domains (prior to the sell), Amazon just to name a few. Read the docs.

[-]

c_pardue@reddit

op you keep mentioning in replies that "this doesn't even solve the underlying issue" but i don't think you give a single F about the underlying issue, you are just annoyed as hell at having to cope with this latest travesty of random changes.

yeah we get it, it sucks.
some of us don't care, some of us now will just have to fix it, and some of us have no input other than pointlessly complaining.

i am with you in your camp, pointlessly complaining. honestly i don't think this will even solve the underlying issue so what's the point (ie. please somehow don't make me deal with it)???!!!

[-]

Only_Worldliness3870@reddit

My problem with some of the automation is DNS providers that don't have an API to update the record to be able to do automatic renewals. Or the ones that have an API but a long time to propagate the new information. My current DNS provider you have to manually add the records, and they say it can take 24/48 hours. Most of the client servers that I manage are automated and have been, but they are not doing the DNS validation. They are using http validation.

[-]

Frothyleet@reddit

Cloudflare is literally free. Export your zone, import your zone, update your NS records, gratz

I mean I'm being a little facetious but if your problem is "my DNS provider sucks", switch to one that doesn't. It's not like it's a money problem, they're all cheap if not free in the first place.

[-]

daschu117@reddit

You can CNAME the acme challenge record to a separate domain that does have a better API. That way the actual A/MX/NS/CNAME records you care about stay with whatever DNS provider you're currently using, but then the specific TXT records for the DNS-01 domain validation can point elsewhere. That secondary domain is just for TXT records and has no actual control over anything else. It can also be hosted on any other DNS provider, not necessarily the same one your main domain is on.

My favorite method is running a service to create per-domain credentials on a secondary domain that I own. This also abstracts my DNS-01 automation away so that I can change my main provider without having to change all of my certificate automation credentials.

https://github.com/acme-dns/acme-dns

[-]

Only_Worldliness3870@reddit

Thank you will have to check that out.

[-]

DDS-PBS@reddit

"I'd rather just retire than learn how to automate things"

[-]

Normal_Choice9322@reddit

Automations don't magically last forever with no interaction required

[-]

FloridaIsTooDamnHot@reddit

This is a fairly ridiculous statement. Nothing in tech lasts forever with no interaction required.

In fact life doesn’t last forever with no interaction required.

[-]

Normal_Choice9322@reddit

I automated a year ago and now they are getting rid of the product so I get to do it all over again

[-]

What do you mean so what?

So you have monitoring, in the unlikely event your simple script to rotate the cert fails you have plenty of time before it expires to resolve the errors.

This is bread and butter stuff

[-]

Normal_Choice9322@reddit

Monitoring does not fix the problem that can occur across many servers every month

[-]

streetmagix@reddit

[-]

Spokezzy@reddit

Sure but the card that you use to pay for them probably has an expiry right? So eventually there comes a time where you do have to manually intervene when you are notified of that?

throwawayPzaFm@reddit

Then they're allocating manpower to replacing certificates. Feel free to get a better job if you have the skills to do something else.

[-]

Moontoya@reddit

I'm a senior engineer at an msp with 30 years under my belt

I'm still supporting server 2012r2 all over the place and hardware even older than that , entirely because the client can't or won't upgrade.

Your thinking is monopolar

[-]

throwawayPzaFm@reddit

Is it? Are you not allocating budget to manually supporting broken down old crap?

Seems to me like you agree with me more than disagree.

[-]

Moontoya@reddit

_I_ am not allocating shit to any budget

Im the fix this shit guy, not the owner or management of several dozens of companies in the SMB (small-med Business, not the share type)

Lots of FREE tools for doing it ? Cos if theres a cost at all, it wont fly with the money people.

I deal with a LOT of cassandrean behaviour, I can tell them the truth all day long, warn them of problems, tell them they need to spend money - and they wont/cant hear it or think Im lying or trying to generate a sale.

My point is - theres a lot of crud out there still in use that automation isnt a quick / easy / smart or cheap option for - which is very different to saying automation is useless.

[-]

throwawayPzaFm@reddit

Lots of FREE tools for doing it ?

Well maybe not lots but it's still very doable. posh-acme for instance seems to work, though I've escaped that particular level of hell for now so can't guarantee it.

[-]

Moontoya@reddit

Being hamstrung by the money people is one of the reasons automation isn't as easy as it should be

HJForsythe@reddit (OP)

The concept is pointless. If SSL certificates are so poorly thought out that they must be rotated every 49 days then they should be done away with entirely. Just making them expire faster isn't solving a problem. So you just automating bullshit isn't a solution.

[-]

oxidizingremnant@reddit

I think you’re missing the forest for the trees here.

TLS encryption is important but previous methods to invalidate improper/invalid certificates (such as OCSP and CRLs) just didn’t work. So rather than relying on broken tech, the solution is to just revoke certificates faster.

The creep toward shorter certificate periods has been coming for at least a decade, so honestly if you’re dealing with legacy tech that doesn’t support certificate automation at this point then don’t get mad at W3C. You should get mad at whoever keeps buying legacy stuff that hasn’t been keeping up with decades-old technology.

[-]

WDWKamala@reddit

This is a very valid and uncomfortable point.

pbrutsche@reddit

If you're in an organization that needs NSX or NSX-T, Proxmox is a half assed feature deficient toy and an absolute non-starter

VMware is more than virtualization

[-]

Xzenor@reddit

Why do you think it is inadequate? It's absolutely not.

[-]

secesh@reddit

random group of folks? you mean the makers of web browsers and certificate authorities?

I'll trust the industry leaders and experts over some random curmudgeon. Let's Encrypt launched in 2014. This writing has been on the wall for over a decade.

[-]

Fun_Structure3965@reddit

this, you have all the experts on the pro side for this and all the people who don't understand certificates at all on the contra side.

not so random...

following the ballot discussion on github was exhausting.

[-]

Dax420@reddit

If the experts think shorter expiry is better why stop at 49 days? Why not 4 days, why not 4 hours?

The whole architecture is wrong and they are trying to fix it with a bandaid. People complaining are the people who will have to deal with the mess and the "experts" who sell certificates for a living get to sell more certificates.

[-]

Frothyleet@reddit

"experts" who sell certificates for a living get to sell more certificates.

The organizations who charge people for SSL certificates are actually on the losing end of all this, because almost all of their customers are people who are manually messing with certificates because of their stunted skillsets.

For the set of people who are forced to learn some basic certificate automation, they're also probably going to start asking themselves why they're paying for certificates.

[-]

Fun_Structure3965@reddit

thats called "practicality" and no, there aren't only CAs in the cab

[-]

Spicy_Poo@reddit

I'll trust the industry leaders and experts over some random curmudgeon.

Like Symantec.

[-]

DueBreadfruit2638@reddit

This is a non-issue for me. Implemented simple-acme years ago and haven't worried about SSL/TLS certs since.

[-]

Flabbergasted98@reddit

We can't have have late stage capitalism with naysayers like you around.
Keep talking like that and they'll replace you with AI.

[-]

Cyhawk@reddit

Keep talking like that and they'll replace you with AI.

Funnily enough, this type of task is something agentic AI tools can do really, really well.

[-]

HJForsythe@reddit (OP)

Dont threaten me with a good time.

[-]

pabskamai@reddit

Hugh, jokes on them :( In Our erp you have to manually install the cert….

[-]

Are you a dinosaur?

[-]

jefmes@reddit

I do think I'm getting a bit scaly, hmmm

[-]

strawzy@reddit

VoodooKing@reddit

I'm from Singapore. I certainly took some time to think about renewing my contract. This 49 day SSL thing was not the only reason that drove me, it was many other reasons too, the demands of the customer (government), the demands of my company, after hours and weekend maintenance. I'm really grateful for the knowledge I have gained in the 25+ years I have been in IT. Many of the younger admins ask me for help and advice which I'm always happy to impart.

Currently I have another source of income coming in that matches what I'm making so I can actually retire but I don't want to get bored.

I'm going to take a few months break to just recuperate and spend time with my nephew and niece.

I'm exploring a few options,

1) Train station worker :- Basically sitting in a glass booth and helping passengers with issues tapping out of the gate and any other tasks related to smooth running of the train station.

2) Part time 7-11 employee

3) Part time Subway employee

4) Private Hire Vehicle driver (Similar to Uber)

[-]

uptimefordays@reddit

I think this is a fundamental misunderstanding of what went down--companies insisted, for years, that CRLs couldn't be enforced because generating new certs and revoking compromised ones was too hard. So the industry said "well fine, we'll just decrease validity periods" which was a reasonable approach.

[-]

FostWare@reddit

But it’s the same CAs that skimped on protecting their CRL (and OCSP to a lesser extent until long lived caching became the new SOP) service from DDoS resulting in people’s browsing going slow, or just straight timing out.

[-]

uptimefordays@reddit

But it’s the same CAs that skimped on protecting their CRL (and OCSP to a lesser extent until long lived caching became the new SOP) service from DDoS resulting in people’s browsing going slow, or just straight timing out.

That's a real failure, but it's a separate one—CAs under-investing in OCSP/CRL infrastructure and cert holders failing to actually submit revocations are two distinct problems. Revocation broke for layered reasons: CA infrastructure was unreliable, holders dragged their feet on submitting requests, and browsers eventually soft-failed on timeout just to keep things moving—which gutted the security value entirely. Nobody's hands are clean, but that doesn't contradict the original point about why short validity periods became the forcing function.

[-]

ecnahc515@reddit

To be fair, shorter expirations also means the CRLs don't need to contain entries for as long which should help with that, but also there is going to be some increase just due to more frequent renewals so it's not necessarily a huge win.

[-]

Tutorbin76@reddit

Just wait until these CA's start demanding payment per renewal, which is likely the real objective here.

[-]

Stryker1-1@reddit

For the low monthly fee or X you can continue renewing your certs

Okay dude but my entire point was that if the whole idea of certificates is so stupid that they cannot be trusted for more than 47 days then fix that.

[-]

Riist138@reddit

The problem isn't due to certificates being "stupid"...they're one of the best ways we have to ensure data has not been altered in transit. The change has much more to do with a rapidly evolving threat landscape,, and the longer certs stay active, the higher the risk is of compromised keys, persistence of misused certs, outdated cryptography, orphaned and forgotten certs (often used in impersonation attacks). Old certificates also facilitate AITM and Downgrade attacks, attackers can force fallback to insecure protocols (such as TLS 1.0/1.1) or weak cipher suites, exposing data to interception.

[-]

VTi-R@reddit

Explain how you will prevent misconfigurations by admins who invariably seem to claim they're super smart yet end up having the same compromised password everywhere because "no-one could ever guess it so I'll reset it to the same thing every month rather than change it"?

Include a discussion on how you'll prevent any private key from being copied by root (on a Linux) or Administrator on Windows (hint: the exportable flag is an absolute nothing for security).

[-]

protogenxl@reddit

the SAP BASIS team is reconsidering their practices.......

[-]

Disastrous_Meal_4982@reddit

As someone who was a cert admin responsible for hundreds of thousands of certs and an engineer responsible for deploying them, I pushed for 30 day certs for years. There were private keys floating around that were valid for a decade when I took over. We are now at a year with admins having to validate their certs are valid every 90 days or they get revoked.

[-]

wrootlt@reddit

As i am reading Let's Encrypt blog how they are designing systems to cope with huge numbers of certs/checks/renewals i just wonder when it will inevitably crumble and drive the world into darkness. It doesn't seem that current approach and technology is sustainable. Billions or trillions of certificates relying on a single entity. That is not what Internet is supposed to be. But it seems Let's Encrypt is trying to monopolize this thing.

[-]

You are missing the other half of this, we are going to be required to validate our domain every 30 days with cert vendors also. DigiCert is already out in force peddling thier DNS solution they just bought that can automate it.

[-]

Geekenstein@reddit

Much like passwords, if you make this painful with constant changes, people will work around it in a way that’s much less safe.

[-]

suburbanplankton@reddit

I'm not worried in the least.

We have a whole team that's currently devoted to automating certificate renewals, and I'm not on it! :P

[-]

newked@reddit

I am hoping for daily replaces, modern http routers have no issue with this, legacy infrastructure has.

[-]

greenFox99@reddit

Have a look at ACME. I think it is implemented in hashicorp vault. Your certificates can get renewed automatically using cert bot, however you need to configure what server to use.

[-]

Shot-Bag-9219@reddit

yeap! e.g., https://infisical.com/docs/documentation/platform/pki/ca/acme-ca

[-]

ayeshrajans@reddit

It's not some random group of folks. It's the CA/B forum, which is perry much THE group that decides all certificate rules, just like every other rule before this.

There is a newer DNS verification method proposed that you can do manually and it will remain verified as long as you do not change DNS (I crudely simplified this), so you only have to automate the certificate renewal and not necessarily the verification part.

Hackers love this one trick!

axonxorz@reddit

If the system is not public facing on the internet then use an internal cert signed by your internal CA for 365 days just like you have been doing.

If you're doing it internally, there's no broad restrictions on cert validity.

47 days only applies to certs in the public trust chain:

These Requirements do not address the issuance, or management of Certificates by enterprises that operate their own Public Key Infrastructure for internal purposes only, and for which the Root Certificate is not distributed by any Application Software Supplier.

There are ACME providers for every modern CA I’ve ever worked with. And frankly if you think this is a bad idea, you should retire. You’re far too out of the loop on the WHY this change is necessary.

The world doesn’t need dinosaurs like you holding back actual, real security progress.

[-]

iamabdullah@reddit

OP, you're overreacting and behaving like a dinosaur. It wasn't decided on by a bunch of random people.

ACME has been available since ~2017. Almost all major cert providers support it.

[-]

800oz_gorilla@reddit

They weren't random folks, sectigo was a major backer for this and I absolutely gave the rep some s*** about it.

I won't be renewing with them

[-]

mixduptransistor@reddit

Well, it wasn't just some random group of folks it was the CA/Browser Forum which is literally made up of both Certificate Authorities and browser vendors. Second, if in the Year of Our Lord 2026 you can't automate certificates on your services and devices, or at the very least put a reverse proxy in front of legacy devices that are hard or impossible to automate, my Brother in Christ maybe it IS time for you to retire

[-]

sembee2@reddit

No. It was Apple. They made the CA forum do it because they were going to do it anywaym.

[-]

mixduptransistor@reddit

Fair, the 47 day ballot was specifically an Apple proposal but others, including Google, were pushing a 90 day limit but Google supported Apple's proposal. Apple is also on the forum as a browser vendor, not a certificate vendor, so my original point is still valid, the people who pushed it do not have a financial interest in selling more certificates

Everything related to SMTP validation is done in TXT records in DNS. right?

So why can't SSL revocation just use the same process? lol

[-]

mtgguy999@reddit

For having access to a comprised cert be useful the attacker still needs to man in the middle your connection. That means when you do a dns query to get the txt record of compromised certs list the attacker can return whatever info they want and not include the compromised cert they are using. If the attacker couldn’t influence the dns queries or ip routing they couldn’t make you connect their there server instead of the real one in the first place. which is the whole thing point having a cert to prove the server is owned by the site you are connecting to and not an attacker.

[-]

tesselaterator@reddit

It’s not as easy as that. No smtp encryption is not done with txt records. Listen to this security now episode. SG explains how Mozilla fixed checking for revoked certs

https://twit.tv/posts/transcripts/security-now-989-transcript

[-]

uber_poutine@reddit

Fyi, this is a thing, it just hasn't really taken off yet: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities

[-]

Gives ya time to counter the Omer! Ha! 49 days is an interesting coincidence right after Passover.

[-]

spin81@reddit

If the technology itself is inadequate then change the technology itself.

The tech isn't the issue. From a tech standpoint, the certificates could be 3 days or 10,000 days.

They're doing this for two reasons: the least important one is that it incentivizes automation, but the most important one is that if your certificate gets compromised, it will only be compromised for 47 days at most.

The person who told you there is a technological limitation that makes so they have to be 47 days doesn't know what they're talking about. I wouldn't believe a word that comes out of the person's mouth that said that.

My point wasn't that I am unable or unwilling to automate things.

And yet you're acting like you've got some kind of problem.

Can certbot automatically renew certificates from other CAs than LetsEncrypt?

Yes. It's called ACME if you want to Google the underlying principles or to find alternatives to Certbot, because Certbot is just an ACME client which they made it so it's extremely easy to use with Let's Encrypt.

If your CA supports EAB, your server doesn't have to be reachable from the internet and you don't have to fiddle with DNS automation. I'll leave the actual research to you, but in a nutshell EAB means you get (basically - not quite but basically) a username and password and a server to talk to, and it's all web requests going out.

I'm doing research and it sounds like on the certbot page that it only works with LetsEncyrpt

It does look like that. I agree that this is confusing. There are other ACME clients too, just google "ACME clients" and you'll find a whole bunch.

[-]

SortaIT@reddit

I would like to retire and I'm nowhere near retiring age :P

There are certificate lifecycle management tools already available that can handle this for you and make things way easier. Sectigo, Apviewx, Venafi to name a few.

[-]

Shot-Bag-9219@reddit

Infisical is open source too: infisical.com

[-]

mb194dc@reddit

Yes it's completely moronic, like most other technical stuff in this era...

[-]

tidderwork@reddit

Can certbot automatically renew certificates from other CAs than LetsEncrypt?

Yes, easily.

https://eff-certbot.readthedocs.io/en/stable/using.html#changing-the-acme-server

I thought months ago you couldn’t get certs that lasted longer, but I realized not too long ago that Amazon generated a year-long certificate for my site.

You can auto-renew certs with cert bot, yes, and it’s essentially fully automatic, assuming the CA supports ACME, which nearly everyone does.

"I would rather retire than purchase something to fix a major problem I have".

There are a boatload of products that can automate your certs. Even F5s, Kemp load balancers, Java Key Stores, etc. If you don't want to do it yourself, there are many solutions available.

[-]

retornam@reddit

Certificate renewal can be automated. If certificate vendors don’t provide tools for this, you can write your own code to automate the process.

[-]

clbw@reddit

You can automate cert renewals many ways using cert issuer agent if they have one,I have not seen one that does not have the option of using acme or an API script. Where I work the certs we automated are renewed every 30 days. I fully believe cert renewal will become a 1 day renewal at some point.

[-]

puffybaba@reddit

[-]

HJForsythe@reddit (OP)

What in the actual fuck does what you're saying have to do with anything?

[-]

lazyhustlermusic@reddit

Clearly that you have no idea what you’re complaining about, but you’ve made that very apparent yourself.

But sure the only world that exists for certificates are herp derp users ignoring browser warnings.

[-]

HJForsythe@reddit (OP)

I guess what you are saying is that you've allowed the private key for your APIs that you run to be stolen at least enough times for this to be an issue for you?

[-]

lazyhustlermusic@reddit

lol someone doesn’t understand PKI

[-]

HJForsythe@reddit (OP)

Cool I'm glad you commented.

[-]

lazyhustlermusic@reddit

Kind of oddly hostile still, must be the dunning Kruger still kicking in. Juniors always form hard opinions about things they don’t really understand.

We’re doing this with digicert atm. Using an ACME client (not certbot, can’t remember which), and it’s going alright. We refresh at 30d, 19d for handling issues.

[-]

ancientstephanie@reddit

If the technology itself is inadequate then change the technology itself.

CA/Browser forum, which is composed of the major browser vendors and the widely recognized CAs, got together and decided that an adequate technology solution for certificate revocation not only doesn't exist, but fundamentally can't coexist with the necessary privacy, availability, and reliability guarantees. Everything to date, even Mozilla's CRLite, which came about after this was in motion, is a stopgap.

That was the main factor in this - certificate revocation sucks for everyone involved, and both CAs and Browsers want to be done with it. OCSP has to phone home. CRLs get too big. And and failed dissemination of revocation information, whether through OCSP, traditional CRLs, Chrome CRLsets, or Mozilla CRlite, is a soft fail.

The other big factor here ... is 100% about being able to change the technology itself, and about being able to kill off some of those legacy systems, at 49 day speeds. When we eventually have another major algorithm or protocol vulnerability discovered, or some breakthrough in quantum computing threatens multiple algorithms at once, the shorter renewal cycle can be used to rapidly sunset the vulnerable algorithms or protocol.

[-]

SirLoremIpsum@reddit

Anyone read this 49 day SSL expiration thing and think they would rather just retire?

I think that's overly dramatic.

Automate it. If it cant be automated replace it / upgrade it.

If you have an up to date tech stack and implement it properly you will have zero issues and be in a better place operationally and security wise.

What's to hate?

My point wasn't that I am unable or unwilling to automate things.

When they expired annually we simply just replaced them anytime they were coming up for expiration because it isn't a giant deal to do that once a year honestly. It takes like 4 seconds per cert.

Now that it's shortening which doesn't actually solve the underlying issue with the certs so it's pointless anyway we are trying to wrangle all of them into certbot or whatever but it's still not going to fix the problems that SSL certificates don't actually work as it stands right now.

[-]

flunky_the_majestic@reddit

“Rather just retire” is a little extreme. But yeah, it’s annoying and pointless.

[-]

ledow@reddit

In convenience, maybe.

In security, no.

Almost like there's a trade-off that is universally applicable there, eh?

[-]

Kraeftluder@reddit

In security, no.

The only thing this solves is that browsers are too dumb to implement standards properly. There was no problem in the wild with longer duration certificates. "They could be expired" is something that even goes for a 1 day valid certificate that was minted an hour ago.

This secures nothing and helps no one.

[-]

ledow@reddit

Securing nothing is not the same as "two steps back" - that would imply this is LESS secure. We could discuss whether it's MORE secure, but that's not the argument.

It's NO LESS secure than it ever was, so it's not a step back in terms of security.

Convenience, maybe, but not security.

[-]

Kraeftluder@reddit

Securing nothing

Who's talking about securing nothing?

that would imply this is LESS secure

What reply did you read?

It's NO LESS secure than it ever was, so it's not a step back in terms of security.

Let me reformulate; This makes nothing MORE secure than it already was.

[-]

ledow@reddit

"This secures nothing". Literally in the post I replied to.

What reply did YOU read?

[-]

Kraeftluder@reddit

Do you understand language? "This" refers to "this measure" as we were discussing it holy shitballs.

[-]

TheFluffiestRedditor@reddit

I'm starting to feel like the whole CA system is flawed. Far too few people understand how PKI works (it is complex), and everything is now dependent on it being configured correctly, and operating properly. Rotating certificates like this is just layering band aids on top of each other.

[-]

radicldreamer@reddit

Ugh, cryptonerds.

https://xkcd.com/538/

[-]

Antique_Grapefruit_5@reddit

Agreed. This is absolutely stupid. Fix the technology first...

[-]

Civil_Inspection579@reddit

Yeah, it’s frustrating but the shorter expiry is about reducing risk if a cert is compromised. Automation (like Certbot + ACME) is basically the industry’s answer now, whether we like it or not.

[-]

I have to do this eventually too. Are we essentially installing "agents" to renew certs on every machine?

[-]

smartguy_x@reddit

Totally get the frustration. Even if you automate renewals, 45 to 49 day certs create a real visibility problem, especially across internal servers and mixed environments.

That is why tools that focus on expiry tracking still matter. If you already have AppViewX, something like Tokentimer (tokentimer.ch) could still be useful as a lightweight way to keep cert, token, and secret expirations visible in one place without adding more PKI overhead.

[-]

Able-Ambassador-921@reddit

What problem is this solving?

[-]

kombiwombi@reddit

The basic problem is that revoking a compromised certificate has always been a bolted-on hack, and now even that is not fit for purpose.

So this time they are dropping the certificate lifetime to what the group issuing certificates thinks is a reasonable cap to the time a compromised certificate can be exploited.

Of course, it's not reasonable at all. But it is cheaper than building a scalable revocation infrastructure, so the certificate issuers are all for it.

[-]

Able-Ambassador-921@reddit

I c. Thank you for explaining. Seems like such a waste of resources for something that should be automated within the security process itself.

First you ratchet down the lifetime (in the name of security! Nevermind that the problem of revocation has already been solved).

Second, once everyone is dependent on automation, you extend the paid services with features that the free tiers can't.

Finally, you undermine or eliminate the free services (LE is primarily funded by the big tech companies)

I know, I am a paranoid old person. But I see the pattern by now.

Don't get me started on the whole "you don't trust me to keep my private keys safe" bull crap.

[-]

Adda717@reddit

My team is currently in the process of building out Keyfactor into our environment.

[-]

aon9492@reddit

Dreading it.

If anyone has had any success managing things this way for ADFS STS domains please hit me up.

[-]

dts-five@reddit

[-]

KillerKellerjr@reddit

You are suppose to automate the process of renewal. You're making this out to be a bigger deal than you need to. Any guide you follow will walk you though automating the renewal process via a cron job. It's nice never having to worry about the semi-manual process of renewing a cert. Even Chat GPT will walk you through the process on whatever OS you are using. I used it on all of our internal servers and have never looked back.

[-]

alyssa_at_chronicle@reddit

u/HJForsythe

gif

[-]

markth_wi@reddit

Absolutely, but there are a few problems here.

Firstly , it's moments like this when you realize Sneakers isn't just some old film, it's required watching, it's not like we hadn't seen this coming.

More plainly

We haven't automated this , which is a fair criticism, I roll hard on the Eisenhower principle so this is one of those 5 minutes once every year so it stays unautomated, if :I'm doing it every 60 days or every week than I'm going to automate.
Key vulnerability - the other less spoken of concern we've gotten a bit comfortable so it's incumbent we keep ourselves in play technologically, or other nations will absolutely be happy to take up being secure while we wonder why things go sideways. So we adopt methods of PQC whether it is settled to some sort of lattice math or some combination of high bit Elliptic Curve 25519 type standards no doubt these too will become vulnerable over time.

Even with these later developments, while these systems appear to be the most resistant to the sort of very easy decryption efforts we must expect to see as quantum cryptographic chips and/or GPU like devices become more prevalent making decryption near real time.

There is also the question of the use of LLM's lean into this trouble as well, because of the fact that we're at or near the cutting edge , in the next six months to 2 years the commercial/practical edge is going to end up being just a couple of years away from the publicly available edge of known mathematics.

One of the most powerful features of LLM's is the ability to explore the sometimes seemingly impractical gaps between discovery/innovation A and discovery/innovation B, so the "gap" isn't just one of distance from where we are practicing engineering commercially and the cutting edge of applied mathematics , it's the semi-automated, perhaps even completely automated low-rent research that might stumble into a Riemann loophole and close the gap between "hard to break" and "trivial to break".

To my mind and to OP's point, this provides a claustrophillia we must become comfortable with. This absolutely wants to make me want to retire, but I also understand this is as much my fight as someone else's, there's an uncomfortable moment when you're doing this job when you look around and realize "you're it" , you're the person everyone else is depending on.

People like to say it's a privledge but the fact is, it's a responsibility.

Of course our media champions every ego that prances around pronouncing themselves that "smartest guy in the room" , almost certainly that's not the guy you need to worry about, and it's a call on everyone else to get serious , carve out time and put some of that much lauded grey-matter to work. Of course German linguistics has a word for this, sitzfleisch , sit your ass down and do the job.

It seems it's a question of how do we like our civilization served up, with all the conveniences of interconnected , remote trade or do we find ourselves in some reduced circumstance, or we have some sort of cryptographic Pearl Harbor, 9/11 type day when we find out shits been compromised all around for a while and we spend ruinous amounts of time-money and effort scrambling back to square one.

And it won't be that cool, it will simply be some "and treasury bills in 14 nation-states went belly up for XYZ reasons...." , who needs that headache.

[-]

oldmilwaukie@reddit

It’s increased my job security by several years so I’ll take it.

[-]

Metalfreak82@reddit

I feel the same. I have automated most of it now, but there are still some systems that don't support that or I don't have the permission to do this.

Tarcanus@reddit

I've just been fighting with my available time versus 3rd party products.

I don't have the time to whip up a system with open-source solutions, so I need to rely on the company's purse, but now it's finding time to configure the vendor product.

I've basically thrown up my hands to my supervisor, telling them I don't have the time to dig in and do it right, so I'll use whatever product you want me to as long as a decision is made before 2027.

However you do research, that’s what you want to improve.

[-]

Akeshi@reddit

is probably the craziest thing that has happened to technology in the past 20 years

User1539@reddit

Yeah, there's some kind of weirdness with snap installs of docker not seeing symlinks quite right, so I have to manually do a little dance to get some of my reverse proxies to see the new certs.

Obviously, I can either just re-build the server, or write a separate script.

But, meh ... is this really fixing anything?

[-]

Z3r0C0o@reddit

This is to force the government into cloud automation services, I'm willing to bet on it

[-]

gex80@reddit

Honestly, it's not that big of a deal and anyone one forward thinking would've seen this coming. This is where movies and reality start aligning more. Frequent rotation in movies was one of the things that made "hacking" hard.

We are eventually going to get to a point where it's going to be closer to PKI for websites.

[-]

Ramorous@reddit

ACME, EST... Many options available.

We subscribed to AppViewX to perform certificate lifecycle management. Using their PKI now and have internal servers using it for named host certificates expiring/renewing every 45 days.

Man-e-questions@reddit

The ironic thing is its getting harder and harder to brute force a modern certificate. Its like a bank having a safe that takes 10 years to crack but they throw it away and buy a new one every month.

[-]

hammertime2009@reddit

I don’t think it’s just because of brute forcing certs. It’s if they become stolen by other means such as vulnerabilities.

[-]

Man-e-questions@reddit

Doesn’t really make sense though. If they don’t have the private key, they can “steal” the certificate and put it on their own server. Lets assume they can spoof DNS or whatever to send your traffic to their servers. Your browser STILL won’t trust the cert since the private key isn’t installed.

[-]

_mick_s@reddit

'just change it's... Why do you think it didn't go straight to 49 days but to 1 year, 200 days, 100 days first?

Even this change was too much to do outright.

[-]

v00d00ley@reddit

https://bugzilla.mozilla.org/show_bug.cgi?id=647959 oldie but goldie, about how to join the trusted root certificate authority cartel

You mean you didn't just deploy LetsEncrypt YEARS ago when the opportunity came along to have perfectly-acceptable SSL certificates for free by doing almost nothing?

No, that's really not cause for me to "just retire".

I walked into my last workplace, deployed LetsEncrypt, saved about £200-300 a year (a tiny, tiny drip in the ocean of other IT expenses) and haven't thought about it since in the 3 years hence.

When that 49-day thing comes in? Oh no. I'll have to... do nothing at all, whatsoever. The certs I get from LE will just be shorter length, and every day the ACME renewal tools will continue to check if any are near expiry and automatically renew them for me.

I'll admit that i have one or two systems that I still manually install certs for (need to find time to automate them), but it's been standard practice to automate certificate installation for a LONG time. There's almost no scenario where you can't use a tool or script to let your devices/servers just get their own fresh certs monthly.

[-]