Mailing List Archive: Using gpgsm+scute with p11tool

Hi all,

I'm trying to get 2FA HTTP client authentication working with a YubiKey
5 hardware token at my workplace.

I currently already have the YubiKey working successfully with GnuPG
2.2 in OpenPGP mode for two-factor SSH authentication and git code
signing. Aside from a few niggles (like not being able to use two
YubiKeys simultaneously, something GnuPG 2.3 should resolve if I can
get it working right), things have been pretty smooth.

I had `curl` working via OpenSC's PKCS#11 support, but this clashes
with GnuPG, one must re-plug the YubiKey after accessing it via OpenSC,
which gets annoying. It's been suggested I look at `scute` instead.

The HTTP request I need to perform is this one:
https://www.vaultproject.io/docs/auth/cert#via-the-api

I tried using Firefox, it can see the certificate presented by `scute`,
but it seems Vault isn't designed to authenticate clients that way as
best I can tell.

Using OpenSC PKCS#11, I can do something like this:

$ curl -E 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=<snip>;token=<snip>;id=%07;object=<snip>;type=cert' --insecure --data '{"name": "me"}' https://tls.server.example.com:8200/v1/auth/cert/login

I can see what tokens exist with `p11tool`:

$ p11tool --provider=/usr/lib64/pkcs11/opensc-pkcs11.so --list-tokens
Token 0:
URL: pkcs11:model=<snip>;token=PIV_II
Label: PIV_II
Type: Hardware token
Flags: RNG, Requires login
Manufacturer: piv_II
Model: <snip>
Serial: <snip>
Module:

If I try doing the same with `scute`, I get nothing:

$ p11tool --provider=/usr/lib64/pkcs11/scute.so --list-tokens

Consequently, I have no idea what hardware token URI to supply to
`curl` when authenticating.

Is there some trick needed to get `scute` to tell me what tokens are
present or how to find out what the URL of my private key is?

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hi,

On Mon, Nov 08, 2021 at 02:45:53PM +1000, Stuart Longland via Gnupg-users wrote:
>The HTTP request I need to perform is this one:
>https://www.vaultproject.io/docs/auth/cert#via-the-api
>
>I tried using Firefox, it can see the certificate presented by `scute`,
>but it seems Vault isn't designed to authenticate clients that way as
>best I can tell.

As long as the server allows certificate-based client authentication, it
shouldn’t matter to the server that you are using Scute (or any other
way to store your certificate) at your end.

However, usage of Scute + Firefox seems broken with TLS 1.3. In my case,
it works perfectly fine if I force Firefox to use TLS 1.2
(security.tls.version.max = 3 in about:config), but systematically fails
when TLS 1.3 is enabled.

I am not sure about the root cause of the failure with TLS 1.3, or even
if the root cause is in Scute itself or in Firefox.

Could you try temporarily disable TLS 1.3 and try again? If it works
with TLS 1.2 only, this would suggest you are running into the same
problem as me.

>If I try doing the same with `scute`, I get nothing:
>
>$ p11tool --provider=/usr/lib64/pkcs11/scute.so --list-tokens
>
>Consequently, I have no idea what hardware token URI to supply to
>`curl` when authenticating.
>
>Is there some trick needed to get `scute` to tell me what tokens are
>present or how to find out what the URL of my private key is?

I would need to look at how is p11tool generating its output, but I
suspect it may be using some PKCS#11 functions that Scute does not
currently implement.

- Damien

Mailing List Archive

Mailing List Archive

Attached Files: