SSL certificate lifetimes are going down. Dates proposed. 45 days by 2027.

[-]

mikerbiker@reddit

Internal servers need some love.

In order to provision certs for internal purposes, DNS validation is necessary. However, I don't want to put API keys to control my DNS zone on every server.

Therefore, there needs to be a widely-implemented way to offload DNS validation to a centralized server. The internal servers should only have credentials to provision exactly the certificate that they need.

To my knowledge, the only currently-developed open source projects that do this are certwarden and Netflix's lemur.

Certwarden is an individual's part-time project, and lemur requires a lot of setup. Kubernetes has the generically-named cert-manager, but it's heavily tied to kubernetes and not easily used outside kubernetes.

[-]

webprofusor@reddit

There's a few other options, at https://certifytheweb.com/ we provide a service called Certify DNS, which is an acme-dns compatible CNAME delegation service for those that don't want to run their own acme-dns linux server. If you want DNS challenge centralization we are also developing Certify Management Server which will also provide an API for this that other ACME clients can use, so you don't need privilege credentials on individual servers etc. I've not heard of any other product doing that. Our stuff is available as a mix of open source, source available and proprietary.

[-]

PlannedObsolescence_@reddit

for internal purposes

If you are doing widespread certificate deployment internally, definitely think about running an internal CA - and deploying your root(s) via your configuration management solution (AD GPO, MDM, Ansible etc).

If you have a specific reason to use a public CA, and are using ACME - you can always just CNAME your acme-challange records to a new public DNS zone for that project, and make a service account that can only edit that zone. Then your blast radius for a (DNS API) credential compromise is just certs issued for that project.

[-]

HappyVlane@reddit

If you are doing widespread certificate deployment internally, definitely think about running an internal CA - and deploying your root(s) via your configuration management solution (AD GPO, MDM, Ansible etc).

This will suck. My least favorite vendor manages something like 10 websites for us, and we have to provide the certs manually every time. Between live and test this is gonna suck.

In many cases, it's not about the app developer or system administrator. In my case, we rely on certificates generated by a DoD entity. Unfortunately, the only way to generate them is to submit a CSR to the application AFTER I've already logged in with my own PKI certificate. While I can sit and hope they update the capability to allow for some automation, it's not presently here. That's true for customers of some other CAs as well.

You're saying that your org manages root certs but you cannot respond to a compromise or disclosure by invalidating and rotating them within a business-critical amount of time?

Can use OpenSSL on Windows, too.

Yeah, trust me, it is a source of endless frustration for me, and probably why I end up being "the guy" in a lot of situations. I take time and put in effort to learn new stuff, and they seem content with their current base of knowledge and actively try to remain in their own silo.

[-]

davy_crockett_slayer@reddit

Oh, you can absolutely use OpenSSL on Windows, I just don't like it. I'm a big fan of using native tools for the problem. OpenSSL (in my opinion) is great for everything but Windows. With Windows, you can use a request.ini file to do everything for you. It's great.

[-]

Maybe if it was a different set of coworkers. The ones I have show zero interest in learning. Besides which, the platforms where certs are applied are almost exclusively in my portfolio. For those which are not, I'm called on to obtain them. Every single time I have to walk them through the process of generating the CSR, then provide them the cert and tell them where it has to go, and what other steps need to be taken to install it into whatever application. I just had a long fight trying to get someone to understand the concept of a Common Name. He refused to give me temporary admin access to the appliance interface to generate the request, and instead kept providing me ones with the incorrect CN, or with an IP as the CN. It took four tries before he finally got me a request with the proper CN, and even then he had an incorrect SAN in there. I would have done it all for him, but the thought of trying to talk him through importing the key made me want to curl up into the fetal position.

[-]

Darkk_Knight@reddit

On pfsense I use HAProxy for that.

[-]

No-Honey8906@reddit

Im curious to hear what you think about eMudhra. As they are kind of disrupting the CA market right now. They have their CLM built into their whole UI.

[-]

Reverent@reddit

Have you heard of our lord and saviour caddy?

Stable, efficient, dead simple to configure. Wack it on an edge appliance or DMZ VPN and away you go. Most server configurations take 1-2 lines.

[-]

Brufar_308@reddit

Thanks. Adding this to the list of solutions to investigate

[-]

Mike22april@reddit

Doesnt the full automation with ACME only work with webcomponent servers? You would need DNS automation for any non-webserver, right?

[-]

Longjumping_Gap_9325@reddit

It all depends. Sectigo uses Organizational Validation, so as long as the domain is validated to be used in Sectigo via the DCV process, you're good to go as long as the domain is in your ACME enrollment end point (you can create multiple "account" endpoints)

This works for RFC1918 systems too if you don't want or have the infra setup for a private CA (and lack of ACME I assume most of those options have?)

Works great, BUT even 1 year DCVs as they are now absolutely BLOWS as a large org and I wish there was some sort of automated way to handle that as well

[-]

VexingRaven@reddit

You don't need to have a web component to use it, but you do need to be able to run a web server specifically for the purposes of renewing certificates. That web server can host just the ACME challenge if you want. Or you can use DNS challenge, which is what I do because IMO it's just so much better and easier.

[-]

Tetha@reddit

To be specific, the HTTP challenge works for single-domain, public web reachable, HTTP / HTTPS servers. (iirc, LE validation accepts invalid TLS certs so you can automate the setup of a server by starting up with self-signed certs first and rotating to LE-Signed certs after first challenge).

Wildcards, and things not using HTTPs? need the DNS challenge.

If you are worried that the DNS challenge opens big permissions into your DNS infrastructure, you can use aliases. So if you have a DNS setup supporting it, you can setup control for acme for records in "*.oh-no-if-you-see-this-in-a-mail-call-tetha.company.example" and CNAME the acme challenges over there. This way you can sandbox these DNS challenges if your setup allows that.

Or you can just delegate this particular zone to a provider supporting automation via acme and point CNAMES there and keep control over everything else statically.

[-]

Brufar_308@reddit

looks like I responded out of thread when the person I responded to was talking about more info on using a load balancer to resolve the issue when acme isn’t an option.

One Can get lost in these long threads at times.

[-]

No-Honey8906@reddit

All you need to know, don't use the big names right now. Theres a disrupter in the CA market called eMudhra. They will sweep the floor for issuing certs in the next 5-10 years. They have all the necessary tools to combat the crap thats ahead.

[-]

*F5/Citrix enters the chat*

I hear you need a bigger load balancer.

Yeah, appliance vendors need to get off their asses and build support for automated certs.

[-]

DarthPneumono@reddit

can't be automated

Can I ask why/how?

[-]

Nu11u5@reddit

Devices with web consoles can be automated but would need something like Selenium.

[-]

DarthPneumono@reddit

Well, yeah, that's my point. Tools exist to automate web applications too, including plain curl.

[-]

gonewild9676@reddit

I have certs on customer systems that run our software but we don't control. The only way to automate an update is to get admin rights on their systems, which we don't want.

A once every 11 months fire drill is enough.

[-]

KittensInc@reddit

A once every 11 months fire drill is enough.

If it is properly automated, it isn't a fire drill. It's a non-event, happening quietly in the background. Just like, say, log rotation or backups.

The only way to automate an update is to get admin rights on their systems, which we don't want.

Orrrr, you add a "rotate-cert" CLI command to your software, so that the admins deploying your software can automate it for you. Alternatively, integrate it with something like LetsEncrypt so it can provision its own certificate: this is absolutely trivial for services who expose a web server to the open internet, and can also be done fairly easily if your DNS provider has an API your software can hook into.

Other software is already doing this. You have to think in terms of possible solutions, not go looking for reasons why it is impossible.

[-]

gonewild9676@reddit

Some of them have IT staffs that do automate it. Others are small mom and pop type shops that have to be manually walked through it. It is down to either a manual "check for updates" call while logged in as an admin or a pushed app that does the update. But getting admin rights for some people is like pulling teeth. I could have a windows service that logs in as an administrator do the update, but that's a security issue as well, plus it has to be updated if they change the admin password.

Either way, there is zero benefit for this change. We used to have 2 year certs.

Very skeptical it can't be automated, unless you have to load the certs from like a USB drive lol

[-]

