Здравствуйте, pva, Вы писали:

pva>·>Именно, что bundle. А оно действительно надо, чтобы это была цепочка? Поместить просто оба серта как корневые, да и всё. Попробуй в песочнице.
pva>Bundle потому что цепочка сертификатов. Я там привел пример что один и тот же узловой сертификат проходит валидацию как через цепочку, так и через самоподписанный int CA сертификат.
Я может что-то не понимаю, в ssl... но по-моему bundle это просто bundle — ведро с сертификатами. А цепочки это уже этап валидации: видим серт, смотрим — известен ли нам, ака лежит ли в нашем ведре? Если нет, смотрим на кем этот серт подписан. goto 10.
Поэтому что такое "цепочка в bundle лежит" — я что-то не очень понимаю это как вообще может так быть, как бандл с цепочкой отличается от бандла просто независимых сертов.

pva>Эта схема дает возможность заменить корневой сертификат без остановки всей инфраструктуры просто постепенным обновлением.
Это не значит что эта схема единственная..

pva>Впрочем, я кажется понял что ты имеешь в виду. Поместить на клиенте в bundle оба CA сертификата, чтобы при проверке выбирался нужный. В целом, вероятно, рабочая схема. Под вопросом, правда, сохранит ли она работоспособность при использовании certificate pinning или client auth via certificate.
Стоит проверить и если вдруг не заработает — мне будет очень любопытно — по какой причине.

Здравствуйте, pva, Вы писали:

pva>·>Вроде обычно есть некое хранилище сертификатов, в которое ты импортируешь все нужные CA серты. Про mongo конкретно ничего не знаю.
pva>Судя по доке, только единый CA.
pva>

Client certificate requirements:
pva>A single Certificate Authority (CA) must issue the certificates for both the client and the server.
pva>...
pva>The certificates have the following requirements:
pva>A single Certificate Authority (CA) must issue all X.509 certificates for the members of a sharded cluster or a replica set.

pva>И это только один из элементов.
Хм... Грустно, если так. Может тут имеется в виду, что один CA должен выписывать серты на обоих сторонах?
Попробуй, net.tls.certificateKeyFile параметр — путь к .pem файлу, который вообще-то может иметь несколько сертов внутри.
А ещё есть net.tls.certificateSelector, там написано такое: The mongod searches the operating system's secure certificate store for the CA certificates.
А ещё такое чтиво есть: https://www.mongodb.com/docs/manual/tutorial/rotate-x509-membership-certificates/
Дальше мне лень изучать...

Здравствуйте, pva, Вы писали:


pva>На нем построена цепочка доверия небольшой инфраструктуры. Есть ли возможность заменить этот рутовый сертификат без остановки зависимых узлов?
Не очень понял.... но вроде же рутовых сертов может быть несколько. В типичном браузере стоят десятки рутовых CA сертов.
Т.е. добавляешь второго рута. Спокойно заменяешь серты узлов. Выкидываешь первого рута.

pva> — переподписать новый CA на self-signed, отрезав старый CA от цепочки
А это возможо разве? Придётся выпустить новый серт, насколько я понимаю.

Здравствуйте, ·, Вы писали:

·>Именно, что bundle. А оно действительно надо, чтобы это была цепочка? Поместить просто оба серта как корневые, да и всё. Попробуй в песочнице.
Bundle потому что цепочка сертификатов. Я там привел пример что один и тот же узловой сертификат проходит валидацию как через цепочку, так и через самоподписанный int CA сертификат.
Эта схема дает возможность заменить корневой сертификат без остановки всей инфраструктуры просто постепенным обновлением.
Впрочем, я кажется понял что ты имеешь в виду. Поместить на клиенте в bundle оба CA сертификата, чтобы при проверке выбирался нужный. В целом, вероятно, рабочая схема. Под вопросом, правда, сохранит ли она работоспособность при использовании certificate pinning или client auth via certificate.

Привет,

в общем, столкнулся с такой ситуацией. Есть CA узел в сертификате которого допущена ошибка.
На нем построена цепочка доверия небольшой инфраструктуры. Есть ли возможность заменить этот рутовый сертификат без остановки зависимых узлов?
Я попытался сгенерить с того же привата исправленный серт, но при этом узловые сертификаты перестают проходить верификацию. Очевидно цепочка завязана на поле Issuer, которое и требует исправления, а не на Public Key.
Может возможно каким-то образом сделать мультисигн? Чтобы было 2 Issuer для начала, а затем после обновления второго уровня отозвать невалидный серт.

p.s. Посмотрел cross-signing. Правильно ли я понимаю что можно сделать так
— сгенерить новый CA сертификат, подписав его старым CA сертификатом
— от нового CA перегенерить узловые сертификаты
— переподписать новый CA на self-signed, отрезав старый CA от цепочки
?

Здравствуйте, pva, Вы писали:

pva>в общем, столкнулся с такой ситуацией. Есть CA узел в сертификате которого допущена ошибка.

Ее нужно исправить, перевыпустив этот CA. Подпись на нем можно сделать также как на старом, либо от трастед рута либо self-sign. Все что было под ним придется перевыпускать.

Здравствуйте, mike_rs, Вы писали:

