OpenSSL провера валидности p12 сертификата

Сохранение одного и того же закрытого ключа в корневом ЦС позволяет всем сертификатам продолжать успешно проверять новый корень; все, что от вас требуется, – это доверять новому корню.

Отношение подписи сертификата основано на сигнатуре от закрытого ключа; сохраняя один и тот же секретный ключ (и, неявно, тот же самый открытый ключ) при создании нового публичного сертификата, с новым сроком действия и любыми другими новыми атрибутами, измененными по мере необходимости, сохраняет доверительные отношения на месте. CRL также могут переходить от старого сертификата к новому, как они есть, например, к сертификатам, подписанным закрытым ключом.

Итак, давайте проверим!

Сделать корневой ЦС:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

Создайте из него дочерний сертификат:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

Подпишите дочерний сертификат:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

Все установлено, нормальное отношение сертификата. Давайте проверим доверие:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

Итак, теперь, скажем, прошло 10 лет. Давайте сгенерируем новый открытый сертификат из одного и того же корневого закрытого ключа.

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

И .. это сработало?

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

Но почему? Они разные файлы, верно?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

Да, но это не означает, что новый открытый ключ не криптографически соответствует сигнатуре в сертификате. Различные серийные номера, одинаковый модуль:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

Пойдем немного дальше, чтобы убедиться, что он работает в проверке сертификата реального мира.

Запустите экземпляр Apache и дайте ему перейти (структура файла debian, при необходимости отрегулируйте):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

Мы установимэти директивы на VirtualHost прослушивании на 443 – помните, что корневой сертификат newroot.pem даже не существовал, когда был создан cert.pem и подписан.

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

Давайте посмотрим, как opensl видит это:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

Хорошо, а как насчет браузера с использованием криптографического API MS? Сначала нужно доверять корню, тогда все хорошо, с порядковым номером нового корня:

И мы все равно должны работать со старым корнем. Переключите конфигурацию Apache:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

Сделайте полный перезапуск в Apache, перезагрузка не переключит сертификаты должным образом.

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

И с помощью браузера API Crypto API Apache представляет старый root, но новый root все еще находится в доверенном корневом хранилище компьютера. Он автоматически найдет его и проверит сертификат против доверенного (нового) корня, несмотря на то, что Apache представляет другую цепочку (старый корень). После удаления нового корня из доверенных корней и добавления исходного корневого сертификата все хорошо:

Итак, вот и все! Храните тот же секретный ключ при обновлении, замените новый доверенный корень, и он почти все просто работает . Удачи!

Недавно у нас встала задача мониторинга срока действия сертификатов на серверах с Windows. Ну как встала, после того, как сертификаты несколько раз превращались в тыкву, в то самое время, когда ответственный за их продление бородатый коллега находился в отпуске. После этого мы с ним

что-то заподозрили

решили над этим задуматься. Так как у нас не спеша внедряется система мониторинга NetXMS, она и стала главным и, в принципе, единственным кандидатом на эту задачу.

Результат в итоге был получен в таком виде:

А сам процесс далее.

Поехали. Встроенного счетчика заканчивающегося срока сертификатов в NetXMS нет, поэтому нужно создавать свой и использовать скрипты для обеспечения его данными. Конечно, на Powershell, это же Windows. Скрипт должен прочитать все сертификаты в операционной системе, взять оттуда срок их истечения в днях и передать это число в NetXMS. Через его агента. Вот с него и начнем.

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

Чтобы сервер NetXMS узнал о существовании нашего кастомного параметра, он должен получить его от агента. Иначе этот параметр невозможно будет добавить, по причине его отсутствия. Поэтому, в конфигурационный файл агента nxagentd.conf мы добавляем строку внешнего параметра с именем HTTPS.CertificateExpireDateSimple, в которой прописываем запуск скрипта:

ExternalParameter = HTTPS.CertificateExpireDateSimple: powershell.exe -File "\servershareNetXMS_CertExpireDateSimple.ps1"

Учитывая, что скрипт запускается по сети, нужно не забыть про

Execution Policy

, а так же не забыть прочие “-NoLogo -NoProfile -NonInteractive”, которые я опустил для лучшей читаемости кода.

В результате чего конфиг агента выглядит примерно так:

#
# NetXMS agent configuration file
# Created by agent installer at Thu Jun 13 11:24:43 2021
#
 
MasterServers = netxms.corp.testcompany.ru
ConfigIncludeDir = C:NetXMSetcnxagentd.conf.d
LogFile = {syslog}
FileStore = C:NetXMSvar
SubAgent = ecs.nsm
SubAgent = filemgr.nsm
SubAgent = ping.nsm
SubAgent = logwatch.nsm
SubAgent = portcheck.nsm
SubAgent = winperf.nsm
SubAgent = wmi.nsm
 
ExternalParameter = HTTPS.CertificateExpireDateSimple: powershell.exe -File "\servershareNetXMS_CertExpireDateSimple.ps1"