PlannedObsolescence_@reddit

load the certs from like a USB drive

Now that sounds like a challange :)

I bet it's doable to automate with a networked KVM that allows you to 'connect' a virtual disk image as a flash drive.

[-]

Merakel@reddit

If it's networked it's doable haha. I run a team of automation engineers whose spend all day automating things people have said can't be automated.

[-]

khobbits@reddit

I think the point here is that there is quite a long adoption time here.
If this rule get's approved most vendors will have time to get their shit in order.

That said, if you've got a lot of legacy apps, that will realistically not see software updates, you can probably just click through the warning.

Personally, I have never put a valid SSL certificate on a server IDRAC. I'm happy to just click through the insecure warning every time.

[-]

Reverent@reddit

Also there's plenty of ways to handle this situation.

Just keep using self signed internally, as long as you understand the implications
Have an automation system that collects public certs and distributes them internally
Use a private CA. That's free to do, minus the astronomical tech cliff that learning how to run a CA requires.

[-]

NebraskaCoder@reddit

A private CA is going to have the same limitations as a public one. They usually enforce the restrictions in the browsers.

[-]

Seth0x7DD@reddit

I don't think the adoption time will be that long. Apple essentially enforced the reduction of the time previously. It is big enough that a push from their end will bring movement.

There are ways to mitigate that but in the end, if browsers enforce a 45 day limit you will have to setup your stuff to work for endusers.

[-]

throw0101a@reddit

I think the point here is that there is quite a long adoption time here.

Not really? We're towards the end of 2024, and they want to do this in 2027, which is kind of three years away but really more like two.

[-]

theadj123@reddit

vCenter stores certificates in some database/registry kind of way

There are multiple ways to deploy certs to/through vCenter (including making it a subordinate CA in your existing PKI, which is what many people do) and it can 100% be automated end-to-end.

Any platform that generates a CSR that you must use for the cert issuance (which vCenter is one of) due to keeping the private key is more than a 1 step 'dump a cert on the file system' process. Just because you have to pull a CSR out doesn't mean it can't be automated.

other systems might use that or similar approach and again ssh is available but certificate update-wise is useless.

One of the many use cases for a LB/WAF, put that in front with the 'real' cert and leave a dummy cert on the device that can't be managed.

[-]

xCharg@reddit

There are multiple ways to deploy certs to/through vCenter

I know, but that's beside the point. vCenter is just an example of a system that ticks both boxes:

certs stored not in a text file format
product known to pretty much everyone here

One of the many use cases for a LB/WAF

You know certificates aren't a web-exclusive technology right?

[-]

theadj123@reddit

I know, but that's beside the point, if you read it further.

No, that was exactly the point - if you read further in my reply. vCenter is a common example of a system that holds onto the CSR for signing purposes, which is a common thing done by many popular systems that have an interactive setup out of the box. Most of them can be automated, and all the popular ones I've used have been. Dell OME is another common example I've dealt with that is solved in the same way. There are like examples of systems that don't let you automate this, but your example isn't one of them.

You know certificates aren't a web-exclusive technology right?

Try being less condescending. You can run many protocols through the either of those, not just HTTP rendering. I have unencrypted 514 syslog traffic that is terminated on F5s, many devices don't do anything but 514 UDP for syslog. From the F5 out to anything else reading the logs its encrypted TLS traffic with certs on the F5 and the devices are none the wiser about it.

[-]

xCharg@reddit

but your example isn't one of them.

It literally is and I provided example of one such system twice and you ignored it both times.

[-]

theadj123@reddit

vCenter has a REST API that includes commands for issuing and renewing certificates, how can that not be automated? I would know since I wrote an Ansible playbook automating this very thing using the Automation API. The certificate-manager is just one interface for cert management, it's not the only one and most major applications/platforms are similar. It's like saying "I cant automate Windows PKI because I don't have options in the MMC to do " when certutil or powershell exist.

https://developer.broadcom.com/xapis/vsphere-automation-api/latest/vcenter/certificate_management-vcenter/

It literally is and I provided example of one such system twice and you ignored it both times.

I'm not ignoring your example, it's a bad example.

[-]

xCharg@reddit

What part of that are you not getting? https://i.imgur.com/WGUgxqR.png

[-]

theadj123@reddit

I get it just fine. vCenter uses its own keystore, no different than every major OS and all apps using something like jks that requires openssl to interact with a separate keystore from the OS. No app/device that requires using a locally generated CSR+key is going to let you copy/paste the cert text/file, and your provided example requires a CSR generated from the app itself. You can replace the certs on other vSphere components (Machine certs on vCenter or ESX, or the STS SSO cert on vCenter) directly via copy/paste as they don't require the key to be generated from the app/device themselves.

You also went on to say a few other related things :

certs aren't stored in a basic format, which is a text file => renders "accessible over ssh means can be managed" point not true

As described below, this is not true as you can manage it completely over SSH. Some certs are in the VECS keystore, others are flat files - /var/lib/vmware/vmca has certs/keys/crls in it for example, along with the VECS .db file.

I even provided example - got a software/appliance with a binary tool that only works interactively and is the only way to upload fresh cert and key. It also can not generate CSR but that doesn't matter in this context.

That is clearly incorrect, so which is it - you want to be able to copy/paste the cert or encrypted text or you think vCenter's cert management is a GUI/TUI only option? The former is rarely needed and the latter isn't true.

got a software/appliance with a binary tool that only works interactively

The 'binary tool' you mentioned is fact can be used non-interactively, via submitting a .CFG (this is the same method you use to interact with many CAs using an .INF) to generate a CSR, which you can retrieve via SSH to submit to a CA. You can submit the cert+csr back to cert-manager the same way, non-interactively. This can be done 100% with SSH/SCP and not require interaction at all.

This is also incorrect

is the only way to upload fresh cert and key

I've already shown the API method, which will let you do this entire process via CLI (which includes SSH and meets your initial requirement), but you can directly manipulate the cert store as well. You can SSH certs onto vCenter, you need to use the vecs-cli or dir-cli commands to actually load them into the cert store (VECS) so they're recognized. That's no different than using certutil/pwsh for Windows keystores or adding a cert to an application's jks or /etc/ssl on *NIX machines/appliances using openssl.

[-]

xCharg@reddit

Duh. I'm just going to assume you are trolling.

Twice I provided an example of a separate appliance which is not vCenter, multiple times I've clarified that vCenter was used as example of a system that doesn't store certs in plaintext only and that part only. The only relevant part about vCenter was the way it stores certificates - that part only and nothing else. Many times I've mentioned that I do know that vCenter can be automated and I'm talking about other system, which is not vCenter, and unlike vCenter can not be automated. No it does not deal with CSRs. It doesn't support them, it doesn't generate them, it doesn't accept them. At all. No it doesn't have REST API. Or any API. It just doesn't. Again, it's not vCenter - it's that other system I did not name because it's a niche software which is local to my region and no one here wouldn't know about hence I never provided it's name. But it is not vCenter ffs. And vCenter's certmanager was also used as an example of interactive tool that this other system, which is not vCenter, uses and unlike vCenter can not be automated. I really do hope this is clear enough this time around.

But all you keep seeing and replying about is "by muh vCenter can be automated"...

=\

[-]

theadj123@reddit

I'm not trolling at all, your response style is not well put together and is also pretty condescending. Have a great day!

[-]

PlannedObsolescence_@reddit

Wouldn't both those examples be best served by an internal certificate authority? I can't think of a reason for wanting a public CA cert on either of those.

If you run you own internal CA, which many businesses do - you set your own rules. Sure that also means you are at the whim of your own technical competence to run a secure CA, but that's the cost of having full control of your own internal certs.

Basically the entire world trusts any certificates that a publicly trusted CA issues. There is a good reason to have more strict requirements even if they increase the burden, there is a clear security benefit to rotating public certs more often, especially with the very difficult to solve problem that is certificate revocation checks (but there is an excellent effort here recently with CRLite).

[-]

wildcarde815@reddit

I can't think of a reason for wanting a public CA cert on either of those.

because then you don't have to configure subordinate machines to see the cert as valid, it's valid by nature.

[-]

PlannedObsolescence_@reddit

Sure, but if these are corporate managed computers (eg Active Directory, or MDM) - then rolling out trust for your internal CA's root certificate is a single policy, applying to your whole fleet?

If you don't have an internal CA - as the in-house experience isn't there etc, but you do want to have full control of your certificates, you can even purchase enterprise PKI from a lot of CAs. They run a CA for you, and give you integrations for issuance etc. You still need to trust the root CA across your fleet of course, but you can have whatever certificate validity period you want.

[-]

wildcarde815@reddit

Sure, but if these are corporate managed computers (eg Active Directory, or MDM) - then rolling out trust for your internal CA's root certificate is a single policy, applying to your whole fleet?

bold of you to assume access to that is granted to people outside central it. Tho I'm pretty sure they just don't have a pki configuration at all. and for myself we have to make things work with machines that aren't 100% managed, so the more transparent security is the better.

[-]

STiFTW@reddit

The problem is that browsers stop trusting certificates that exceed the (current) 13 months, and in the future 45 days. So while you can make internal CA issued certs that have longer expiration times, browsers will not trust them.

https://thehackernews.com/2020/09/ssl-tls-certificate-validity-398.html

[-]

DerpyMcWafflestomp@reddit

You might want to actually read the article you linked to try and prove your incorrect claim.

In a move that's meant to boost security, Apple, Google, and Mozilla are set to reject publicly rooted digital certificates in their respective web browsers that expire more than 13 months (or 398 days) from their creation date.

Certificates issued before the enforcement date won't be impacted, neither those that have been issued from user-added or administrator-added Root certificate authorities (CAs).

[-]

ChadTheLizardKing@reddit

iOS and MacOS both have a limit of 825 days or less for the validity period to trust any certificate. I expect other browser manufacturers to follow suit and implement similar soft caps.

https://support.apple.com/en-us/HT210176

[-]

STiFTW@reddit

I appreciate the correction, now I have something to go test today. While this should be fine for domain joined machines or an environment with a CA root certificate deployment, this would be still be problem for environments that are not able to push out trusted root CA to clients.

[-]

Crafty_Individual_47@reddit

No they won’t

[-]

PlannedObsolescence_@reddit

That article specifically says:

reject publicly rooted digital certificates

I have this on an old internal exchange that I have to keep alive.

Once every 90 days, open the port on the firewall, run win-acme, close the port. All to stop the self signed error on ECP should we ever have to use it.

Darkk_Knight@reddit

On Cloudflare I've setup the security token to only update the DNS records on certain domains. Also I make use of IP restrictions.

[-]

Model_M_Typist@reddit

I've been moving to this and it is great.

[-]

PlannedObsolescence_@reddit

So really you should be using an internal certificate authority, but I understand if you have very little requirements for on-premesis certificates you can get away without one. Just you are now at the whims of the global CA system rather than one you control.

Why not use dns-01 if you are using ACME?

If you have example.com, and run an internal DNS zone in your AD etc for ad.example.com. Then you make a public DNS zone for ad.example.com. It'll basically stay empty all the time - but when your ACME agent needs to verify domain ownership, it adds an ACME challenge record into that public zone then deletes it when done. No need to actually expose your internal systems to the internet.

Here's a list of plugins for certbot as an example. The only real concern, is that you need to take caution with the permissions you grant the new user for this purpose in your public DNS zone's authentication system. For example I use a policy in AWS IAM that restricts the certbot IAM user to only creating / deleting resource records in the one zone ad.example.com, and only from that known outbound IP. And because this zone is not actually used for any other systems, there's no real concern of a compromise. I also have alerts if a record is ever created that isn't 'acme-challenge' in the case of a credential compromise.

[-]

TotallyNotIT@reddit

WHOOPS DELETED

Problem goes away, join us at r/ShittySysadmin

[-]

purplemonkeymad@reddit

I thought win-acme suppored pre and post renew actions, you could automate the firewall part too.

[-]

Windows-Helper@reddit

If it is local only just use a Windows CA then?

[-]

newboofgootin@reddit

I've had win-acme running on dozens of servers for years. Works very well and if you know powershell you can make it work for almost anything.

[-]

Yeah this is my go-to and I’ve been quite happy with it

[-]

spokale@reddit

IIS can be automated

I'm using IIS central certificate stores, which in theory can pull .pfx certificates from a DFS replicated directory that gets populated from letsencrypt on the loadbalancer in front of them via SFTP. The issue is that IIS central certificates feature is quirky as hell and seemingly doesn't work at random.

[-]

SelfEnergy@reddit

People still use IIS?

[-]

mb194dc@reddit

Meanwhile how many breaches will this stop ?

Zero of course 😎

[-]

MandelbrotFace@reddit

100% this! It's like, show me the evidence of major incidents caused by certificate duration of 1 or even 2 years and that doing this will have a huge impact.

[-]

KittensInc@reddit

The risk isn't the duration, the risk is that many organizations are incapable of renewing their certificates during an incident.

There have definitely been compromised CAs before, such as Diginotar and Comodo for example. In those cases fraudulent certificates were issued for major websites like GMail, and in the Diginotar case it was discovered because someone was actively using them to MitM traffic! This is obviously really really bad.

Comodo was able to adequately respond to the incident, but Diginotar wasn't. Despite knowing about the incident they did not take any action to mitigate the fallout. Clearly Diginotar could not be trusted anymore, so their root certificate had to be revoked.

But Diginotar was primarily used by a national government to secure a lot of their core systems! Revoking them immediately would mean those people would be unable to pay taxes, register a new car, or do all the other things people use governments for. In this case the national government did the right thing: they sent out a press release that those websites could not be trusted anymore and should only be used when absolutely necessary, and worked tirelessly to immediately replace all certificates with ones from another CA. It took them three days. The very next day the Diginotar root certificates were removed from the first browsers.

Now imagine what would've happened if it was a more popular CA, whose certificates were used by banks, critical infrastructure, and Fortune 500 companies. Immediate revocation means those bank's customers can't buy groceries tomorrow, but not revoking the root cert means leaving every single website vulnerable to MitM attacks. If you're a CA and JPMorgan Chase is begging you to keep a hack secret and give them 30 days to renew, what do you do?

It's kind-of difficult to prove a misuse of certificate if the method of detecting that has not yet been implemented. Our other hope is OCSP Stapling, but there isn't enough interest in it.

[-]

MandelbrotFace@reddit

Tbh, I think the main risk is theft of private keys internally. Rotating keys more frequently helps with that but... Yeah ... I'd pick a different battle myself

[-]

narcissisadmin@reddit

Exactly. Recommend it if you like, but to force it? GTFO

[-]

This is why I like NIST. The guidance is practical and evidence based. It's why I adore their password rules -- Length is king, don't rotate passwords on an automatic cadence, it causes more problems than it solves.

[-]

altodor@reddit

But those rules are a small part of a complete security posture, not to be adopted in isolation.

[-]

petrichorax@reddit

They were not made in isolation. Make a strong case for scheduled password resets

[-]

altodor@reddit

NIST has ending scheduled rotations as the final bit of a comprehensive strategy. An organization needs (among other things) detection of account compromise, something checking a blacklist with each change or reset, and MFA in place everywhere the credential is used. If an organization doesn't have those in place first, the NIST recommendation to cease password rotations does not apply to them.

For the record, I'm not a fan of scheduled rotations and I'm not advocating for them to be used. But I see disabling rotations parroted on this sub all the time without the prerequisite work being mentioned.

[-]

petrichorax@reddit

If you don't have MFA already you're hopeless to begin with.

[-]

altodor@reddit

It most certainly is not. On-prem exchange, ADFS, anything using LDAP isn't forced MFA. I'm over here trying to kill those. Using Entra for auth can use MFA, but it's not forced and admins/orgs can disable it. They're stupid if they do disable it, but they can.

[-]

petrichorax@reddit

When I was a penetration tester, I never used breaches to find passwords, I'd just do '!' Fall2024!, and variations of that.

Those are the passwords you end up with littered all over your network if you do rotations.

And those can be guessed under the limits of your lockout policy.

Your take is a misrepresentation of NIST's position on the matter. They don't say you should do these things first and THEN fix your password policy, they say you should also do these things.

There is no reason to gate these things behind each other. Do them all, do them when you can, I know how hard it is being a sysadmin at a dinosaur show, I've lived it.

[-]

altodor@reddit

In NIST SP800-63-b section 5.1.1, the requirements for things like not having hints, rate limiting, and forced rotation if compromised, are all "shall". That's "follow strictly without deviation" as they define it. Disabling forced rotations is a "should not", that just means "discouraged" as they define it.

You're preaching to the choir on disabling rotations. Like, you don't need to convince me, I'm not over here going "no, fuck you, my users must rotate passwords forever because muh old school" but that seems to be what you're writing against (I am in fact, 2-3 apps away from my entire org being able to go completely MFA-based passwordless and never having to give a shit about my users' passwords again). I'm only saying the NIST docs do not start and end the story with "disable rotations", which seems to be all anyone ever remembers is in that doc, likely because they've never actually read it themselves.

[-]

petrichorax@reddit

Disabling forced rotations is a "should not", that just means "discouraged" as they define it.

Forced rotations is not the same thing as scheduled rotations, I think you're conflating these ideas, which is somewhat understandable because of the word 'rotation' which implies a periodicity.

Forced rotation on compromise = your password hash was found in a breach/leak, or we guessed it, change it

Scheduled rotations (aka password expiration)= change your password every X number of days

You should 100% be disabling password expirations no matter what.

Forced rotation on compromise should never be disabled.

I'm only saying the NIST docs do not start and end the story with "disable rotations", which seems to be all anyone ever remembers is in that doc

It comes up a lot, that and dumb password complexity requirements, because it generates a shitload of tickets. The other ones do not. They're also really annoying, and we love to bitch here.

Not much to talk about with the other password recommendations. But turning off password expiration is an immediate ticket reducer.

Also, here's something that might terrify you that you might not know. If you don't have a password manager for your employees, they are likely saving them in their outlook notes, which cannot accessed easily with powershell, cmd, or graph.

At one place I work on, I asked 15 users across the org in person, and all 15 were doing this, and they were all in finance.

--

Good job on gunning for passwordless, it's nice. Hope it catches on more.

[-]

altodor@reddit

Forced rotations is not the same thing as scheduled rotations, I think you're conflating these ideas, which is somewhat understandable because of the word 'rotation' which implies a periodicity.

I do not have the two concepts confused. It was incredibly late at night for me (pushing 2am) and unfortunately in my stupor I picked the wrong word to write (I tend to think of scheduled as "forced" and "compromise response" as "emergency" and forgot to filter that back out). Scheduled rotation is the "discouraged but not prohibited" one nestled in with a bunch of "required and do not deviate" so I tend to read it as "finish here after doing everything else".

I have no doubts my users are doing absolutely shitty things with passwords. I have most of the "shall" requirements implemented in there preventing the worst of the worst at least, and I don't hear from my help desk that anyone is complaining or struggling with any of it. I'm trying to gently nudge the boat in the right direction, not capsize it by dragging it too fast.

[-]

RedShift9@reddit

💯💯💯💯💯💯

[-]

anothergaijin@reddit

I feel like so much of modern security guidelines are based off of what is theoretically good practice rather than a practical analysis of the actual threat landscape.

Nobody is expecting RSA or EcDSA/EdDSA to be broken any time really soon. For those scenarios we have the newly standardized ML-KEM and its friends.

[-]

chicaneuk@reddit

Exactly why this pisses me off so much.

[-]

chase32@reddit

Doubt that is the purpose. More likely they want to get more of a lockdown of CAs and then have the ability to deny a new cert on a shorter timeline if they don't like your site.

[-]

lebean@reddit

All of our certs are automated so short lifetimes don't really affect us, but I'd still tend to agree with you that it's security theater. One or two year certs were totally fine.

[-]

2drawnonward5@reddit

I doubt it's about security. I think it's about pushing the tool chain so things work different. Nobody likes the classic methods either so they're at least moving away from manual.

Whether it'll be better than old school methods will depend on your needs.

[-]

steavor@reddit

Similar to "$AUDITOR said we need to disable TLS 1.0 and 1.1 immediately, it is DEPRECATED and a RED FLAG for them".

Well, if you can show me practical attacks on TLSv1.0/1.1, then sure, I might consider it. In the meantime I've got bigger fish to fry.

Heck, even SSL 3.0 (!) is vastly (and I do mean VASTLY) superior to "simply send the mail unencrypted" (opportunistic TLS for most SMTP speakers....). An attacker is not ever trying to decrypt in-transit data if he's got any chance to simply have Brian from Accounting click on a link in an email....

[-]

BuffaloRedshark@reddit

It might actually cause more due to people missing expiration or doing work arounds

[-]

[-]

Ansible32@reddit

Financial institutions have layers upon layers of security requirements. EV certs do actually include insurance. I'm not sure that insurance could ever pay out, but it is there and for like a bank it's really kind of chump change in the grand scheme of all the weird layers of insurance and security requirements. It's not just sales, I mean alongside the EV requirement they will also usually require that you store your TLS keys in an HSM, which seems a little excessive to me but it does serve a purpose.

[-]

pixel_of_moral_decay@reddit

There’s no rule requiring device manufacturers to only ship with certain CA’s hardcoded in their firmware. And no rule allowing certain CA’s to pay for that placement instead of certain free ones.

what are they worried for? stealing certificates?

drunkcowofdeath@reddit

Hell if we are automating this to prevent key cracking do it hourly. What difference does it make at this point?

[-]

Dday82@reddit

Next step is crypto encryption with algorithm update schedules.

[-]

Rare-Page4407@reddit

What difference does it make at this point?

tz/time skew before NTP fixes the clocks

[-]

Ansible32@reddit

Current quantum computers are utterly useless, and I would actually be surprised if there's a quantum computer that can crack a modern cert in less than a month. Maybe someday, but it's not something that urgent to worry about, and it might never happen.

[-]

narcissisadmin@reddit

Are there even quantum computers that can crack encryption at all?

[-]

Ansible32@reddit

No. What I meant to say is I will actually be a little surprised if anyone ever creates a quantum computer that can crack an 1024-bit RSA key, and I don't expect it to happen in the next 10 years in any event.

[-]

andrea_ci@reddit

as Proofs of Concepts, they can. In real life? meh...

but the companies that actually have access to those, have no problems using other means to do that

[-]

Ansible32@reddit

but the companies that actually have access to those, have no problems using other means to do that

The other means do not involve cracking keys. They just steal the keys which is why rotation is a useful thing to do, and worrying about improving the encryption is not.

There's no proof of concept for breaking any keys made with halfway decent crypto in the past 10 years. There probably won't be any such proof of concept for at least 10 years, not if you're following current best practices. If there is it won't be because of quantum computers.

[-]

andrea_ci@reddit

http://cjc.ict.ac.cn/online/onlinepaper/wc-202458160402.pdf

Only 22 bits, for now

[-]

CatDiaspora@reddit

A PDF provided by a .cn server? Nope.

[-]

narcissisadmin@reddit

Always always paste those links into https://archive.today

Last archived 20 hours ago: https://archive.today/Elyx8

[-]

andrea_ci@reddit

That's a pretty famous Chinese university...

[-]

CatDiaspora@reddit

I'm a pretty famous guy...

[-]

narcissisadmin@reddit

That's an interesting theory.

I wonder which will happen first...full scale quantum computing or a breakthrough in mathematics to quickly factor primes.

[-]

ACEDT@reddit

But isn't it a better idea to just use something like SHAKE? Computers will always get faster, and once quantum computers are practical they'll just get faster too. There's no real advantage to rotating certs more often when it's a solved problem cryptographically.

[-]

mobani@reddit

You still have to be able to hijack the traffic. Doesn't matter if I have a quantum computer at home, if i cannot get a copy of your traffic.

[-]

MrShlash@reddit

Isn’t traffic encrypted with a symmetric session key that is generated during the TLS handshake? How would that be useful in cracking the certificate?

[-]

mobani@reddit

At the moment a quantum algorithm, (can't remember its name) can reduce the security level of symmetric key encryption by half. For example, AES-128 would have its security reduced to an effective key size of 64 bits, making it vulnerable to brute-force attacks. Still AES-256 is hard, but it's a matter of time.

slippery@reddit

In January 1999, distributed.net and the Electronic Frontier Foundation collaborated to publicly break a DES key in 22 hours and 15 minutes. ZERO quantum computing.

I can't think of one notable thing quantum computing has done yet.

[-]

No, ML-KEM and SHAKE (and similar) are a solution against quantum computing related threats. Shorter lifetimes are not addressing cryptographic issues. It's basically all about mismanagement - theft, misissuance, poor automation.

[-]

Appoxo@reddit

DOesnt matter. Save the data for cracking later. Now what? Ask the adversary every 30 days to delete your unrequested backups? /s

[-]

Tai9ch@reddit

45 day ssl certs is one way to reduce that risk.

No.

That's just a demonstration of mathematical incompetence that should get anyone who suggests it removed from these committees.

[-]

SoonerMedic72@reddit

This is funny. When you are the 3 biggest tech companies in a "not allowed to fail" sector, you don't care about rules or customer needs. You just tell them that sounds like a professional services request and give a quote that you know they can't afford.

[-]

plupien@reddit

Ugh... We need more built in ACME with Paid options. Free certs don't fly at many organizations.

[-]

durkzilla@reddit

Venafi can provide ACME enrollment of certificates from the CA of your choosing.

Disclaimer: former Venafi employee

[-]

plupien@reddit

Yes, but on Firewalls, VPN devices etc.

[-]

durkzilla@reddit

The client needs to support ACME. If it doesn't, Venafi can serve up certificates using SCEP, NDES, EST, or the device's own API if the manufacturer had the foresight to include certificate management in their API.

[-]

Mike22april@reddit

So uhm, how exactly is SCEP different from NDES? And which network devices obtain server certs using EST protocol?

[-]

durkzilla@reddit

SCEP is Cisco, NDES is Microsoft. Some minor differences in authentication methods.

Because every other day the CAs add another entry to bugzilla about how they missed a revocation deadline because their Very Important Customers say they can’t possibly replace their certs in less than three months.

If processes are done right it could be 5 hours and not be an issue. That's kind of the point. People NEED a kick in the ass to fix their process first.

[-]

kevin_k@reddit

If processes are done right

... but they're not always done right, are they? The more frequently certs need to be replaced, the greater the likelihood that something - even something out of our hands - will fail, bringing potential critical communications down.

[-]

gsmitheidw1@reddit

It's a game of cat and mouse of Moores law style gains in compute for hackers versus stronger encryption.

Bigger keys means more data per transaction which means more latency and slower websites etc.

Maybe things like elliptical curve can lead to smaller keys. But I think SSL needs to be replaced entirely with something else. The fundamental design needs to improve.

[-]

kevin_k@reddit

I still haven't heard of any instances of commercial SSL certs being broken.

[-]

gsmitheidw1@reddit

No, that would be front page news if it was a big thing.

Design needs to change because it's fiddly and time consuming. Man in the middle attacks are not as much of an issue anymore. The weak points are the clients and the services ends.

Everything is switched networks now. It's not as easy to sniff traffic as it used to be. Nobody running web proxies etc anymore.

I'm not saying we should go back to plain text, but the game has moved on.

[-]

fudgemeister@reddit

I'm still fighting to get certs in place at all. If this passes, that just means I'll be fighting expired certs and no certs. I run into enough cases where I get calls because the end customer forgot about a cert...

Apple has been doing its absolute best to make me hate everything about them. The ARP change was one thing but this is just a wild grab. Google too if they're pushing it.

[-]

dustojnikhummer@reddit

So 60 minute certificates by 2035?

[-]

_BoNgRiPPeR_420@reddit

Don't joke, this is already a thing with Intune and Microsoft AlwaysOn VPN. Mind you, not public certs, but it issues your PC a 1-hour cert for login purposes.

[-]

What exactly is the goal here? This sounds like its just going to add more load and complication to systems providing the certs. To what end? What is the goal/purpose? Is jacking certs that big of a problem?

[-]

CAs don’t make money off of that. Also legacy devices probably shouldn’t be directly exposed to the public internet anyways. You only really need a publicly trusted certificate for a service that will be exposed on the public internet.

[-]

ExcitingTabletop@reddit

Sigh. Yes, CA's tend to charge for certs. No, they don't currently charge for re-issue during the year long period.

I see you don't work with legacy devices or industrial equipment. We don't expose to the general public internet. But we don't run our own fiber from our plant to Germany or Japan either. We whitelist who can access what, and further secure it. Including with things like... certs.

And lastly no, some of us need to encrypt traffic between the server and client even locally. Yes, you can do self-signed local CA, if the equipment supports it. Which it doesn't always.

[-]

0xmerp@reddit

I still don’t understand why you wouldn’t just use Let’s Encrypt if you absolutely needed a publicly trusted certificate for some reason. It’s possible to use the ACME client without it automatically installing the certificate for you. The expensive certificate you buy from a commercial CA will have to be replaced every 45 days too. The only difference is one is free and one is not.

We generally have a VPN for the use case you described, it is not just exposed to the public internet, and we don’t want random stranger from outside of our company connecting to the control interfaces of our equipment. If your business own all of the endpoints that might connect to this industrial equipment, you should be able to install both a VPN client and your own root certificate.

[-]

ExcitingTabletop@reddit

Because 1) Let's Encrypt doesn't or at least didn't support the cert requirements we needed at the time, 2) the equipment often doesn't support ACME , 3) the equipment doesn't always let you add your own local CA and 4) we don't get to dictate remote access to our vendors.

