Добрый день.
На windows c 4.0.9963 выводит, вероятно дело только в другом ключевом слове, посмотрите что вам покажет без grep
Добавлю от себя, что в случае 4 версии Вы можете в программу просмотра ASN.1 (есть онлайн сервисы) загрузить header.key (так как он не содержит закрытой информации) и почти в самом конце увидите что-то вроде
Код:(2303,33) CONTEXT SPECIFIC (12)
SEQUENCE
OBJECT IDENTIFIER '1.2.643.2.2.37.3.10'
OCTET STRING
SEQUENCE
CONTEXT SPECIFIC (1): '20231006103056Z'
Понять строчку не составит труда - 4 цифры год, 2 цифры месяц, 2 цифры число в месяце, 2 цифры час, 2 цифры минута, 2 цифры секунда, "Z" обозначение часового пояса. Обычно "Z", то есть UTC (упрощенно говоря - по Гринвичу), для Московского времени нужно прибавить 3 часа.
Примечание. В теории UTC не то же самое что GMT, но Вас наверняка не интересуют секунды и доли секунды, которых то не хватает в конце полугодия, то появляются лишние (из-за неравномерностей движения небесных тел порядка 1/300 000 доли процента).
Примечание 2. Если в сертификате есть расширение со сроком действия закрытого ключа, Вы можете удалить расширение из контейнера при помощи утилиты csptest. В этом случае тестирование будет показывать одинаковую дату окончания действия ключа, в примере со снимка экрана - 18 августа 2022 года. С другой стороны, подсмотреть в header.key будет нечего.
Конечно, для квалифицированного сертификата использование ключа дольше установленного законом срока недопустимо (за исключением расшифровки). Однако, законом не указано каким способом будет зафиксирован срок действия ключа и от какого события отсчитывать 1 год 3 месяца. Если специально не передавать в УЦ дату генерации ключа, УЦ будет руководствоваться либо датой поступления запроса на сертификат либо датой выпуска сертификата. Если УЦ несмотря на неопределенность берет на себя функцию ограничения даты действия ключа, то почему бы этой датой не воспользоваться?
Разница менее месяца не принципиальна с точки зрения безопасности и напрямую закону не противоречит, так как число способов использовать ключ до выпуска сертификата крайне ограничено и в 99% случаев ключ в первые дни после генерации (до получения сертификата из УЦ) используется только для подписания запроса на сертификат.
Для себя я даже написал небольшую "графическую оболочку" над csptest (в частности, для удаления расширения со сроком), так удобнее указывать имена контейнеров. Правда в 2022 году почти нет поводов ее использовать - Федеральное казначейство (где сейчас получаем 99% сертификатов) больше не добавляет расширение со сроком действия ключа и стало выпускать сертификаты сроком на 450 дней и с учетом 5-6 дней изготовления сам сертификат заканчивается примерно на день раньше истечения срока ключа в контейнере.
Примечание 3. Если в сертификате нет расширения со сроком действия закрытого ключа и удалено расширение из контейнера, тестирование возьмет за основу дату начала сертификата и отсчитает 456 дней (для справки 1 год и 3 месяца это от 365+88=453 дня до 366+92=458 дней). В примере со снимка это 17 августа 2022 года.
Примечание 4. Если в сертификате нет расширения со сроком действия закрытого ключа при необходимости "продлить" срок действия ключа, например, неаккредитованного (неквалифицированного) УЦ, возможно экспортировать ключ в pfx, затем импортировать в новый контейнер. Новый контейнер ничего не знает о прошлом контейнере, а в pfx расширения со сроком пока нет, поэтому отсчет начнется "с чистого листа". Для неквалифицированных сертификатов сроки жестко не заданы и могут регулироваться внутренними регламентами.
Отредактировано пользователем 29 июля 2022 г. 7:03:48(UTC)
| Причина: Не указана