pva>>в общем, столкнулся с такой ситуацией. Есть CA узел в сертификате которого допущена ошибка.
_>Ее нужно исправить, перевыпустив этот CA. Подпись на нем можно сделать также как на старом, либо от трастед рута либо self-sign. Все что было под ним придется перевыпускать.
Ну, это крайний вариант и достаточно плохой поскольку требует остановки всего. Попробую в песочнице реализовать кросс-подпись и перевыпуск.

Здравствуйте, pva, Вы писали:

_>>Ее нужно исправить, перевыпустив этот CA. Подпись на нем можно сделать также как на старом, либо от трастед рута либо self-sign. Все что было под ним придется перевыпускать.
pva>Ну, это крайний вариант и достаточно плохой поскольку требует остановки всего. Попробую в песочнице реализовать кросс-подпись и перевыпуск.

так выше написали, просто второй рут и постепенный переход. И кстати — любой серт, в том числе и рут, имеет срок действия. Как ты вообще планировал его замену по истечении срока без остановки всего? Считай что у тебя эта ситуация настала и тебе надо просто заменить протухший рут — штатная же операция.

Здравствуйте, mike_rs, Вы писали:

_>так выше написали, просто второй рут и постепенный переход.
Браузеры-то может и умеют в мультисерт, а вот умеют ли всякие mongodb и иже с ними — большой вопрос. Сертификаты — это не только про браузеры.

_>И кстати — любой серт, в том числе и рут, имеет срок действия. Как ты вообще планировал его замену по истечении срока без остановки всего?
С продлением нет никаких проблем, потому как Subj остается тем же самым. Ты просто перевыпускаешь сертификат с новой датой на том же приват ключе и все.

Здравствуйте, pva, Вы писали:

_>>так выше написали, просто второй рут и постепенный переход.
pva>Браузеры-то может и умеют в мультисерт, а вот умеют ли всякие mongodb и иже с ними — большой вопрос. Сертификаты — это не только про браузеры.
Вроде обычно есть некое хранилище сертификатов, в которое ты импортируешь все нужные CA серты. Про mongo конкретно ничего не знаю.

Здравствуйте, ·, Вы писали:

·>Вроде обычно есть некое хранилище сертификатов, в которое ты импортируешь все нужные CA серты. Про mongo конкретно ничего не знаю.
Судя по доке, только единый CA.

Client certificate requirements:
A single Certificate Authority (CA) must issue the certificates for both the client and the server.
...
The certificates have the following requirements:
A single Certificate Authority (CA) must issue all X.509 certificates for the members of a sharded cluster or a replica set.

И это только один из элементов.

Здравствуйте, ·, Вы писали:

·>А это возможо разве? Придётся выпустить новый серт, насколько я понимаю.
Сделал в песочнице.

>openssl verify -show_chain -CAfile good-ca-int-bundle.crt good-ca-child.crt
good-ca-child.crt: OK
Chain:
depth=0: C=US, L=New York, O=Test, CN=GOOD CA CHILD (untrusted)
depth=1: C=US, L=New York, O=Test, CN=GOOD CA
depth=2: C=GB, L=London, O=Test, CN=BAD ROOT CA

>openssl verify -show_chain -CAfile good-ca.crt good-ca-child.crt
good-ca-child.crt: OK
Chain:
depth=0: C=US, L=New York, O=Test, CN=GOOD CA CHILD (untrusted)
depth=1: C=US, L=New York, O=Test, CN=GOOD CA

Так что работает предложенная мной выше схема. Думаю что можно и в обратном порядке тоже сделать.
— генерим исправленный CA со старого ключа
— подписываем старый CA новым CA, получая цепочку GoodCA -> BadCA -> nodes
— деплоим новую chain of trust без нарушения работы нод
— генерим новые nodes от GoodCA напрямую и деплоим
По идее, этот путь даже лучше если BadCA имеет ограниченный pathLenConstraint.

Здравствуйте, pva, Вы писали:

pva> ·>А это возможо разве? Придётся выпустить новый серт, насколько я понимаю.
pva> Сделал в песочнице.
pva> >-CAfile good-ca-int-bundle.crt
Именно, что bundle. А оно действительно надо, чтобы это была цепочка? Поместить просто оба серта как корневые, да и всё. Попробуй в песочнице.

Здравствуйте, ·, Вы писали:

·>Поэтому что такое "цепочка в bundle лежит" — я что-то не очень понимаю это как вообще может так быть, как бандл с цепочкой отличается от бандла просто независимых сертов.
Да ничем, в целом. Тут ты прав на 100% для openssl как минимум. С остальными серверами надо разбираться. Чтобы поддерживали поиск в корзине сертификатов, а не использовали только первый прочитанный.

·>Стоит проверить и если вдруг не заработает — мне будет очень любопытно — по какой причине.
Вероятно, будет работать. Нет возможности сейчас проверить.

Здравствуйте, pva, Вы писали:

pva>·>Поэтому что такое "цепочка в bundle лежит" — я что-то не очень понимаю это как вообще может так быть, как бандл с цепочкой отличается от бандла просто независимых сертов.
pva>Да ничем, в целом. Тут ты прав на 100% для openssl как минимум. С остальными серверами надо разбираться. Чтобы поддерживали поиск в корзине сертификатов, а не использовали только первый прочитанный.
Если так, то оно сможет работать только для цепочки из двух сертов.