We're not stupid, you know. I'm not sure if that's what you're intending to imply, but that is how it is coming across.

You should consider that it's possible that industrial automation IT is often both competent and faced with real world limitations.

Often, the equipment is built by a very narrow number of companies. You don't dictate terms to them anymore than you do to Microsoft or Apple. And it's what the business needs to make widgets, that's what we have to buy.

[-]

That was old job. But we did essentially that for some stuff. For other stuff, we had to comply with the manufacturer's system.

Basically so that we could sue them if they fucked up or killed anyone. To put in perspective, if the equipment seriously went bad, it could kill a couple hundred folks. I did the math on the potential damage, and it was ugly. The only saving grace is we built the facilities specifically away from populations.

The highest priority was making sure that didn't happen, at least IT wise. Next was making sure if it did happen, it wasn't our fault. And making sure we could sue the vendor to recover. The prices they charged us reflected that liability. So making sure the vendor could see the equipment and had perfect access in the manner they demanded was a high priority. And then we had to build our security onion around that. Whitelisting, SD-WAN, MFA, etc etc.

[-]

mrmacedonian@reddit

So I've never dealt with anything that could directly cause any harm to life. Certainly delay/loss of service can cause harm, esp. w/ healthcare clients, but nothing like you're talking about.

I did have a situation where I had to integrate a vendor that similarly needed a high degree of access into their equipment and it was a liability issue for the client. The client's use was physical/local control and some through vendor's servers anyway, so my recommendation to put them on their own WAN and enough firewall to limit access into the appliance from an IP range and port list, and lock down everything else. I would have preferred they VPN in, but they were unable to make that happen on their end.

It provided the vendor all the access and control over it, without adding any complexity or potential vulnerability to the client's LAN. There was some hardware cost and monthly service, but well worth it to this security minded client.

[-]

Dang, I thought Googles 90 push was going to be rough

The DCV part is the worst. The cert life time dropping wouldn't be so bad but the DCVs? That's going to be beyond a pain in the ass

When do we get to the point the Roots and intermediates are only valid for 90 days because hey, if they're compromised we're all screwed, right?

[-]

isnotnick@reddit (OP)

Roots and intermediates are dropping in duration, yes - not quite that low, though. Users should never expect roots or ICAs to remain the same, they should simply expect a trusted cert. Of course software will need to keep up to date with a trusted root store, which doesn’t happen in some places.

DCV is a pain - time to get a DNS provider with better automation.

[-]

goferking@reddit

Roots and intermediates are dropping in duration, yes

Hopefully OS and devices will let us be able to update them.

Speaking of that still angry at Samsung for not including the cert used by incommon/eduroam.

[-]

lywyu@reddit

Make them last 24 hours. Because why not? /s

[-]

goferking@reddit

I liked the person suggesting a femtosecond

