We have a really awkward issue with thw following
The setup looks like this:
- Client Side
- Windows 11 Client 23H2
- Windows Native Client using the below configuration
- Installed Yubikey Minidriver (tried without it too, same thing)
- Yubikey 5C NFC with Firmware 5.7.1
- Server Side
- Debian 12
- Strongswan 5.9.8 with swanctl (config below; all certificates valid and trusted)
We have 2 Windows Clients (same image), 2 Yubikeys and multiple issued certificates from the same CA. Some with 2048 Bit RSA keys some with 4096 (both are supported with yubikey firmware 5.7.1 and windows and are known to work as we can connect with both types sometimes)
The issue is completly random (to us) so stuff like below is happening:
- Scenario A:
- User Certificate A is loaded on Yubikey A and used with client A to connect via IPSec -> Everything works fine; IPSec Connection is succesfull
- Same Certificate A is loaded to Yubikey B and used with client B to connect -> Connection fails
- Scenario B:
- User Certificate B (same CA other CN) is loaded on Yubikey B and used with client B to connect -> connection sucessfull
- User Certificate B is loaded to Yubikey A and used with Client A to connection -> connection fails
- Scenario C
- User Certificate C (same CA other CN) is loaded on Yubikey A and used with client A to connect -> connection fails
- User Certificate C is loaded to Yubikey B and used with Client B to connection -> connection fails
The most awkward thing is this can change over time. On one day a certificate that previously hasnt been working on client A yubikey A might suddenly work even though it didnt before.
In strongswan this message pops up indicating the eaptls client (windows device) reset the connection with a fatal tls alert. Up to that point the logs are identical to a working try:
Strongswan log
2024-12-09T10:35:22.392364+01:00 debian charon-systemd[15870]: 05[ENC] parsed IKE_AUTH request 7 [ EAP/RES/TLS ]
2024-12-09T10:35:22.392440+01:00 debian charon-systemd[15870]: 05[TLS] EAP_TLS payload => 17 bytes @ 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] processing TLS Alert record (2 bytes)
2024-12-09T10:35:22.392700+01:00 debian charon-systemd[15870]: 05[TLS] received fatal TLS alert 'access denied'
2024-12-09T10:35:22.392765+01:00 debian charon-systemd[15870]: 05[IKE] EAP method EAP_TLS failed for peer 192.168.30.114
2024-12-09T10:35:22.392841+01:00 debian charon-systemd[15870]: 05[ENC] generating IKE_AUTH response 7 [ EAP/FAIL ]
2024-12-09T10:35:22.392908+01:00 debian charon-systemd[15870]: 05[NET] sending packet: from 192.168.30.116[4500] to 192.168.30.1[64917] (88 bytes)
2024-12-09T10:35:22.392985+01:00 debian charon-systemd[15870]: 05[IKE] IKE_SA eap-tls[9078] state change: CONNECTING => DESTROYING
2024-12-09T10:35:22.393082+01:00 debian charon-systemd[15870]: received packet: from 192.168.30.1[64917] to 192.168.30.116[4500] (104 bytes)
2024-12-09T10:35:22.393214+01:00 debian charon-systemd[15870]: parsed IKE_AUTH request 7 [ EAP/RES/TLS ]
2024-12-09T10:35:22.393292+01:00 debian charon-systemd[15870]: received fatal TLS alert 'access denied'
2024-12-09T10:35:22.393403+01:00 debian charon-systemd[15870]: EAP method EAP_TLS failed for peer 192.168.30.114
2024-12-09T10:35:22.393491+01:00 debian charon-systemd[15870]: generating IKE_AUTH response 7 [ EAP/FAIL ]
2024-12-09T10:35:22.393580+01:00 debian charon-systemd[15870]: sending packet: from 192.168.30.116[4500] to 192.168.30.1[64917] (88 bytes)
In the windows schannel logs this appears when the connection fails
Informationen 09.12.2024 10:45:18 Schannel 36867 Keine
Eine TLS-Client Anmelde Informationen werden erstellt.
der SSPI-Client Prozess svchost[EapHost] (PID: 5776).
Informationen 09.12.2024 10:45:18 Schannel 36868 Keine
Der private Schlüssel der Client-Anmeldeinformationen für TLS besitzt folgende Eigenschaften:
CSP-Name: Microsoft Base Smart Card Crypto Provider
CSP-Typ: 1
Schlüsselname: 7d6ba0cb-8ab2-36e4-325b-bf23475fc105
Schlüsseltyp: key exchange
Schlüsselkennzeichen: 0x0
Die angefügten Daten enthalten das Zertifikat.
Informationen 09.12.2024 10:45:18 Schannel 36888 Keine
Es wurde eine schwerwiegende Warnung generiert und an den Remoteendpunkt gesendet. Dies kann dazu führen, dass die Verbindung beendet wird. Die vom TLS-Protokoll definierte schwerwiegende Warnung hat folgenden Code: 40.
Zielname:
Der SSPI-Clientprozess ist svchost[EapHost] (PID: 5776).
Die Registrierung von TLS-Warnungen befindet sich unter: http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-6
Which is awkward because when the connection is sucessful schannel log is showing that instead of "Microsoft Base SmartCard Crypto Provider" the "Microsoft Smart Card Key Storage Provider" is used like this
Informationen 09.12.2024 10:45:18 Schannel 36867 Keine
Eine TLS-Client Anmelde Informationen werden erstellt.
der SSPI-Client Prozess svchost[EapHost] (PID: 5776).
Informationen 09.12.2024 10:48:44 Schannel 36868 Keine
Der private Schlüssel der Client-Anmeldeinformationen für TLS besitzt folgende Eigenschaften:
CSP-Name: Microsoft Smart Card Key Storage Provider
CSP-Typ: 0
Schlüsselname: 72c27e3d-737e-301e-c312-23a1ef5fc105
Schlüsseltyp: N/A
Schlüsselkennzeichen: 0x0
Die angefügten Daten enthalten das Zertifikat.
Informationen 09.12.2024 10:48:46 Schannel 36880 Keine
Ein Client-Handshake für TLS wurde erfolgreich ausgeführt. Die ausgehandelten kryptografischen Parameter sind:
Protokollversion: TLS 1.2
CipherSuite: 0xC030
Austauschstärke: 384 Bits
Kontexthandle: 0x1defdf9c800
Zielname:
Name des Antragstellers für das lokale Zertifikat: CN=######
Name des Antragstellers für das Remotezertifikat: CN=########
We dont know what this random behaviour is caused by, and hoped you guys can help us out. There's nothing indicating the yubikey or strongswan server are doing something wrong instead microsoft seems to randomly decide when it really sends out the private key using the key storage provider properly.
Thank you in advance for any kind of help.
VPN Settings Windows
Name : test
ServerAddress : #########
AllUserConnection : False
Guid : {4E1CF7BC-B9B7-42BC-AC55-159E3143806E}
TunnelType : Ikev2
AuthenticationMethod : {Eap}
EncryptionLevel : Custom
L2tpIPsecAuth :
UseWinlogonCredential : False
EapConfigXmlStream : #document
ConnectionStatus : Disconnected
RememberCredential : False
SplitTunneling : True
DnsSuffix :
IdleDisconnectSeconds : 0
AuthenticationTransformConstants : SHA256128
CipherTransformConstants : AES256
DHGroup : ECP384
IntegrityCheckMethod : SHA384
PfsGroup : ECP384
EncryptionMethod : 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
}
}
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
