[TrueDuality]

Speaking as someone who has worked in tightly regulated environment, certificates are kind of a nasty problem and there are a couple of requirements that are in conflict for going to full automation of certificates.

- Rotation of all certificates and authentication material must be renewed at regular intervals (no conflict here, this is the goal)

- All infrastructure changes need to have the commands executed and contents of files inspected and approved in writing by the change control board before being applied to the environment

That explicit approval of any changes being made within the environment go against these being automated in any way shape or form. These boards usually meet monthly or ad-hoc for time-sensitive security updates and usually have very long lists of changes to review causing the agenda to constantly overflow to the next meeting.

You could probably still make it work as a priority standing agenda idea but its going to still involve manual process and review every month. I wouldn't want to manually rotate and approve certificates every month and many of these requirements have been signed into law (at least in the US).

Starting to see another round of modernization initiatives so maybe in the next few years something could be done...

[ericpauley]

It seems like the core problem here is that certificates are considered part of infrastructure, and further that they're part of infrastructure that requires approval!

Clearly not all automated infrastructure requires approval: autoscaling groups spin up and tear down compute instances all the time. Further, changes to data can't universally require approval, otherwise every CRUD operation would require a committee meeting.

Are certificates truly explicitly defined to be infrastructure that requires change approval? If not, perhaps more careful interpretation of the regulations could allow for improved automation and security outcomes.

[syncsynchalt]

> Clearly not all automated infrastructure requires approval: autoscaling groups spin up and tear down compute instances all the time.

In these sort of environments, they do not.

We're talking about environments where it is forbidden to make _any_ change of any kind without a CCB ticket. Short cert lifetimes are fundamentally at odds with this. Luckily these systems often aren't public and don't need public certs, but there's a slice of them that do.

[mrgaro]

What dictates that certificate update needs to have a manual change process? I'd bet that it's just legal team saying that "this is how it's always been" instead of adjusting their interpretation as the environment around changes.

[TrueDuality]

The references I'd direct you to are NIST 800-53r5 controls CM-3 (Configuration Change Control) and CM-4 (Impact Analyses) along with their enhancements, require that configuration changes go through documented approval, security impact analysis, and testing before implementation. A certificate change is unfortunately consider a configuration change to the services.

Each change needs a documented approval trail. While you can get pre-approval for automated rotations as a class of changes, many auditors interpret the controls conservatively and want to see individual change tickets for each cert rotation, even routine ones.

[cpach]

Haven’t read those documents but to me that sounds like a problem with the auditor rather than the guideline?

[whynotmaybe]

Yes, those rules always come from legal.

In some regulated places, someone is legally responsible for authorizing a change in production.

If it fails, that person's on the hook. So the usual way is to have a manual authorization for every change. Yes, it's a PITA.

One place I've worked changed their process to automatically allow changes in some specific parts for a specific period during the development of a new app.

And for some magical reasons, the person usually associated with such legal responsibility are the one that don't trust automatic process.