[-]

isnotnick@reddit (OP)

I know there's the '/s' in there, but the honest answer is...they can be, and in some cases...are. But for most use-cases that involve consumers and browsers, clock-skew is still a thing.

[-]

dustojnikhummer@reddit

24 hour

Nope, different account. And the second line doesn't help either, as we also don't have access to the administrative systems. A 3rd party manages the sites while we manage the certs

[-]

circling@reddit

Oh that's even better then, because it's not your problem! Automate the cert creation and wipe your hands of it.

[-]

dustojnikhummer@reddit

Firstly, if you have physical access to the device, you can get root and enable ssh.

And break a) warranty b) contract

What if the device is a loaner?

[-]

meditonsin@reddit

Probably don't even need to mess around with webpage interactions. Just hit F12 and look at the payload and response for login and cert upload, then write a script that mimics those. That'd be like 10 lines or whatever in Python, probably.

[-]

_IBlameYourMother_@reddit

Yeah, that's gonna work great with webpages behind sso with 2nd factor.

[-]

meditonsin@reddit

There's obviously cases where this is not the easier route. Doesn't mean it's never.

[-]

Avamander@reddit

It's very likely doable with just a few "Copy as cURL" clicks in developer tools (minimum just one for the login, one for the certificate upload).

Then you paste that into cURL-to-your-favourite-language converter, boom you've got a script that uploads the certificate. Now you just have to do the challenge automatically and that's it.

[-]

spanhol90@reddit

I really thought you were giving an example of how you tried harder and used puppeteer or selenium to automate it. It's like 30 minutes of coding, and I'm sure that web interface is not changing for another 10 years.

[-]

Usually that's due to security settings not allowing the cert provider to read the data in the /.well-known/acme-challenge/ directory, or if you're running the web server on any ports besides 80 and 443. You could always try the DNS validation, it's much easier and more consistent to automate as long as your DNS provider allows for API access and works for probably 80% of enterprise use cases.

[-]

Fridge-Largemeat@reddit

Unfortunately it's kinda locked behind a GUI and I can only do HTTP. Maybe you're right about the security though, it's Mitel.

[-]

isnotnick@reddit (OP)

The other thing might be to look at if it needs a publicly-trusted certificate at all. These changes will weed out places where regular old public 'SSL' has just been used for convenience for years rather than a better solution. If it's not browsers from unmanaged devices hitting the thing, then it's not likely to need a public certificate.

[-]

ThatGuyMike4891@reddit

So credentials should be sent plaintext to authenticate. No SSL = No Encrypted Communication of Credentials.

[-]

Fortunately, we don't do BYOD. And I'm very glad that I never even had to advocate against it.

[-]

ThatGuyMike4891@reddit

I would die a happy man if I could get rid of BYOD.

[-]

I never claimed otherwise?

[-]

TunedDownGuitar@reddit

so can a large enterprise with far more resources.

Except these large enterprises keep laying off the people who know what the fuck they are doing every year. Then they have major incidents, the new team learns what the fuck to do, then they lay that fucking team off too.

I see plenty of good reasons for this, but the skeptic in me says it's a cash grab to force more control over your environment, or to force you into their environment.

[-]

neoKushan@reddit

Who is "they" in this case?

[-]

TunedDownGuitar@reddit

Google, Microsoft, Amazon. Take your pick.

[-]

neoKushan@reddit

But they aren't the only cert providers out there. There's several free providers now, it can all (mostly) be automated. There really isn't an excuse and Google/Microsoft/Amazon doesn't benefit any more or less than anyone else with this.

[-]

TunedDownGuitar@reddit

You are right, I do agree, but many of those certificate providers are reliant upon upstream CAs for their keys, which they then use to sign certs for customers. In the case of DigiCert's incident the heat was put on them by Google. From what I recall, Google threatened to distrust all DigiCert certificates if they didn't perform revocation per their binding rules.

The only reason they didn't hit the 72 hour mark is a lawsuit and federal injunction blocked them. The Bugzilla threads are good reading if you have interest.

[-]

khobbits@reddit

The point is that it will encourage everyone to use automation. From IT teams to software vendors.
Once it's automated, there is increased security, and less vendor faff.

Assuming the end vendor supports it, most certificates can be renewed with zero effort, a set up once and forget style affair.

I bought a QNAP a year ago, and it ships with an app that can renew a letsencrypt certificate every 30 days or so, for free. I think most large CMS providers have similar plugins. I'm pretty sure things like self hosted wordpress can auto renew.

For all my public facing websites in a cloud provider, that's handled automatically, by the cloud provider on the load balancer level.

For websites we host in the datacenter, but have public URLS, those just have certbot installed, which handles it.

For websites we host locally with no public URL, certbot can do the same but use DNS validation instead. Takes a bit more setup, but is still possible. (I prefer to generate the certificates on a central server, and scp them, rather than have the dns provider creds accessible to each server)

[-]

SenTedStevens@reddit

Assuming the end vendor supports it

TunedDownGuitar@reddit

Yep, Google has been the big proponent for this, and the DigiCert incident in July probably has a part to play here. Long story short - DigiCert sat on an issue with their domain certificate verification, then told clients affected they had 72hrs to revoke (per the binding rules of their parent CA), then got sued and was legally ordered to delay.

My gut says Google is using this as just cause to push for a shorter duration to force companies to invest in automation, which would be a good thing long term. My company was affected by the DigiCert issue, and we identified a lot of issues with how we did certificate management, which we'll be improving on.

Certificate duration should always be a balance. Some higher risk systems should have a 45 day rotation, and highly sensitive ones even more, but you should have a full automation process for automated cert management driving that. Most companies do not have this and will never have it.

The skeptic in me says it's a cash grab to force more shit into the cloud and lock you in to vendors that just want the line to go up.

[-]

HotTakes4HotCakes@reddit

It's both.

No one ever said legitimate security guidelines couldn't also be financially motivated.

[-]

TunedDownGuitar@reddit

This is a good point too, thanks for raising it. I agree, I have seen this with vendors countless times in the past, and it's always shaped in a "Look at how great this is for both of us! Now please accept this 30% OPEX increase!"

[-]

FenixSoars@reddit

[-]

Rare-Page4407@reddit

This is a browser forum requirement. It does not apply to anything not validated by browsers

[-]

PlannedObsolescence_@reddit

Is this a production/life-critical system with multiple organisations who interconnect and use TLS for encryption in transit? That's the kind of use that comes to mind with what you've described.

I don't mean to straw-man you if this is tangential to your actual use case, but I'm just going off the minimal context I have.

In that scenario, the public CA system isn't appropriate - instead the parties should be using a self-managed CA or a hosted PKI solution.

They could be issuing 5 year TLS certificates and trusting those specific certificates in each other's systems, then do standard change requests in maintenance windows for the manual rotation.

Or A's systems should trust B's CA and B's systems should trust A's CA (ideally specifcally an intermediary cert used for this project).

Or just use automated certificate renewal if they're going to be using the public CA system.

[-]

1esproc@reddit

Is this a production/life-critical system with multiple organisations who interconnect and use TLS for encryption in transit? That's the kind of use that comes to mind with what you've described.

Wouldn't call it life critical but yeah, it's B2B stuff. Unfortunately this thing is highly regulated and unless the government comes out and says we all need to start allowing and supporting private PKI, it'll never happen - though if this 45 day stuff comes to pass, maybe it would. There's no way things could continue as is, even at yearly renewals it's already obnoxious scheduling turnovers.

[-]

isnotnick@reddit (OP)

Yeh, this is where private PKI comes in. Sounds like your use-case really shouldn't be using publicly-trusted certs that are impacted here (note how Google and others call it the 'web PKI' - it's really nowadays for websites/services accessed by devices you don't control). If there's control over the endpoints as it seems to be in this case - it should be a private CA.

This change is also to force these kind of changes and make sure public certificates are used in the right places.

[-]

Ttylery@reddit

I have cert renewal automated on the application side. However the team that manages the certs refuses to let me automate cert renewal process itself. This means that I have to create a ticket to them telling them I want my cert renewed, wait about a day for them to look at it and renew, and then hope that they renew the correct one (theyve done it correctly once since Ive taken over this application), then they give me the cert which I drop into my automation script.

