5 Lis
2018
5 Lis
'18
17:47
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.
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 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: "" [daniel.salzman(a)nic.cz]
Date: 11/02/2018 05:39 AM
To: "Full Name" <nuncestbibendum(a)excite.com>
CC: knot-dns-users(a)lists.nic.cz
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.