Клиент VPN Windows Native с Yubikey PIV иногда вызывает сбой на стороне клиента EAP-TLS. Фатальная ошибка TLS ‘доступ запрещен’ и ошибка сбоя рукопожатия TLS 40.

У нас действительно неудобная проблема с следующим

Настройка выглядит так:

Клиентская сторона

• Клиент Windows 11 23H2
• Нативный клиент Windows VPN с использованием следующей конфигурации VPN
• Установлен Yubikey Minidriver (пробовали без него, то же самое)
• Yubikey 5C NFC с прошивкой 5.7.1

Серверная сторона

• Debian 12 Strongswan 5.9.8 с swanctl (конфигурация ниже; все
  сертификаты действительны и доверены)

У нас есть два Windows клиента (одинаковый образ), два Yubikey и несколько выданных сертификатов от одного ЦС. Некоторые с ключами RSA 2048 бит, некоторые с 4096 (оба поддерживаются с Yubikey прошивкой 5.7.1 и Windows и уже известны как работающие, так как мы можем подключиться с обоими типами иногда)

Проблема совершенно случайна (для нас), поэтому происходит такое:

Сценарий A

• Сертификат пользователя A загружен на Yubikey A и используется с клиентом A для подключения через IPSec -> Все работает нормально; Соединение IPSec успешно
• Тот же сертификат A загружен на Yubikey B и используется с клиентом B для подключения -> Соединение не удалось

Сценарий B

• Сертификат пользователя B (тот же ЦС, другой CN) загружен на Yubikey B и используется с клиентом B для подключения -> соединение успешно
• Сертификат пользователя B загружен на Yubikey A и используется с клиентом A для подключения -> соединение не удалось

Сценарий C

• Сертификат пользователя C (тот же ЦС, другой CN) загружен на Yubikey A и используется с клиентом A для подключения -> соединение не удалось
• Сертификат пользователя C загружен на Yubikey B и используется с клиентом B для подключения -> соединение не удалось

Самое странное, что это может меняться со временем. В один день конфигурация (например, сертификат A загружен на Yubikey A, использованный на клиенте A), которая ранее не работала, может внезапно заработать, даже если раньше этого не происходило.

В strongswan это сообщение появляется, указывая, что клиент EAP-TLS (устройство Windows) сбросил соединение с фатальной tls-ошибкой. До этого момента логи идентичны рабочей попытке:

Журнал Strongswan

2024-12-09T10:35:22.392364+01:00 debian charon-systemd[15870]: 05[ENC] разобран запрос IKE_AUTH 7 [ EAP/RES/TLS ]
2024-12-09T10:35:22.392440+01:00 debian charon-systemd[15870]: 05[TLS] EAP_TLS полезная нагрузка => 17 байт @ 0x7f704c05d8a0
2024-12-09T10:35:22.392494+01:00 debian charon-systemd[15870]: 05[TLS]    0: 02 D4 00 11 0D 80 00 00 00 07 15 03 03 00 02 02  ................
2024-12-09T10:35:22.392546+01:00 debian charon-systemd[15870]: 05[TLS]   16: 31                                               1
2024-12-09T10:35:22.392625+01:00 debian charon-systemd[15870]: 05[TLS] обработка записи TLS Alert (2 байта)
2024-12-09T10:35:22.392700+01:00 debian charon-systemd[15870]: 05[TLS] получен фатальный TLS сигнал 'доступ запрещен'
2024-12-09T10:35:22.392765+01:00 debian charon-systemd[15870]: 05[IKE] Метод EAP EAP_TLS завершился неудачно для пира 192.168.30.114
2024-12-09T10:35:22.392841+01:00 debian charon-systemd[15870]: 05[ENC] генерирование ответа IKE_AUTH 7 [ EAP/FAIL ]
2024-12-09T10:35:22.392908+01:00 debian charon-systemd[15870]: 05[NET] отправка пакета: от 192.168.30.116[4500] до 192.168.30.1[64917] (88 байт)
2024-12-09T10:35:22.392985+01:00 debian charon-systemd[15870]: 05[IKE] IKE_SA eap-tls[9078] изменение состояния: CONNECTING => DESTROYING
2024-12-09T10:35:22.393082+01:00 debian charon-systemd[15870]: полученный пакет: от 192.168.30.1[64917] до 192.168.30.116[4500] (104 байта)
2024-12-09T10:35:22.393214+01:00 debian charon-systemd[15870]: разобран запрос IKE_AUTH 7 [ EAP/RES/TLS ]
2024-12-09T10:35:22.393292+01:00 debian charon-systemd[15870]: получен фатальный TLS сигнал 'доступ запрещен'
2024-12-09T10:35:22.393403+01:00 debian charon-systemd[15870]: Метод EAP EAP_TLS завершился неудачно для пира 192.168.30.114
2024-12-09T10:35:22.393491+01:00 debian charon-systemd[15870]: генерирование ответа IKE_AUTH 7 [ EAP/FAIL ]
2024-12-09T10:35:22.393580+01:00 debian charon-systemd[15870]: отправка пакета: от 192.168.30.116[4500] до 192.168.30.1[64917] (88 байт)