Maybe I can use this as a reason to let me take over my own cert and never have to deal with it again.

[-]

heapsp@reddit

please tell me how to do cert replacement on my tableau servers without bringing them down :P

[-]

arwinda@reddit

What is the uptime requirement you have there. 9 Nines, more? How much money are you spending on availability?

[-]

heapsp@reddit

It doesnt matter my only point is that there are applications which don't support ansible swapping a cert, especially enterprise BI tools which require thumbprints to be manually put into a portal or something like Tableau server which requires a downtime of 45 minutes per server when doing non multi-node deployments.

Yep. For those PITA systems, we put in calendar events on the day they expire with a 1 month notice.

[-]

Jazzlike_Pride3099@reddit

And in some cases even have to rearrange the order inside the cer file 🤬🤬

[-]

Qel_Hoth@reddit

This is so damn annoying. Had one application that kept complaining that the chain was broken, but it kept working so we just ignored it. The same cert was used on a related server and it said the chain was fine. Then the developer updated their android app and it, but not the iOS app or any web browser, starting giving cert errors about the broken chain.

Finally figured out that this application wanted root>intermediate>server, not server>intermediate>root like literally every other cert I've ever touched.

[-]

Jazzlike_Pride3099@reddit

One of our things wants server-root-intermediate.... I guess they did their own webbserver inhouse and the devs had their own CA so they didn't have any intermediate. When reality hit them they didn't manage to implement any better

[-]

Stop working with that vendor? Every vendor I've dealt with will generally work with me to figure out some way to do this if they don't already provide an API, or I just figure it out on my own

[-]

jrichey98@reddit

Most of our infrastructure is self-signed and doesn't connect to the internet. Getting a bunch of hosts and SAN certs updated every 45 days is not going to happen. Not that I'm too worried about it, as we'll just push a browser policy to make it not a problem.

We've got some industrial-adjacent stuff that has to have certs to communicate back to the control systems, or to be polled by our inventory management stuff, etc. To update the certs on some of those machines means (1) bringing them down and (2) by-hand plugging in a programmer/flash drive. They aren't designed to be renewed like this frequently. For reasons we can't use our own CA.

We have already been considering various workarounds, and all of them in the end strip or reduce the useful security that could be there. One-year certs seemed fine enough, and just this is more frustration on my/our end of being punished for trying to have any security at all on these systems. We could far easier remove all auth/cert flows than dealing with trying to keep any semblance of security.

[-]

Avamander@reddit

Sounds like your problem is the poor policies that stop you from using an internal CA where you should be using one, not the wide internet trying to remedy a long-time lapse in handling revocation properly.

[-]

crackanape@reddit

Why are you manually installing certs? That's already broken.

I have hundreds of public-facing devices and I don't care if they make the max lifetime 3 days.

[-]

These decisions are taken by companies which have rehearsed this a thousand times, have the teams and resources to make all sort of cool automations/api calls, the there’s is the rest… the majority…

[-]

PrettyFlyForITguy@reddit

This is also a bit anti-competitive. I'd have to think that the harder it is to run your own systems internally, the more you'd be driven to SaaS and cloud options who will have the infrastructure set up to automate it all...

[-]

dustojnikhummer@reddit

Also even if everyone says no, as long as Google says "Yes", what they say will become standard.

[-]

What makes them think that having to replace all of the certs will make businesses faster at replacing any of them?

If it become inconvenient enough, people will just find less secure workarounds that don't require constant maintenance.

[-]

skywalker-11@reddit

Ideally every vendor of software/hardware would support automatic certificate deployments so you would just do the initial setup of configuring the certificate properties and the authorization method once. The renews would then be automatically handled by the system.

If it isn't feasible to do that sort of automation or replacing certificates on a short notice you should look into other solutions such using an internal/private CA that isn't trusted by the public WebPKI as a whole. Is that less convenient and requires additional configuration on the clients? Yes! But then only people you have a business relationship would be impacted in case of issues the certificates and you will need to take full responsibility in that case.

Even today if there is hard evidence that the private key for your certificate is compromised you really SHOULD be able to replace these asap and have corresponding procedures in place to do that.

[-]

sysneeb@reddit

if this goes through does this mean all SSL certitificate will follow the below rule?

| __Certificate issued on or after__ | __Certificate issued before__ | __Maximum number of days for data reuse__ |

| -- | - | - |

| | September 15, 2025 | 398 |

| September 15, 2025 | September 15, 2026 | 200 |

| September 15, 2026 | April 15, 2027 | 100 |

| April 15, 2027 | September 15, 2027 | 45 |

This is like forcing password changes every 30 days....

I understand it's supposed to make it automated... But how long before the automation is the taget of the attacks... Get a copy of the new key as it's updated....

No increase in security and lots of bricked devices.... Yay Future!

[-]

YoureCringeAndWeak@reddit

Move away from certs :)

[-]

markth_wi@reddit

Oh look the mission critical software running some ancient version of Tomcat or IIS can't update......

[-]

jaymz668@reddit

let's not forget even automated cert renewals often require a restart, that's gonna be fun when that forced restart has issues or happens at the wrong time

[-]

10 days is just insane.

That means I will have to update certs once a week.

Granted I have an ansible playbook that handles this on my Linux hosts and a load balancer with TLS offloading for my primary web app. So those are OK I could do nightly if needed.

The Windows IIS boxes.... Urgh... Now I am going to have to do some PowerShell to automate those.... I know what my project is for Q2 of next year.

Just have the cert revoked, just like they are now if they get compromised.

Someone breaking a HSM is a lot higher of an undertaking than snarfing a key off a load balancer. Mainly because HSMs are not just designed from the CPU level, if not at the silicon level, but audited a ton of ways to get FIPS and other certifications. If someone breaks a HSM... which can happen like the side channel attacks with YubiKeys [1], it still requires a large amount of effort to figure out the PIN, and then decap the CPU.

HSMs at least give a tough obstacle. Yes, they can be broken, eventually, but it is a lot better than not having one.

[-]

rthonpm@reddit

The only reason for this is someone thinks they can make money from it, no different than the expansion of TLDs.

[-]

RedNailGun@reddit

My point is that workarounds are unexpected and unpredictable. The people who make the rules had no idea that forcing password changes every 90 days would cause a decrease in security. My point is that the people who are now making these rules, and us, have no idea if the end result will actually achieve what they intend to achieve. Seems obvious now, but any new requirement that puts significant stress on a system, may cause an unexpected problem. That is the only comparison that I am drawing here.

[-]

No_Size_1765@reddit

Thats going to need a lot of manpower for things that cant be automated...

[-]

MacAdminInTraning@reddit

Time like this make me very happy everything I manage is now SaaS.

[-]

SokkaHaikuBot@reddit

^Sokka-Haiku ^by ^MacAdminInTraning:

Time like this make me

Very happy everything

I manage is now SaaS.

^Remember ^that ^one ^time ^Sokka ^accidentally ^used ^an ^extra ^syllable ^in ^that ^Haiku ^Battle ^in ^Ba ^Sing ^Se? ^That ^was ^a ^Sokka ^Haiku ^and ^you ^just ^made ^one.

[-]

inteller@reddit

Hell just go Letsencrypt then.

[-]

uebersoldat@reddit

Bad actors: "Oh no!...anyway..." continues just phishing users and dropping malware via fake Fedex links et al.

[-]

This. Automation has been possible - ACME or otherwise - for a long, long time. The carrot didn't work too well, time for a stick.

[-]

AnnoyedVelociraptor@reddit

This is a trade off. No one is checking revocation lists and no one is adding OSCP signatures. And OSCP signatures is just a bandaid.

[-]

isnotnick@reddit (OP)

CAs do (or will, soon) have an option to issue 10 day certs with no revocation information in, so they couldn't even be checked if you wanted to. 10 days is a maximum acceptable risk window.

[-]

Avamander@reddit

I mean, stapling does work, but nobody is enforcing that.

I remain hopeful that maybe they'll allow longer lifetimes with must-staple flag, but who knows.

[-]

AnnoyedVelociraptor@reddit

Problem with stapling is that it merely proves private key possession, not legitimate domain ownership.

