просто уточню что этот патерн противоречит основным концепциям CM и идти по этому пути скорее всего очень большая ошибка. Но бывают всякие ньюансы конечно

правильней серты сначала сгенерировать и положить в пилары. Или использовать нормальный PKI типа Vault

Мой тебе совет разбей задачу на этапы:
1. Сгенерировать сертификат
2. Установить сгенерированный сертификат на хост/контейнер.

Оба этапа лучше делать сборками в ci/cd системе, например Gitlab-ci/Jenkins, которые уже в свою очередь запускают salt/Ansible/bash'ернетос.
Далее 1-ю сборку триггерить или вручную или чем то по Rest-api, a после успешного выполнения вторая сборка(установка) будет триггериться автоматически.

Плюс этого подхода в том, что всегда можно видеть логи.

Вот второй этоб я бы и делал на salt, а первый python скиптом

Благодарю, но все же хочется попровать встроенный механизм ACME

так acme это протокол 🤷‍♂️ один из УЦ, работающих по нему - летсэнкрипт, а утилита для работы с acme - certbot и обвязка вокруг него

а запретить временно применять state.apply без удаления ключа или выключения миниона можно? ну типа, тчобы человек выполняя state.apply  а салт ему - хер, тут это запретили

можно

да не

проще

проще не знаю методов

типа salt 'test' state.disable

только не то)

Будет ли жить такая конструкция?
Старый salt-master 2017.7.8 и salt-minion 2019.2?

В доках писали что желательно апгрейдить сначало мастер а потом миньена.

Тогда обещяют совместимость.

Ну, вообще скорее будет жить, чем нет ) но могут быть проблемы, если ты заюзаешь подмножество фич, которое есть в одном, а во втором нету )

Причем сложно предсказать последствия, наверное