libykcs11.dll: inside generated certificates and attestation certificates are listed with the same pkcs11-id

[denisgrilliGMSL]

I am trying to use openvpn with the pkcs11 provider libykcs11.. When I run the command: "openvpn.exe" --show-pkcs11-ids "c:\Program Files\Yubico\Yubico PIV Tool\bin\libykcs11.dll"
I can see that both my certificate and its attestation certificate are having the same pkcs11-id.
Trying to use that id will end up on openvpn to pick the attestation certificate instead of the actual one and of course failing to connect.
Using the opensc implementation of the pkcs11 provider does not have the same problem.

Openvpn 2.6.6
Yubico-piv-tool 2.3.1
Yubikey minidriver 4.11.210

Windows 11 22H2 running on laptop (no VM or RDP involved)
Yubikey 5 NFC

I have already spoken with the yubico support which suggest to be a bug that need to be reported here.

[qpernil]

The spec says that any 'related' objects should use the same id, but in practice it seems most software expects to find just one certificate when searching by id. So I agree we should probably fix this. One idea would be to add, say, 100 to the id for the attestation certificate.

[denisgrilliGMSL]

I don't see how a software can select between multiple certificates with the same id considering that is the only field considered unique so I second the idea to add something to the id to identify the attestation certificates.

To be also precise, opensc implementation does not actually shows any attestation certificates at all, so I am not sure if they somehow filter them out or because they "just look" at specific slots.

[qpernil]

Attestation certificates are actually not 'real' certificates, they are generated when you open the first session to a slot. This is a feature of the module. They will therefore not be marked as token objects, so if the software searches only for token objects (CKA_TOKEN == CK_TRUE) with the proper CKA_ID they will not find the attestation certificate. But apparently openvpn doesn't do that so it is not that helpful in this case. Possibly a change request towards openvpn ?

[e100]

I've been using openvpn this way for years but we generate our keys in an offline CA, not inside the yubikey, so the attestation certificate is not associated with my keys. Might explain why I do not have this issue.

@denisgrilliGMSL you mentioned openvpn.exe so I'm assuming you are using openvpn on windows?
Another solution on windows is to use cryptoapicert instead of ykcs11, requires just a single line in the openvpn config:

cryptoapicert 'SUBJ:[email protected] 

We have multiple certs with the same subject on our keys and the above works fine for us, it always uses the correct slot and is much easier to setup.

[qpernil]

Maybe request a change in OpenVPN where they only search for CKA_TOKEN=CK_TRUE certificates ?

[qpernil]

On the subject that OpenSC doesn't show certificates - Attestation certificates are not stored on the device, they are dynamically generated by the attestation command supported by YubiKeys. This is outside thePIV spec, so might not be supported / used by OpenSC. libykcs11 does request attestations for every PIV key when the first session is opened to a pkcs11 slot (a YubiKey). This attestation contains the public key (and we fall back to the metadata command if attestation fails) so we can return the correct public for any keys slot regardless of the certificate stored for that key (or not stored..). Since we do this anyway we decided to also make the attestation certificate visible to users of libykcs11. To indicate it is not a stored certificate we set CKA_TOKEN=CK_FALSE for those certificates.

[qpernil]

As a pkcs11 client you could either filter certificates by CKA_TOKEN=CK_TRUE to skip the attestations altogether, or get that attribute for every certificate, and manually handle them differently.