После этого нужно сохранить конфиг и перезапустить агента. Можно это сделать из консоли NetXMS: открыть конфиг (Edit agent’s confuguration file), отредактировать, выполнить Save&Apply, в результате чего, собственно, произойдет то же самое. Потом перечитать конфигурацию (Poll > Configuration), если совсем нет сил подождать. После этих действий должна появиться возможность добавить наш кастомный параметр.

В консоли NetXMS идем в Data Collection Configuration подопытного сервера, на котором мы собрались мониторить сертификаты и создаем там новый параметр (в дальнейшем, после настройки, есть смысл перенести его в шаблоны). Выбираем HTTPS.CertificateExpireDateSimple из списка, вписываем Description с понятным именем, тип ставим Integer и настраиваем интервал опроса. Слишком коротким его нет смысла делать, чтобы не забивать базу лишней информацией, слишком длинным неудобно будет ждать при проверке. Для сертификатов я обычно ставлю 600 секунд. На время отладки есть смысл сделать его покороче, 30 секунд, например:

Всё, готово, пока достаточно. Можно проверять… нет, еще рано. Сейчас, естественно, ничего мы не получим. Просто потому, что скрипт еще не написали. Исправляем это упущение. Скрипт будет выдавать просто цифру, количество дней, оставшихся до окончания срока действия сертификата. Самую минимальную из всех имеющихся. Пример скрипта:

try {
    # Получаем все сертификаты из хранилища сертификатов
    $lmCertificates = @( Get-ChildItem -Recurse -path 'Cert:LocalMachineMy' -ErrorAction Stop )
     
    # Если сертификатов нет, вернуть "10 лет"
    if ($lmCertificates.Count -eq 0) { return 3650 }
 
    # Получаем Expiration Date всех сертификатов
    $expirationDates = @( $lmCertificates | ForEach-Object { return $_.NotAfter } )
 
    # Получаем наиболее близкий Expiration Date из всех
    $minExpirationDate = ($expirationDates | Measure-Object -Minimum -ErrorAction Stop ).Minimum
 
    # Конвертируем наиболее близкий Expiration Date в количество оставшихся дней с округлением в меньшую сторону
    $daysLeft = [Math]::Floor( ($minExpirationDate - [DateTime]::Now).TotalDays )
 
    # Возвращаем значение
    return $daysLeft
}
catch {
    return -1
}

Получается так:

723 дня, до истечения срока действия сертификата еще почти два года. Логично, потому что сертификаты на Exchange тестового стенда я перевыписывал совсем недавно.

Это был простой вариант. Наверное, кого-то и такой устроит, но нам хотелось большего. Задачу мы себе поставили получить список всех сертификатов на сервере, поименно, и у каждого видеть количество дней, оставшихся до окончания срока действия сертификата.

Второй вариант, несколько посложнее.

Опять редактируем конфиг агента и там вместо строчки с ExternalParameter пишем две другие:

ExternalList = HTTPS.CertificateNames: powershell.exe -File "\servershareNetXMS_CertNames.ps1"
ExternalParameter = HTTPS.CertificateExpireDate(*): powershell.exe -File "\servershareNetXMS_CertExpireDate.ps1" -CertificateId "$1"

В

ExternalList

мы получаем просто список строк. В нашем случае, список строк с именами сертификатов. Список этих строк мы получим скриптом. Имя списка —

HTTPS.CertificateNames

.

Скрипт NetXMS_CertNames.ps1:

#Список возможных имен сертификатов
$nameTypeList = @(
        [System.Security.Cryptography.X509Certificates.X509NameType]::SimpleName,
        [System.Security.Cryptography.X509Certificates.X509NameType]::DnsName,
        [System.Security.Cryptography.X509Certificates.X509NameType]::DnsFromAlternativeName,
        [System.Security.Cryptography.X509Certificates.X509NameType]::UrlName,
        [System.Security.Cryptography.X509Certificates.X509NameType]::EmailName,
        [System.Security.Cryptography.X509Certificates.X509NameType]::UpnName
)
 
#Ищем все сертификаты, имеющие закрытый ключ
$certList = @( Get-ChildItem -Path 'Cert:LocalMachineMy' | Where-Object { $_.HasPrivateKey -eq $true } )
 
#Проходим по списку сертификатов, формируем строку "Имя сертификата - Дата - Thumbprint" и возвращаем её
foreach ($cert in $certList) {
    $name = '(unknown name)'
    try {
        $thumbprint = $cert.Thumbprint
        $dateExpire = $cert.NotAfter
        foreach ($nameType in $nameTypeList) {
            $name_temp = $cert.GetNameInfo( $nameType, $false)
            if ($name_temp -ne $null -and $name_temp -ne '') {
                $name = $name_temp;
                break;
            }
        }
        Write-Output "$($name) - $($dateExpire.ToString('dd.MM.yyyy')) - [T:$($thumbprint)]"
    }
    catch {
        Write-Error -Message "Error processing certificate list: $($_.Exception.Message)"
    }
}

А уже в

ExternalParameter

