convert Knot DNS sigantures certs to BIND format.

Thu Mar 14 16:01:46 UTC 2019

Hello Tony,

ok, I did exactly what you adviced.

Now I´m able to sign my zone. But in dsset file, which should contain the 
same DS as I already have in the parent zone a have different "keytag" and 
different hash. 

In my case is "keytag" in dsset file is 43120.

i.e.

example.com.    IN DS 43120 13 1 28844871EB1835E6EA3EE5554B5E7BLABLABLA

example.com.    IN DS 43120 13 2 7777AEB8EE54BE246EA6A83637E39EE47AB13EAD8B3
E287D3BLABLABLA

I hoped for the same result which I already have in the parent zone.

Could you please advice me once again?
-- 
Smil Milan Jeskyňka Kazatel

---------- Původní e-mail ----------
Od: Tony Finch <dot at dotat.at>
Komu: Milan Jeskynka Kazatel <KazatelM at seznam.cz>
Datum: 14. 3. 2019 14:56:26
Předmět: Re: convert Knot DNS sigantures certs to BIND format.
"Milan Jeskynka Kazatel <KazatelM at seznam.cz> wrote: 
> 
> When I tried to re-sign my zone in BIND by Webmin, then I get this error 
> message below. My original "keytag" is 43121. I don´t understand, where is

> written information like example.com/ECDSAP256SHA256/45623 

BIND often does not refer to key files by filename, so it helps if you 
know how the mnemonic description of the key maps to the filenames. In 
this case, example.com/ECDSAP256SHA256/45623 corresponds to 
Kexample.com+013+45623.key and .private - 13 is the algorithm number for 
ecdsa256 and 45623 is the key tag. 

> dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: 
> error reading private key file example.com/ECDSAP256SHA256/45623: 
> file not found 

I think this means there is a DNSKEY record in the zone with tag 45623, so 
dnssec-signzone is looking for the corresponding private key file. 

> dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: 
> error reading private key file example.com/ECDSAP256SHA256/43121: 
> private key is invalid 

This error happens if there's a cryptographic mismatch between the private 
key and the public key. 

The unexpected key tag might be caused by the same mismatch, but I can't 
be sure about that. 

It might help if I go through the details of the parts I omitted from the 
end of my previous message. 

Remember, I had: 

$ cat /var/lib/knot/keys/zone_example.com.json 
{ 
"policy": "\u0006policy", 
"nsec3_salt": null, 
"nsec3_salt_created": null, 
"keys": [ 
{ 
"id": "c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658", 
"keytag": 19633, 
"algorithm": 13, 
"public_key": "h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6
gcXKJddCM3EVcGIv9u25TQSHQ7SrA==", 
"ksk": false, 
"created": "2019-03-12T15:44:02+0000" 
} 
] 
} 

$ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9
fb7b89d521a4f658.pem | 
perl -Mv5.10 -MMIME::Base64 -e ' 
undef $/; my $k = <STDIN>; 
print encode_base64 substr $k, 7, 32; 
print encode_base64 substr $k, -64;' 
read EC key 
writing EC key 
9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94= 
h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u2

5TQSHQ7SrA== 

The JSON metadata says "algorithm": 13, "ksk": false, so I run 

$ dnssec-keygen -a 13 example.com 
Generating key pair. 
Kexample.com.+013+11891 

(If ksk is true then I need to add the -f KSK option.) 

The JSON says "keytag": 19633, so I run 

$ mv Kexample.com.+013+11891.key Kexample.com.+013+19633.key 
$ mv Kexample.com.+013+11891.private Kexample.com.+013+19633.private 

Now I need to edit the files. 

In the .key file I change the keyid (aka keytag) and the public key to 
match the JSON metadata. Note that the public key is very long, and you 
need to avoid unwanted line breaks. (The perl magic ouput has an unwanted 
line break so you might prefer to use the blob from the JSON.) 

Before: 

$ cat Kexample.com.+013+19633.key 
; This is a zone-signing key, keyid 11891, for example.com. 
; Created: 20190314133836 (Thu Mar 14 13:38:36 2019) 
; Publish: 20190314133836 (Thu Mar 14 13:38:36 2019) 
; Activate: 20190314133836 (Thu Mar 14 13:38:36 2019) 
example.com. IN DNSKEY 256 3 13 1cZ3gTd2P3su+pWjBj+wGjGsWt22T/cZmlxrwB1Be91
lW0BvrOHN1SDZ togkoCBsdb70zj2//W6QQQcgQudVEQ== 

After: 

$ cat Kexample.com.+013+19633.key 
; This is a zone-signing key, keyid 19633, for example.com. 
; Created: 20190314133836 (Thu Mar 14 13:38:36 2019) 
; Publish: 20190314133836 (Thu Mar 14 13:38:36 2019) 
; Activate: 20190314133836 (Thu Mar 14 13:38:36 2019) 
example.com. IN DNSKEY 256 3 13 h9c2BtzXhjYHSdLC+XstMGQ6HBLgoerczR++pA/
owtWv/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA== 

I also need to change the private key to match the output from the perl 
magic. 

Before: 

$ cat Kexample.com.+013+19633.private 
Private-key-format: v1.3 
Algorithm: 13 (ECDSAP256SHA256) 
PrivateKey: ysGhvWvE6fJcTxC9d9FXPn4qYuVkILE7l3Ei5VS2pMs= 
Created: 20190314133836 
Publish: 20190314133836 
Activate: 20190314133836 

After: 

$ cat Kexample.com.+013+19633.private 
Private-key-format: v1.3 
Algorithm: 13 (ECDSAP256SHA256) 
PrivateKey: 9WCSrP5vSTrPMrMWISz3N0aU6wZPcRHxcZKE9g0Wc94= 
Created: 20190314133836 
Publish: 20190314133836 
Activate: 20190314133836 

Now I should be able to sign the zone. I'm using the -S smart signing 
option, and -P to suppress the error that is reported because my zone has 
no KSK. 

$ dnssec-signzone -S -P example.com 
Fetching ZSK 19633/ECDSAP256SHA256 from key repository. 
example.com.signed 

Done. 

Tony. 
-- 
f.anthony.n.finch <dot at dotat.at> http://dotat.at/ 
Viking: Variable 3 or less, becoming southwest 4 or 5, occasionally 6 later.

Moderate or rough. Showers then rain. Good, occasionally poor."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20190314/b3f9f047/attachment.html>