🪟 Windows: Ищем «протухающие» сертификаты через PowerShell

Забытый SSL-сертификат на внутреннем веб-сервере или в хранилище `LocalMachine` — это классический повод для экстренного вызова админа из отпуска. Чтобы этого не случилось, давай автоматизируем проверку.

Технический разбор:
В Windows есть встроенный провайдер `Cert:`, который позволяет работать с сертификатами как с обычными файлами.

Сниппет для поиска проблем:

# Найти все сертификаты в личном хранилище компьютера, 
# срок действия которых истекает в ближайшие 30 дней
Get-ChildItem -Path Cert:\LocalMachine\My | 
    Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) -and $_.NotAfter -gt (Get-Date) } |
    Select-Object Subject, NotAfter, Thumbprint |
    Format-Table -AutoSize

Зачем это нужно: Закинь этот скрипт в ежедневный Task Scheduler с отправкой письма на почту, и ты никогда не пропустишь момент, когда пора обновлять сертификат на твоем AD FS или IIS.

#windows #powershell #security #pki #certificates #automation #admin_future

🪟 Windows: Secure Boot — вчера прошёл финальный AMA, June дедлайн через 6 недель

Коллеги, вчера 18 мая Microsoft провела последний AMA по Secure Boot перед июньским истечением сертификатов. Разбираем главное что прозвучало — и что нашли в майском обновлении.

Майское обновление Windows 11 (KB5089549) разместило на системах новую папку SecureBoot — это не вредонос, не ошибка установки. Это Microsoft размещает ресурсы для обновления Secure Boot, включая PowerShell-скрипты для определения статуса сертификатов и автоматизации развёртывания.

Главное с вчерашнего AMA:

Системы без новых сертификатов к июню 2026 войдут в деградированное состояние Secure Boot или не смогут загрузиться с BitLocker recovery prompts. Для отключённых устройств (lab machines, air-gapped) может потребоваться ручное вмешательство.

Один из участников поделился скриптом который сначала пытается установить Microsoft-обновление, при неудаче — делает fallback на OEM-пакет. AMA-команда одобрила подход, но предупредила: fallback нужно тщательно тестировать, так как неудачное обновление прошивки может окирпичить материнскую плату.

# Итоговая проверка статуса — прямо сейчас:
# Смотрим статус обновления сертификатов
Get-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
    -Name "UEFICA2023Status" -ErrorAction SilentlyContinue

# Значения:
# (отсутствует или пусто) = NOT_STARTED — нужно действовать
# "InProgress"            = в процессе
# "Updated"               = готово

# Массовый аудит парка серверов:
$servers = Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
    Select-Object -ExpandProperty Name