мы на вход подаем строки из списка ExternalList, а на выходе получим всё то же количество дней для каждой. Идентификатором служит Thumbprint сертификата. Обратите внимание, что HTTPS.CertificateExpireDate в этом варианте содержит звездочку (*). Это необходимо для того, чтобы он принимал внешние переменные, как раз наш CertificateId.

Скрипт NetXMS_CertExpireDate.ps1:

#Определяем входящий параметр $CertificateId
param (
    [Parameter(Mandatory=$false)]
    [String]$CertificateId
)
 
#Проверка на существование
if ($CertificateId -eq $null) {
    Write-Error -Message "CertificateID parameter is required!"
    return
}
 
#По Thumbprint из строки в $CertificateId ищем сертификат и определяем его Expiration Date 
$certId = $CertificateId;
try {
    if ($certId -match '^.*[T:(?<Thumbprint>[A-Z0-9] )]$') {
        $thumbprint = $Matches['Thumbprint']
        $certificatePath = "Cert:LocalMachineMy$($thumbprint)"
         
        if (Test-Path -PathType Leaf -Path $certificatePath ) {
            $certificate = Get-Item -Path $certificatePath;
            $certificateExpirationDate = $certificate.NotAfter
            $certificateDayToLive = [Math]::Floor( ($certificateExpirationDate - [DateTime]::Now).TotalDays )
            Write-Output "$($certificateDayToLive)";
        }
        else {
            Write-Error -Message "No certificate matching this thumbprint found on this server $($certId)"
        }
    }
    else {
        Write-Error -Message "CertificateID provided in wrong format. Must be FriendlyName [T:<thumbprint>]"
    }
}
catch {
    Write-Error -Message "Error while executing script: $($_.Exception.Message)"
}

В Data Collection Configuration сервера создаем новый параметр. В Parameter выбираем наш

HTTPS.CertificateExpireDate(*)

из списка, и, (внимание!) меняем звездочку на

{instance}

. Этот важный момент позволит создать отдельный счетчик для каждого инстанса (сертификата). Остальное заполняется, как в предыдущем варианте:

Для того, чтобы счетчики было из чего создавать, на вкладке Instance Discovery нужно выбрать Agent List из списка и в поле List Name вписать имя нашего ExternalList из скрипта — HTTPS.CertificateNames.

Почти готово, немного подождать или принудительно сделать Poll > Configuration и Poll > Instance Discovery, если совсем невозможно ждать. В результате получаем все наши сертификаты со сроками действия:

То, что надо? Ну да, только червячок перфекционизма смотрит на этот ненужный Thumbprint в имени счетчика печальными глазами и никак не дает закончить статью. Чтобы его накормить, снова открываем свойства счетчика и на вкладке Instance Discovery в поле «Instance discovery filter script» добавляем написанный на NXSL (внутреннем языке NetXMS) скрипт:

instance = $1;
 if (instance ~= "^(.*)s-s[T:[a-zA-Z0-9] ]$")
 {
 return %(true, instance, $1);
 }
 return true;

который будет отфильтровывать Thumbprint:

А чтобы его отобразить отфильтрованным, на вкладке General в поле Description меняем CertificateExpireDate: {instance} на CertificateExpireDate: {instance-name}:

Всё, наконец-то финиш из КДПВ:

Красота же?

Осталось настроить оповещения, чтобы они приходили на почту, когда срок сертификата подходит к своему логическому концу.

1. Сначала нужно создать шаблон события (Event Template) для активации его при уменьшении значения счетчика до какого-то заданного нами порога. В Event Configuration создаем два новых шаблона с именами, скажем CertificateExpireDate_Threshold_Activate со статусом Warning:

и аналогичный CertificateExpireDate_Threshold_Deactivate со статусом Normal.

2. Дальше идем в свойства счетчика и на вкладке Tresholds настраиваем порог:

где выбираем наши созданные эвенты CertificateExpireDate_Threshold_Activate и CertificateExpireDate_Threshold_Deactivate, ставим количество замеров (Samples) 1 (конкретно для этого счетчика больше ставить смысла нет), значение в 30 (дней), к примеру, и, что важно, настраиваем время повторения эвента. Для сертификатов в продакшене я ставлю раз в сутки (86400 секунд), иначе можно утонуть в оповещениях (что, кстати и случилось один раз, причем так, что переполнился почтовый ящик за выходные). На время отладки есть смысл поставить поменьше, 60 секунд, к примеру.

3. В Action Configuration создаем шаблон письма оповещения, типа такого:

Все эти %m, %S и т.п. — макросы, в которые будут подставлены значения из нашего параметра. Подробнее они описаны в мануале NetXMS.

4. И, наконец, объединяя предыдущие пункты, в Event Processing Policy создаем правило, по которому будет создаваться Alarm и отправляться письмо:

Сохраняем политику, всё, можно тестировать. Поставим порог повыше, для проверки. У меня ближайший сертификат истекает через 723 дня, для проверки поставил 724. В результате получим такой аларм:

и такое оповещение по почте:

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