Журналы SCHANNEL Windows

Журналы SCHANNEL показывают, как используется Microsoft Base Smart Card Crypto Provider, но процесс завершается с ошибкой.

Информация 12/9/2024 10:45:18 Schannel 36867 None
Создается клиентский сертификат TLS.
процесс клиента SSPI svchost[EapHost] (PID: 5776).
Информация 12/9/2024 10:45:18 Schannel 36868 None
У клиентского сертификата TLS открытый ключ следующие свойства:
Имя CSP: Microsoft Base Smart Card Crypto Provider
Тип CSP: 1
Имя ключа: 7d6ba0cb-8ab2-36e4-325b-bf23475fc105
Тип ключа: обмен ключами
Идентификатор ключа: 0x0
Приложенные данные содержат сертификат.
Информация 12/9/2024 10:45:18 Schannel 36888 None 

Сгенерирован и отправлен фатальный сигнал на удалённую конечную точку. 
Это может привести к завершению соединения. 
Фатальный сигнал, определенный протоколом TLS, имеет следующий код: 40. 

Имя цели:
Процесс клиента SSPI является svchost[EapHost] (PID: 5776).
Регистратор сигналов TLS находится по адресу: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-6

Что странно, потому что, когда соединение успешно, журнал schannel показывает, что вместо “Microsoft Base SmartCard Crypto Provider” используется “Microsoft Smart Card Key Storage Provider”, как показано ниже:

Информация 12/9/2024 10:45:18 Schannel 36867 None
Создается клиентский сертификат TLS.
процесс клиента SSPI svchost[EapHost] (PID: 5776).
Информация 12/9/2024 10:48:44 Schannel 36868 None
У клиентского сертификата TLS открытый ключ следующие свойства:
Имя CSP: Microsoft Smart Card Key Storage Provider
Тип CSP: 0
Имя ключа: 72c27e3d-737e-301e-c312-23a1ef5fc105
Тип ключа: н/д
Флаг ключа: 0x0
Приложенные данные содержат сертификат.
Информация 12/9/2024 10:48:46 AM Schannel 36880 None
Клиентское согласование для TLS было выполнено успешно. Переговоренные криптографические параметры:
Версия протокола: TLS 1.2
CipherSuite: 0xC030
Сила обмена: 384 бита
Контекстный дескриптор: 0x1defdf9c800
Имя цели:
Локальное имя субъекта сертификата: CN=######
Удаленное имя субъекта сертификата: CN=#######

Мы не знаем, что вызывает это случайное поведение, и надеемся, что вы сможете нам помочь. Нет никаких признаков того, что Yubikey или сервер strongswan делают что-то неправильно, вместо этого Microsoft, кажется, случайно решает, когда действительно отправляет закрытый ключ, используя провайдер хранения ключей должным образом.

Спасибо заранее за любую помощь.

Настройки VPN Windows

Имя                  : test
АдресСервера         : #########
ОбщийПользовательскийСоединение     : Ложь
GUID                  : {4E1CF7BC-B9B7-42BC-AC55-159E3143806E}
ТипТуннеля            : Ikev2
МетодАутентификации  : {Eap}
УровеньШифрования       : Пользовательский
L2tpIPsecAuth         :
ИспользоватьКреденциалыWinlogon : Ложь
EapConfigXmlStream    : #документ
СтатусСоединения      : Отключено
ЗапомнитьКреденциалы    : Ложь
РазделенноеТуннелирование        : Истина
DnsSuffix             :
IdleDisconnectSeconds : 0
AuthenticationTransformConstants : SHA256128
CipherTransformConstants         : AES256
DHGroup                          : ECP384
IntegrityCheckMethod             : SHA384
PfsGroup                         : ECP384
МетодШифрования                 : AES256

Strongswan

connections {
  eap-tls {
    pools = ipv4
    local {
      auth = pubkey
      certs = servercert.pem
      id = ###############
    }
    remote {
      auth = eap-tls
      cacerts = cacertificate.pem
      eap_id = %any
    }
    children {
      eap-tls {
        local_ts = 0.0.0.0/0
        esp_proposals = aes256-sha256
       }
    }
  }
}
pools {
  ipv4 {
    addrs = 10.10.1.64/26
  }
}