1:17 p.m.
Hi Rob,
I was trying to set up a configuration where certmonger would generate
and track a key in an NSS database with an HSM token. I used SoftHSMv2
for the token.
The script roughly describing what I did is attached. You need to put
SELinux in permissive as it would be messing up on certmonger's access.
On Rawhide it creates a private key in the HSM but unable to store a
public key of the certificate there. Rawhide has p11-kit proxy active
and that complicates things because any NSS db gets p11-kit-proxy.so
PKCS11 module injected via crypto-policy:
# cat /etc/crypto-policies/back-ends/nss.config
library=
name=Policy
NSS=flags=policyOnly,moduleDB
config="disallow=ALL
allow=HMAC-SHA256:HMAC-SHA1:HMAC-SHA384:HMAC-SHA512:SECP256R1:SECP384R1:SECP521R1:aes256-gcm:chacha20-poly1305:aes256-cbc:camellia256-cbc:aes128-gcm:aes128-cbc:camellia128-cbc:SHA256:SHA384:SHA512:SHA1:ECDHE-RSA:ECDHE-ECDSA:RSA:DHE-RSA:tls-version-min=tls1.0:dtls-version-min=dtls1.0:DH-MIN=1023:DSA-MIN=2048:RSA-MIN=2048"
name=p11-kit-proxy
library=p11-kit-proxy.so
when p11-kit-proxy.so is injected, it makes all configured PKCS11
modules available in all NSS databases. Even if my script tries to
insert an explicit PKCS11 module into the database used for a
certificate generation, I can skip that on Rawhide as p11-kit-proxy does
it for me:
# certutil -d sql:my-token -U
slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB
uri:
pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services
uri:
pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: SoftHSM slot ID 0x5489b984
token: HSM
uri:
pkcs11:token=HSM;manufacturer=SoftHSM%20project;serial=396d3e3c5489b984;model=SoftHSM%20v2
slot: SoftHSM slot ID 0x1cf72acc
token: my-token
uri:
pkcs11:token=my-token;manufacturer=SoftHSM%20project;serial=77cb41421cf72acc;model=SoftHSM%20v2
Anyway, even if I disable this injection with
NSS_IGNORE_SYSTEM_POLICY=1, it doesn't help because the environment
variable has to be specified for certmonger process too. I tried that as
well and it doesn't help, so there seems to be a bug with certmonger's
processing of PKCS11 modules in nss and p11-kit proxying is not really
changing that.
Certmonger is confused when it doesn't succeed in unlocking a token even
if it is a wrong token:
# certmonger -S -p /var/run/certmonger.pid -n -d 2
2018-08-21 17:42:15 [26673] Changing to root directory.
2018-08-21 17:42:15 [26673] Obtaining system lock.
2018-08-21 17:42:15 [26677] Token is named "NSS Generic Crypto Services", not
"NSS Certificate DB", skipping.
2018-08-21 17:42:15 [26677] Token is named "HSM", not "NSS Certificate
DB", skipping.
2018-08-21 17:42:15 [26677] Token is named "my-token", not "NSS Certificate
DB", skipping.
2018-08-21 17:42:15 [26678] Error authenticating to token "HSM".
2018-08-21 17:42:15 [26679] Error authenticating to cert db.
2018-08-21 17:42:15 [26679] Error authenticating to cert db.
2018-08-21 17:42:15 [26679] Error locating certificate.
2018-08-21 17:42:15 [26680] Token is named "NSS Certificate DB", not
"my-token", skipping.
2018-08-21 17:42:15 [26680] Token is named "HSM", not "my-token",
skipping.
2018-08-21 17:42:15 [26681] Token is named "NSS Certificate DB", not
"my-token", skipping.
2018-08-21 17:42:15 [26681] Token is named "NSS Generic Crypto Services", not
"my-token", skipping.
2018-08-21 17:42:15 [26681] Token is named "HSM", not "my-token",
skipping.
2018-08-21 17:42:15 [26681] Error locating certificate.
2018-08-21 17:42:17 [26733] Certificate "Local Signing Authority" valid for
29682906s.
2018-08-21 17:42:17 [26731] Error authenticating to token "HSM".
2018-08-21 17:42:20 [26673] No hooks set for pre-save command.
2018-08-21 17:42:21 [26750] PIN was not needed to auth to key store, though one was
provided. Treating this as an error.
2018-08-21 17:42:21 [26750] Error shutting down NSS.
Somehow, it doesn't see my token at all but still manages to store the
private key there. It then leaves the request in a state
NEED_CERTSAVE_PIN:
# getcert list -i 20180821173352
Number of certificates and requests being tracked: 4.
Request ID '20180821173352':
status: NEED_CERTSAVE_PIN
stuck: yes
key pair storage:
type=NSSDB,location='sql:/root/test-token/my-token',nickname='my-cert',token='my-token',pin
set
certificate:
type=NSSDB,location='sql:/root/test-token/my-token',nickname='my-cert',token='my-token'
CA: SelfSign
issuer:
subject:
expires: unknown
pre-save command:
post-save command:
track: yes
auto-renew: yes
If I look at the SoftHSMv2 token directly (via pkcs11-tool), I can see
that the key and the cert are both there:
# pkcs11-tool --module /usr/lib64/pkcs11/libsofthsm2.so --token-label my-token -l -p
Test1234 -O
Public Key Object; RSA 2048 bits
label:
ID: f9119ce98a883f7f75a72fb32faed0125b1b31a3
Usage: encrypt, verify, wrap
Private Key Object; RSA
label: my-cert
ID: f9119ce98a883f7f75a72fb32faed0125b1b31a3
Usage: decrypt, sign, unwrap
Using certutil I can also see the private key but not the public one there:
# certutil -d sql:my-token -L -h my-token
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
Enter Password or Pin for "my-token":
[root@ho-2 test-token]# certutil -d sql:my-token -K -h my-token
certutil: Checking token "my-token" in slot "SoftHSM slot ID
0x1cf72acc"
Enter Password or Pin for "my-token":
< 0> rsa f9119ce98a883f7f75a72fb32faed0125b1b31a3 my-cert
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
4:47 p.m.
Alexander Bokovoy via FreeIPA-devel wrote:
Hi Rob,
I was trying to set up a configuration where certmonger would generate
and track a key in an NSS database with an HSM token. I used SoftHSMv2
for the token.
The script roughly describing what I did is attached. You need to put
SELinux in permissive as it would be messing up on certmonger's access.
On Rawhide it creates a private key in the HSM but unable to store a
public key of the certificate there. Rawhide has p11-kit proxy active
and that complicates things because any NSS db gets p11-kit-proxy.so
PKCS11 module injected via crypto-policy:
# cat /etc/crypto-policies/back-ends/nss.config
library=
name=Policy
NSS=flags=policyOnly,moduleDB
config="disallow=ALL
allow=HMAC-SHA256:HMAC-SHA1:HMAC-SHA384:HMAC-SHA512:SECP256R1:SECP384R1:SECP521R1:aes256-gcm:chacha20-poly1305:aes256-cbc:camellia256-cbc:aes128-gcm:aes128-cbc:camellia128-cbc:SHA256:SHA384:SHA512:SHA1:ECDHE-RSA:ECDHE-ECDSA:RSA:DHE-RSA:tls-version-min=tls1.0:dtls-version-min=dtls1.0:DH-MIN=1023:DSA-MIN=2048:RSA-MIN=2048"
name=p11-kit-proxy
library=p11-kit-proxy.so
when p11-kit-proxy.so is injected, it makes all configured PKCS11
modules available in all NSS databases. Even if my script tries to
insert an explicit PKCS11 module into the database used for a
certificate generation, I can skip that on Rawhide as p11-kit-proxy does
it for me:
# certutil -d sql:my-token -U
slot: NSS User Private Key and Certificate Services
token: NSS Certificate DB
uri:
pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: NSS Internal Cryptographic Services
token: NSS Generic Crypto Services
uri:
pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
slot: SoftHSM slot ID 0x5489b984
token: HSM
uri:
pkcs11:token=HSM;manufacturer=SoftHSM%20project;serial=396d3e3c5489b984;model=SoftHSM%20v2
slot: SoftHSM slot ID 0x1cf72acc
token: my-token
uri:
pkcs11:token=my-token;manufacturer=SoftHSM%20project;serial=77cb41421cf72acc;model=SoftHSM%20v2
Anyway, even if I disable this injection with
NSS_IGNORE_SYSTEM_POLICY=1, it doesn't help because the environment
variable has to be specified for certmonger process too. I tried that as
well and it doesn't help, so there seems to be a bug with certmonger's
processing of PKCS11 modules in nss and p11-kit proxying is not really
changing that.
Certmonger is confused when it doesn't succeed in unlocking a token even
if it is a wrong token:
# certmonger -S -p /var/run/certmonger.pid -n -d 2
2018-08-21 17:42:15 [26673] Changing to root directory.
2018-08-21 17:42:15 [26673] Obtaining system lock.
2018-08-21 17:42:15 [26677] Token is named "NSS Generic Crypto
Services", not "NSS Certificate DB", skipping.
2018-08-21 17:42:15 [26677] Token is named "HSM", not "NSS Certificate
DB", skipping.
2018-08-21 17:42:15 [26677] Token is named "my-token", not "NSS
Certificate DB", skipping.
2018-08-21 17:42:15 [26678] Error authenticating to token "HSM".
2018-08-21 17:42:15 [26679] Error authenticating to cert db.
2018-08-21 17:42:15 [26679] Error authenticating to cert db.
2018-08-21 17:42:15 [26679] Error locating certificate.
2018-08-21 17:42:15 [26680] Token is named "NSS Certificate DB", not
"my-token", skipping.
2018-08-21 17:42:15 [26680] Token is named "HSM", not "my-token",
skipping.
2018-08-21 17:42:15 [26681] Token is named "NSS Certificate DB", not
"my-token", skipping.
2018-08-21 17:42:15 [26681] Token is named "NSS Generic Crypto
Services", not "my-token", skipping.
2018-08-21 17:42:15 [26681] Token is named "HSM", not "my-token",
skipping.
2018-08-21 17:42:15 [26681] Error locating certificate.
2018-08-21 17:42:17 [26733] Certificate "Local Signing Authority" valid
for 29682906s.
2018-08-21 17:42:17 [26731] Error authenticating to token "HSM".
2018-08-21 17:42:20 [26673] No hooks set for pre-save command.
2018-08-21 17:42:21 [26750] PIN was not needed to auth to key store,
though one was provided. Treating this as an error.
2018-08-21 17:42:21 [26750] Error shutting down NSS.
Somehow, it doesn't see my token at all but still manages to store the
private key there. It then leaves the request in a state
NEED_CERTSAVE_PIN:
# getcert list -i 20180821173352
Number of certificates and requests being tracked: 4.
Request ID '20180821173352':
status: NEED_CERTSAVE_PIN
stuck: yes
key pair storage:
type=NSSDB,location='sql:/root/test-token/my-token',nickname='my-cert',token='my-token',pin
set
certificate:
type=NSSDB,location='sql:/root/test-token/my-token',nickname='my-cert',token='my-token'
CA: SelfSign
issuer: subject: expires: unknown
pre-save command: post-save command: track: yes
auto-renew: yes
If I look at the SoftHSMv2 token directly (via pkcs11-tool), I can see
that the key and the cert are both there:
# pkcs11-tool --module /usr/lib64/pkcs11/libsofthsm2.so --token-label
my-token -l -p Test1234 -O
Public Key Object; RSA 2048 bits
label: ID: f9119ce98a883f7f75a72fb32faed0125b1b31a3
Usage: encrypt, verify, wrap
Private Key Object; RSA label: my-cert
ID: f9119ce98a883f7f75a72fb32faed0125b1b31a3
Usage: decrypt, sign, unwrap
Using certutil I can also see the private key but not the public one there:
# certutil -d sql:my-token -L -h my-token
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
Enter Password or Pin for "my-token":
[root@ho-2 test-token]# certutil -d sql:my-token -K -h my-token
certutil: Checking token "my-token" in slot "SoftHSM slot ID
0x1cf72acc"
Enter Password or Pin for "my-token":
< 0> rsa f9119ce98a883f7f75a72fb32faed0125b1b31a3 my-cert
Thanks for the script, easily reproducible.
I'm not sure why Nalin makes it a requirement to authenticate to the
token to write a certificate. It shouldn't be mandatory AFAIK.
I changed SelfSign to local so that I could have a CA associated with
the cert for validation purposes.
I tested with a build that ifdef'd that bit of code out and a cert is
written but it is written to the sql database and not to the token.
Maybe this is ok. AFAIR NSS is just fine mixing its own database with
the contents of tokens but this isn't expected and of course the trust
flags are ,, because the key isn't in the same place as the cert. It
verifies ok though if I add the local CA to the NSS database.
I'll keep poking at it.
rob
4:36 p.m.
Rob Crittenden via FreeIPA-devel wrote:
Alexander Bokovoy via FreeIPA-devel wrote:
< 0> rsa f9119ce98a883f7f75a72fb32faed0125b1b31a3 my-cert
Thanks for the script, easily reproducible.
I'm not sure why Nalin makes it a requirement to authenticate to the
token to write a certificate. It shouldn't be mandatory AFAIK.
I changed SelfSign to local so that I could have a CA associated with
the cert for validation purposes.
I tested with a build that ifdef'd that bit of code out and a cert is
written but it is written to the sql database and not to the token.
Maybe this is ok. AFAIR NSS is just fine mixing its own database with
the contents of tokens but this isn't expected and of course the trust
flags are ,, because the key isn't in the same place as the cert. It
verifies ok though if I add the local CA to the NSS database.
I have the basics in place so the cert is written to a token but I have
a ton more testing to do.
I also noticed that the issuer, subject and expiration dates aren't
being set in at least the local ca. I need to determine if that is due
to my patches or another bug.
rob
12:51 a.m.
On ke, 22 elo 2018, Rob Crittenden wrote:
Rob Crittenden via FreeIPA-devel wrote:
> Alexander Bokovoy via FreeIPA-devel wrote:
> < 0> rsa f9119ce98a883f7f75a72fb32faed0125b1b31a3 my-cert
>
> Thanks for the script, easily reproducible.
>
> I'm not sure why Nalin makes it a requirement to authenticate to the
> token to write a certificate. It shouldn't be mandatory AFAIK.
>
> I changed SelfSign to local so that I could have a CA associated with
> the cert for validation purposes.
>
> I tested with a build that ifdef'd that bit of code out and a cert is
> written but it is written to the sql database and not to the token.
> Maybe this is ok. AFAIR NSS is just fine mixing its own database with
> the contents of tokens but this isn't expected and of course the trust
> flags are ,, because the key isn't in the same place as the cert. It
> verifies ok though if I add the local CA to the NSS database.
I have the basics in place so the cert is written to a token but I have
a ton more testing to do.
Thanks.
I also noticed that the issuer, subject and expiration dates
aren't
being set in at least the local ca. I need to determine if that is due
to my patches or another bug.
A bit weird, indeed. I haven't noticed that
failing in my past tests.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
2070
days inactive
2072
days old
freeipa-devel@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
Alexander Bokovoy -
Rob Crittenden