On 2018-11-05 17:47, Full Name wrote:
I am sorry; I made a mistake when pasting the knot.conf contents here
- I am using the module path all right, and it makes no difference. In
fact, the issue seems to be with the knot.conf parser - be it because
I am doing things incorrectly myself, or because it is broken. I have
noticed the same in Knot 2.6.9 and 2.7.3.
So what is your exact configuration of the keystore?
Can anyone throw some light on this? What else has one got to do to
get Knot to use the PKCS #11 interface for the key store? I have the
necessary library (softHSM) plus the correct data in knot.conf. But
the keymgr function is not using the PKCS #11 interface. What am I
missing?
I think you have to learn how to initialize a PKCS #11 token first.
Try something like:
export SOFTHSM2_CONF=/path/to//softhsm.conf
softhsm2-util --init-token --slot=0 --label="knot" --pin=1234
--so-pin=12345 --module=/usr/lib/softhsm/libsofthsm2.so
and follow https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#config
...
I provided some debugging traces in a separate message to
illustrate the issue. I'll be happy to furnish more data, if somebody
knowledgeable on the Knot internals lets me know what traces to
provide. I really need to be able to get Knot to use the PKCS #11
interface.
-----Original Message-----
From: "" [[email protected]]
Date: 11/02/2018 05:39 AM
To: "Full Name" <[email protected]>
CC: [email protected]
Subject: Re: [knot-dns-users] Knot refusing to use the PKCS #11
interface
Hello Full Name,
The pkcs11 keystore configuration should have the form of
"<pkcs11-url> <module-path>". I will improve the documentation.
Daniel
On 2018-11-01 18:04, Full Name wrote:
I have a knot.conf file with the following keystore section:
keystore:
- id: TheBackend
backend: pkcs11
config:
"pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System
Trust"
where the value assigned to the config keyword is obtained from the
output from the GnuTLS p11tool command:
$ p11tool --list-tokens
Token 0:
URL:
pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
Label: System Trust
Type: Trust module
Flags: uPIN uninitialized
Manufacturer: PKCS#11 Kit
Model: p11-kit-trust
Serial: 1
Module: p11-kit-trust.so
Also in knot.conf I have
policy:
- id: manual
manual: on
zone:
- domain: example.com
storage: /var/lib/knot/zones/
file: example.com.zone
dnssec-signing: on
dnssec-policy: manual
With all this in place, I launched the following from the CLI:
# keymgr example.com. generate algorithm=ECDSAP256SHA256
This does not seem to be using the PKCS #11 library, as instructed in
knot.conf. I debugged the command above and noticed that, at some
before the signing operation itself is addressed, the keystore_load
function from the Knot code base is invoked. This function takes
several arguments, the second of which is a backend identifier.
According to the keystore entry in knot.conf, this should be the PKCS
#11 identifier KEYSTORE_BACKEND_PKCS11. However, what I see with the
debugger is that the backend argument is, in fact,
KEYSTORE_BACKEND_PEM.
Even more intriguing (to somebody unfamiliar with the internal
workings of Knot, at least) is that, before keystore_load is invoked,
the check_keystore function is invoked and it evaluates the following
conditional:
if (conf_opt(&backend) == KEYSTORE_BACKEND_PKCS11 &&
conf_str(&config) == NULL)
This conditional clearly succeeds - i.e. at that point the backend has
been correctly identified as PKCS #11. But, like I said above, when
keystore_load gets called later on, such is not the case any longer.
Any idea as to what is going on here? Why is PKCS #11 not being used?
In the config string above in knot.conf I tried replacing %23 and %20
with # and the space character, respectively. It made no difference.
This all is happening with Knot 2.7.3.
--
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
