LINUX.ORG.RU
решено ФорумAdmin

puppet: sslv3 alert certificate expired

 , ,


0

2

Есть древний сервер «srv» на CentOS 5.7 и puppet 2.6.7.

Puppet-агент выдаёт ошибку:

$ puppet agent --server srv --test --noop
err: Could not retrieve catalog from remote server: sslv3 alert certificate expired
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

Сертификаты выглядят исправно:

$ puppet cert --list --all
+ srv (A5:85:2B:...)
+ ...
$ puppet cert --verify --all
$
$ puppet cert --print --all | grep 'Not After :'
            Not After : Apr  7 10:21:04 2035 GMT
            ...

Что ему не так? Помогите пожалуйста локализовать проблему.

★★

Последнее исправление: Evenik (всего исправлений: 1)

Ответ на: комментарий от MagicMirror

У тебя похоже на сервере протух серт

А где его искать? Ткните носом.

Если где крутится puppetmasterd, то там puppet cert --list и --verify отрабатывают так же.

Ну и часы проверь, конечно.

Часы синкаются по ntp, к сожалению)

Evenik ★★
() автор топика
Последнее исправление: Evenik (всего исправлений: 2)
Ответ на: комментарий от MagicMirror

Запусти агент с дебагом, наверняка он явно скажет, какой серт у него экспайред.

О, спасибо, а то --verbose ничего не добавляет. Теперь так:

$ puppet agent --server srv --test --noop --verbose --debug
...
debug: /File[...]: Autorequiring File[...]
...
debug: Finishing transaction -607378708
debug: Using cached certificate for ca
debug: Using cached certificate for srv
debug: Finishing transaction -607651938
debug: Loaded state in 0.02 seconds
err: Could not retrieve catalog from remote server: sslv3 alert certificate expired
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
Evenik ★★
() автор топика
Последнее исправление: Evenik (всего исправлений: 3)
Ответ на: комментарий от MagicMirror

Я бы на твоём месте проверил через openssl s_client

Спасибо ещё раз, проверил с текущим сертификатом:

$ openssl s_client -host master -port 8140 -cert /var/lib/puppet/ssl/certs/srv.pem -key /var/lib/puppet/ssl/private_keys/srv.pem -CAfile /var/lib/puppet/ssl/certs/ca.pem
CONNECTED(00000003)
depth=1 /CN=Puppet CA: master
verify return:1
depth=0 /CN=srv
verify return:1
11809:error:14094415:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate expired:s3_pkt.c:1086:SSL alert number 45
11809:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:

Но почему? Они же не просрочены:

$ openssl x509 -enddate -noout -in /var/lib/puppet/ssl/certs/ca.pem          
notAfter=Apr  7 08:15:23 2035 GMT
$ openssl x509 -enddate -noout -in /var/lib/puppet/ssl/certs/srv.pem
notAfter=Apr  7 10:21:04 2035 GMT

Evenik ★★
() автор топика
Ответ на: комментарий от Evenik

Сделал даже вот так:

$ openssl s_client -connect master:8140 -showcerts

Получил вывод с двумя сертификатами, положил их в файлы и проверил — оба с датами окончания в 2035.

Evenik ★★
() автор топика
Последнее исправление: Evenik (всего исправлений: 1)
Ответ на: комментарий от firkax

ca.pem надо проверять не на клиенте а на сервере. И всю цепочку, если там ещё промежуточные есть.

Да я везде проверил, все сертификаты до 2035 года.

Перед этим был просрочен CRL и puppet cert --list или --verify ругались. На сервере я его удалил и puppet создал CRL с nextUpdate в 2029. На клиенте же с CRL или без него просто появлятся эта ошибка.

Что-то похожее обсуждалось здесь: https://openssl-users.openssl.narkive.com/RMoIGo0D/valid-certificate-reported...

А как вообще правильно пересоздавать файлы CRL и должны ли они быть синхронизированы в цепочке?

З.Ы.: Это всё части некоего промышленного комплекса, и когда-то оно даже работало, потом утратило актуальность, а теперь внезапно снова понадобилось...

Evenik ★★
() автор топика
Последнее исправление: Evenik (всего исправлений: 6)
Ответ на: комментарий от Evenik

Время на сервере правильное?

Мне кажется надо внимательно пройтись по цепочке сертификатов и всё выяснится. Причём проверить что это именно та цепочка, которой пользуется сервер. Я не имел дела с puppet, но из общих соображений:

1) Проверить не закешировал ли сервер старое просроченное CA. Проверяется ребутом той проги которая слушает 8140 порт куда ты коннектился. А да, между выключением и включением проги проверь что коннектишься ты именно к ней (сделай коннект и проверь что connection refused).

2) Посмотреть, откуда сервер берёт список доверенных CA. Проверяется удалением оттуда нужного root CA и наблюдением как сервер вместо expired станет писать unable to find local issuer или чё-то такое. Возможно ребутнуть демон будет т.к. см. п.1

3) Берёшь /var/lib/puppet/ssl/certs/srv.pem смотришь у него поле issuer, ищешь сертификат у которого эта строчка в subject, проверяешь срок действия, и дальше пока не дойдёшь до рута.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Ура, кажется, починил!

Заметил просроченный CRL, пересоздал его на мастере, проверил несколько раз всю цепочку, убедился, что сертификаты не просрочены, много гуглил, создал этот тред, ещё раз всё проверил, скопировал CRL на клиента. Ничего не помогло, расстроился. Потом перезагрузил все машины в цепочке и оно заработало. Перезагружал разом, поэтому причина осталась неизвестна.

MagicMirror, firkax, спасибо большое!

Evenik ★★
() автор топика
Последнее исправление: Evenik (всего исправлений: 1)