$results = foreach ($s in $servers) {
    try {
        Invoke-Command -ComputerName $s -ScriptBlock {
            $sb = Get-ItemProperty `
                -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
                -Name "UEFICA2023Status" -ErrorAction SilentlyContinue
            [PSCustomObject]@{
                Server = $env:COMPUTERNAME
                Status = if ($sb) { $sb.UEFICA2023Status } else { "NOT_STARTED" }
            }
        } -ErrorAction Stop
    } catch {
        [PSCustomObject]@{Server=$s; Status="UNREACHABLE"}
    }
}
$results | Group-Object Status | Format-Table Name, Count
$results | Where-Object {$_.Status -ne "Updated"} |
    Export-Csv "secureboot_todo.csv" -NoTypeInformation

# Для серверов с NOT_STARTED — запускаем обновление:
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# После перезагрузки — запустить ещё раз

# Также важно: обновляем dbx (список отозванных bootloader-ов)
# Проверяем текущий dbx через PowerShell модуль SecureBoot:
Confirm-SecureBootUEFI
Get-SecureBootUEFI -Name dbx

Зачем это критично до июня:
Обновление сертификатов — напоминание что обслуживание Windows теперь распространяется ниже уровня операционной системы. Patch Tuesday доставляет полезную нагрузку, но прошивка решает, может ли цепочка доверия принять и сохранить её.

Итог: шесть недель. Экспортируй CSV с NOT_STARTED серверами прямо сейчас — это твой план на эту неделю.

#windows #secureboot #pki #security #sysadmin #admin_future

🪟 Windows: AD CS в майском обновлении получил постквантовую криптографию — и это важнее чем звучит

Коллеги, в шуме вокруг Secure Boot, RC4 и Patch Tuesday почти никто не заметил кое-что важное в майском обновлении Windows Server 2025. Тихо и без фанфар.

Майское обновление добавляет в AD CS поддержку постквантовой криптографии: ML-DSA-44, ML-DSA-65 и ML-DSA-87 на Windows Server 2025. Это позволяет администраторам начать оценивать постквантовые криптографические алгоритмы и проверять PQC-готовность корпоративных PKI-сред.

Что это такое и зачем нам это сейчас:

Атака «harvest now, decrypt later» — не теория. Спецслужбы нескольких стран активно предупреждают, что противники уже сейчас эксфильтруют зашифрованные данные в расчёте на квантовое дешифрование в течение ближайшего десятилетия. Для любых данных с требованиями конфиденциальности более 10 лет — решение должно приниматься сейчас.

Как попробовать уже сегодня:

# ПРЕДВАРИТЕЛЬНЫЕ ТРЕБОВАНИЯ:
# Windows Server 2025 с майским обновлением KB5087539
# AD CS Certification Authority установлен и настроен

# Проверяем версию после обновления:
Get-ItemProperty `
    "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" |
    Select-Object CurrentBuild, UBR
# Нужен build 26100.32860 или выше

# Открываем Certificate Authority MMC:
# certsrv.msc -> [CA Name] -> Properties -> Cryptography

# Через PowerShell — проверяем доступные PQC-алгоритмы:
# (Нужен Provider Category: Key Storage Provider)
certutil -csplist | Select-String "ML-DSA"

# Создаём тестовый PQC-сертификат (code signing сценарий):
# 1. В CA Properties -> Cryptography -> CSP: Microsoft Software Key Storage Provider
# 2. Signature algorithm: ML-DSA-65 (оптимальный баланс размер/безопасность)
# 3. Выпускаем тестовый cert только для code signing

# ПРЕДУПРЕЖДЕНИЕ о размерах:
# ML-DSA-65 цепочка сертификатов: ~10KB vs ~1.5KB у ECDSA
# Это влияет на TLS handshake latency
# Пока НЕ для TLS, VPN, RDP — только для code signing и оценки

# Проверяем выпущенные PQC-сертификаты:
certutil -CAInfo
certutil -view -out "SerialNumber,NotBefore,NotAfter,Subject,PublicKey"

Что сейчас работает и что нет: ранние тесты показывают многообещающие результаты для сценариев подписи, таких как code signing. Однако более широкие инфраструктурные нагрузки, включая TLS, VPN и Remote Desktop, пока ограничены.

Зачем начинать сейчас если TLS/VPN ещё не готовы: организации, начинающие миграцию в 2026 году, имеют достаточно времени для соответствия срокам устаревания 2030 года. Те кто ждут 2028-го — столкнутся со сжатой высокорисковой миграцией.

Итог: не деплоить в продакшн. Поднять тестовую CA, выпустить ML-DSA-65 сертификат, посмотреть на размеры и latency. Это час работы — и понимание что тебя ждёт через 2-3 года.

#windows #adcs #pki #postquantum #security #sysadmin #admin_future

🔏 eMudhra: ключи восьми промежуточных CA оказались подбираемыми. Один из них буквально был числом 4

Коллеги, показательная история про архитектуру доверия PKI и слепые зоны автономных trust store в серверной инфраструктуре.

📌 ФАКТЫ
Удостоверяющий центр eMudhra отозвал 8 промежуточных сертификатов (6 для TLS и 2 для подписи кода под корнем emSign ECC Root CA - G3, кросс-подписанных Sectigo): закрытые ключи P-384, сгенерированные в апреле 2025 года, содержали катастрофически низкую энтропию

Криптография уровня велосипедного замка: вместо 384 бит случайности ключи представляли собой целые числа меньше 256 (3–8 бит). Закрытый ключ для EM OV TLS CA – G3C оказался буквально числом 4. Полный перебор на обычном ноутбуке занимает доли секунды

Причина: сбой служебного скрипта на этапе wrap/unwrap во время церемонии генерации ключей и ошибка сопоставления лейблов. Проблема оставалась незамеченной 17 месяцев и прошла через два аудита

Эксплуатация: исследователи обнаружили баг 17 октября 2026 года. Прямых фактов вредоносного выпуска в Certificate Transparency не зафиксировано, злоупотреблений в дикой природе пока не найдено

Реакция экосистемы: Chrome (CRLSet), Mozilla (OneCRL, отзыв корня G3, удаление в Firefox 158.0.1 / CVE-2026-113470), Apple и Microsoft заблокировали цепочки. На фоне инцидента eMudhra заявила об уходе с мирового рынка публичных TLS-сертификатов

Специфический фикс для Go 1.27.3 / 1.26.10 (CVE-2026-111943): встроенный верификатор crypto/x509 фильтрует скомпрометированные SPKI-хеши

🛠 ПРОВЕРКА И ПРАКТИЧЕСКИЕ ШАГИ
Браузеры блокируют такие цепочки на лету, но CLI-утилиты, скрипты, ран таймы и контейнеры обычно не проверяют списки отзыва (CRL/OCSP) и продолжают доверять скомпрометированным сертификатам, пока не обновлен сам bundle.

Bash

# 1. Обновляем системное хранилище доверенных корневых сертификатов
apt update && apt install --only-upgrade ca-certificates
update-ca-certificates 2>/dev/null || true

# 2. Тестовый запрос: проверяем, доверяет ли локальный curl скомпрометированной цепочке
# (Ожидаемый безопасный результат — ошибка SSL / HTTP 000, а не 200 OK)
curl -s -o /dev/null -w "%{http_code}\n" https://dv-g3b-emudhra.we-have-a-problem.com/

# 3. Аудит бинарников на Go (агенты мониторинга, CLI-инструменты, экспортеры)
# В них зашит встроенный движок x509:
go version -m /usr/local/bin/<ваша_утилита> | head -1

⚠️ ГДЕ ОСТАЁТСЯ РИСК
Docker-образы: контейнеры несут собственный /etc/ssl/certs/ca-certificates.crt, зашитый при сборке. apt upgrade на хосте их не защитит — необходим пересбор образов с ключом --pull --no-cache.

Изолированные runtime-пакеты: Node.js (22.23.4+ / 24.22.1+), Python (certifi), Java (cacerts), Rust (webpki-roots) тащат свои копии trust store.

Корпоративный софт и appliance: прошивки сетевого оборудования, VPN-шлюзы и внутренние утилиты, не имеющие автообновления бандлов.

💡 В ЧЁМ СУТЬ

Модель открытого PKI держится на презумпции криптографической стойкости корневых участников: ошибка одного вендора в private key автоматически ставит под угрозу весь HTTPS.

Поскольку сервера и пайплайны исторически игнорируют CRL/OCSP из соображений скорости и надежности сети, единственной защитой остается регулярная актуализация trust store в базовых ОС и пересборка контейнеров с подтягиванием свежих пакетов

ca-certificates

.

#pki #tls #certificates #security #go #sysadmin #admin_future