And OSCP stapling requires the legitimate owner to DETECT that its private key was stolen and to actually report it.

And frankly, if your software supports OSCP stapling it also supports ACME.

[-]

Avamander@reddit

Okay, so your SSL-VPN is exposed to the public internet on a certain port - and that service needs a TLS certificate that each remote user's laptop is going to see as 'trusted'.

This doesn't need a publicly trusted certificate FYI.

If you have no internal CA, and don't really have any other reason to spin one up - then I can understand wanting to still use a public CA for this. In that scenario, you would just need to find a solution that allows that certificate to be swapped out automatically. If you have admin over your firewall, you can absolutely automate this - even if there is not an ACME feature built in.

What is your firewall vendor?

At minimum firewalls from these vendors natively support ACME (caveat - not all product lines/models):

Fortinet
SonicWall
CheckPoint
Cisco
Juniper
F5

If you wanted to avoid public CAs and didn't want to run your own internal CA...

The ugliest option would be to generate a self-signed certificate for something like 10 years, and load it into everyone's machine trust store using a GPO in Active Directory. Everyone's laptops will now be happy about the certificate being trusted, and you now need to worry about generating another cert in a decade.

[-]

Old_Ad_208@reddit

Palo Alto is not on that list. Yes, it can be done with third party scripts, but I hardly have the time to spend a month implementing and testing something like this. I then have to repeat for another month testing a third party solution for my Netscaler. My luck the third party integration will fail on a critically important day for the business like election day.

Yes, I have an internal CA, but trying to get that working with both Windows and Mac VPN clients means a bunch of extra work too.

The annual process of buying a cert and throwing it on is a lot less time compared to the days and weeks to automate things. One to two hours per year adds up to around three eight hour days compared to weeks to automate. I just installed some software that has native ACME support and it was literally minutes to set up and get a cert, but the native ACME support is the key.

[-]

PlannedObsolescence_@reddit

If this ballot goes ahead, you can pretty much guarantee Palo Alto will ship ACME support well ahead of the first max validity period change (200 days max from 15 September 2025 onwards).

And it still wouldn't be that much of a headache until 15 September 2026 when it's 100 days.

Of course you can implement an alternative right now - but if you want to use the built in feature you (collective) need to petition your vendor to support ACME.

[-]

BWMerlin@reddit

Please correct me if I am wrong, but if you run your own internal CA can you not issue certs for however long you like as you can push the cert chain out to your devices?

[-]

PlannedObsolescence_@reddit

Absolutely, there are no TLS validity checks in the major browsers when using an internal CA. You control your own kingdom, which of course means taking full responsibility for CA security.

[-]

SnakeOriginal@reddit

The problem is - until the idiots at apple start enforcing their rules within browsers on internal CAs, like they do on most LOBs with iOS/iPadOS

[-]

ChadTheLizardKing@reddit

I mentioned this up thread... both iOS and Mac OS enforce 825 day maximum validity.

https://support.apple.com/en-us/HT210176

[-]

PlannedObsolescence_@reddit

Thanks for that, so if running your own CA and issuing certificates that are going to be valid for something longer than normal - you need to keep 825 days in mind if they'll be used on iOS/iPadOS/macOS etc.

Now, thought experiment - if you have full control of the CA...

Additionally, all TLS server certificates issued after July 1, 2019 (as indicated in the NotBefore field of the certificate) must follow these guidelines

Why did Apple propose that? Often when they do such things which appear harmless, it is either to hurt some competitor or punish a partner. OR there is money to be had and Apple is on it somehow?

Some interesting stats:

https://www.ssldragon.com/blog/ssl-stats/

If this gets to pass the growth of the industry by 2028 is going to be more than 11%... buy SSL issuer stock :P

But how is it going to work?

Especially on the web, some vendors take months for validation.
I had some web certificates being validated after an entire year!!!

They got validated by the time they expired 😂
You can imagine what is going to happen if the validity reduces to 45 days.

Org SSL is an entirely different story. This is going to get messy.

[-]

RequirementBusiness8@reddit

Passwords: Let’s go from every 90 days to once a year. Certificates: let’s go from every 2 years to every 45 days. And realizing how much CAs charge for public certs, the logic checks out.

[-]

Ludwig234@reddit

You still only pay in year increments. Renewals are free within the paid period

[-]

Old_Ad_208@reddit

I really wish I didn't have both a Palo Alto firewall, and a Netscaler, that don't support ACME natively. I can't find anything that says Netscaler 14.1 will support ACME natively. It appears there are non-native ways to do it with both, but I hate having to add an extra layer of complexity to break when I upgrade PANOS, or the Netscaler.

I have everything else in my DMZ doing Let's Encrypt, but the software on the other servers have native ACME support.

[-]

SomeoneRandom007@reddit

I hate SSL provision now, never mind if I have to keep refreshing them. On the plus side, someone might produce a nice way to automatically refresh them. No security risk in 3rd parties doing that for you at all, is there? /s

[-]

ElectroSpore@reddit

Googles solution is so automated without checks that scammers now seem to prefer it over lets encrypt for phishing and copycat sites.

[-]

Dal90@reddit

I can deal with it if I have too; much of our stuff isn't fully automated because I have too many other things to do and I have co-worker who handles the low risk ~80% of our certs. Things to do would include fighting the political battle that API access to Splunk so I can automatically detect an increase in TLS errors and rollback a change is not a security risk...so for now I have to run GUI queries in Splunk and rollback if I see issues.

The group we have who since January has had their application go down every 60 days when MongoDB Online uses Let's Encrypt to update their certs? Them...not so much. They went as far as demanding Mongo notify us in advance of cert updates and Mongo responded they should consider a new database provider.

Imagine my shocked face when Mongo told them the exact same thing I had told them earlier that week.

[-]

Z3t4@reddit

Then my company will stop buying certs and just use certbot/letsencrypt for everything.

[-]

tastyratz@reddit

I have to say, certificate management automation still feels like a lot of hand scripting and shell scripts/ssh when it isn't just windows & IIS. One thing I really wish we had for certs is something similar to a local peer-to-peer environment and just a client you install on every server. The "torrent" file could be how it hooks into the network and each client could have a recipe for what to do every time it updates. There are lots of great clients that pull certs directly but if you just want one or 2 to pull direct from letsencrypt/etc and then share that wildcard to peers it becomes a lot less friendly.

[-]

edhands@reddit

How about they fix certificate revocation first? This all meaningless until that part works.

[-]

It's more about the process and accountability than actually being efficient.

Servers get compromised and certificate revocation is a basically a joke.

The upside is security in the sense that a stolen private key will be valid for \~45day (statistically speaking) when issued with a 90day lifespan. The shorter the original lifespan, the reduced time an attacker has to benefit from the stolen certificate. Used to be 3yr extended validation certs and when compromised, those gave malicious actors so much time to setup and execute their campaigns.

The downside is people need to spend time and resources properly automating and testing (and monitoring) their certificate processes, or shift their architecture to pass through hardware (load balancer, reverse proxy, etc) or a service (cloudflare, etc) which becomes their public facing SSL termination. Then, what happens after SSL termination is handled however they wish (ssh, etc).

Basically it's people resistant to change, or working for companies where they can't bring about change, crying about the added work required as a result of not changing. There's no downside beyond this, and eventually I could see a 3day certificate life cycle being implemented, because why not.

I've shifted as much as I can to Cloudflare/Argo Tunnel routing so it's all built into that architecture. Things that aren't suited to this are setup with acme.sh script and DNS-01 challenge, which runs every night to check if the certificate needs renewal. Upon renewal, it triggers a deploy script which handles export into appropriate formatting and deliver of certificates where they need to go, and then restarts the necessary services, if restart is needed.

This is the standard amz has been running this standard since about 2019.

Just figure out your redeployment

[-]

nakade4@reddit

Google has proposed 90 days already (enforcement via Chrome/Chromium). Time to automate & to push your vendors to make it easier to automate, and about time..

the more often we get these certs updated the less chance we forget (exercise that muscle memory) which is what’s happening now..

[-]

jrichey98@reddit

We run a local CA for everything internal anyway. This will just push everyone to run reverse proxies for everything external.

I do think these companies are mainly trying to just make it difficult for small companies to stay off cloud services.

[-]