convert Knot DNS sigantures certs to BIND format.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

convert Knot DNS sigantures certs to BIND format.

Milan Jeskynka Kazatel
Hello Comunity, 

can I somehow convert Knot DNS stored certificates for a signed zone to BIND 
format? 
 
My use case is to change used topology for authoritative servers. I ´m manage existing zones in Knot, now I would like to transfer it to BIND 
and use existing certificates for signing it on BIND due to DS records in parent zones. The Knot will be reconfigured as a slave. 
 
Is it possible to achieve it? 

I received a hint for a tool which allows converting .pem format used in Knot to .key and .private used in BIND, but it, unfortunately, does not support ECDSAP256SHA256 algorithm which I used. (http://manpages.ubuntu.com/manpages/xenial/en/man1/softhsm-keyconv.1.html)

Have You any other advice?
 
Thanks. 

--
Jeskyňka Kazatel

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Tony Finch
Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> I received a hint for a tool which allows converting .pem format used in
> Knot to .key and .private used in BIND, but it, unfortunately, does not
> support ECDSAP256SHA256 algorithm which I used.

Ah, sounds like Knot uses a relatively familiar key format, so we can hack
around with OpenSSL command line tools.

Unless I have missed something, BIND doesn't have any support for non-BIND
key files: it has its own code for reading and writing keys, which knows
about OpenSSL's in-memory key format. (I think this is related to support
for multiple crypto providers, and the fact that supporting PEM implies
supporting ASN.1 which is not a task any wise programmer would take on.)

So I think you'll have to get dirty with the key internals; fortunately
the modern key types handle the private material as a blob so you don't
have to fiddle around with half a dozen parameters.

If you have an ECDSA key in PEM format, you can break it open like
this. The short blob is the private key and the long one is the public
key.

$ openssl ec </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.pem |
  openssl asn1parse -dump
read EC key
writing EC key
    0:d=0  hl=2 l= 119 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  32 prim: OCTET STRING
      0000 - f5 60 92 ac fe 6f 49 3a-cf 32 b3 16 21 2c f7 37   .`...oI:.2..!,.7
      0010 - 46 94 eb 06 4f 71 11 f1-71 92 84 f6 0d 16 73 de   F...Oq..q.....s.
   39:d=1  hl=2 l=  10 cons: cont [ 0 ]
   41:d=2  hl=2 l=   8 prim: OBJECT            :prime256v1
   51:d=1  hl=2 l=  68 cons: cont [ 1 ]
   53:d=2  hl=2 l=  66 prim: BIT STRING
      0000 - 00 04 87 d7 36 06 dc d7-86 36 07 49 d2 c2 f9 7b   ....6....6.I...{
      0010 - 2d 30 64 3a 1c 12 e0 a1-ea dc cd 1f be a4 0f e8   -0d:............
      0020 - c2 d5 af fe 30 71 be 12-62 60 ba 07 ea 07 17 28   ....0q..b`.....(
      0030 - 97 5d 08 cd c4 55 c1 88-bf db b6 e5 34 12 1d 0e   .]...U......4...
      0040 - d2 ac                                             ..

BIND wants these in base64. A not completely impossible way to do this is
to feed the binary (DER) form of the key to a bit of perl. (PEM is base64
encoded DER.) This involves some magic numbers for the offsets of the
blobs derived from the asn1 dump above.

$ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.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 first line is the private key; the second and third lines are the
public key. We can check it matches:

$ 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/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
      "ksk": false,
      "created": "2019-03-12T15:44:02+0000"
    }
  ]
}

Probably the easiest way to turn this into BIND key files is to run
`dnssec-keygen -a ecdsa256 example.com` and edit the output to insert the
short private and long public base64 blobs emitted by the perl. You will
also need to rename the files to match the keytag in knot's zone_*.json
file.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
public services available on equal terms to all
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Milan Jeskynka Kazatel
Hollo Tony,

many thanks, it´s an awesome trick.

I can confirm, that I´m able to "hack" private and public key from KNOT. I tried to re-write information in .key and .private files in BIND, but now it seems to be an issue with the chain used in the zone.

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

***
Failed to sign zone : dnssec-signzone: warning: /var/named/example.com:458: signature has expired dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading private key file example.com/ECDSAP256SHA256/45623: file not found dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading private key file example.com/ECDSAP256SHA256/43121: private key is invalid dnssec-signzone: fatal: failed to load the zone keys: private key is invalid
***

Could you please help me dig, where I´m wrong?
Best regards, 
--
Smil Milan Jeskyňka Kazatel


Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> I received a hint for a tool which allows converting .pem format used in
> Knot to .key and .private used in BIND, but it, unfortunately, does not
> support ECDSAP256SHA256 algorithm which I used.

Ah, sounds like Knot uses a relatively familiar key format, so we can hack
around with OpenSSL command line tools.

Unless I have missed something, BIND doesn't have any support for non-BIND
key files: it has its own code for reading and writing keys, which knows
about OpenSSL's in-memory key format. (I think this is related to support
for multiple crypto providers, and the fact that supporting PEM implies
supporting ASN.1 which is not a task any wise programmer would take on.)

So I think you'll have to get dirty with the key internals; fortunately
the modern key types handle the private material as a blob so you don't
have to fiddle around with half a dozen parameters.

If you have an ECDSA key in PEM format, you can break it open like
this. The short blob is the private key and the long one is the public
key.

$ openssl ec </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.pem |
openssl asn1parse -dump
read EC key
writing EC key
0:d=0 hl=2 l= 119 cons: SEQUENCE
2:d=1 hl=2 l= 1 prim: INTEGER :01
5:d=1 hl=2 l= 32 prim: OCTET STRING
0000 - f5 60 92 ac fe 6f 49 3a-cf 32 b3 16 21 2c f7 37 .`...oI:.2..!,.7
0010 - 46 94 eb 06 4f 71 11 f1-71 92 84 f6 0d 16 73 de F...Oq..q.....s.
39:d=1 hl=2 l= 10 cons: cont [ 0 ]
41:d=2 hl=2 l= 8 prim: OBJECT :prime256v1
51:d=1 hl=2 l= 68 cons: cont [ 1 ]
53:d=2 hl=2 l= 66 prim: BIT STRING
0000 - 00 04 87 d7 36 06 dc d7-86 36 07 49 d2 c2 f9 7b ....6....6.I...{
0010 - 2d 30 64 3a 1c 12 e0 a1-ea dc cd 1f be a4 0f e8 -0d:............
0020 - c2 d5 af fe 30 71 be 12-62 60 ba 07 ea 07 17 28 ....0q..b`.....(
0030 - 97 5d 08 cd c4 55 c1 88-bf db b6 e5 34 12 1d 0e .]...U......4...
0040 - d2 ac ..

BIND wants these in base64. A not completely impossible way to do this is
to feed the binary (DER) form of the key to a bit of perl. (PEM is base64
encoded DER.) This involves some magic numbers for the offsets of the
blobs derived from the asn1 dump above.

$ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.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 first line is the private key; the second and third lines are the
public key. We can check it matches:

$ 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/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
"ksk": false,
"created": "2019-03-12T15:44:02+0000"
}
]
}

Probably the easiest way to turn this into BIND key files is to run
`dnssec-keygen -a ecdsa256 example.com` and edit the output to insert the
short private and long public base64 blobs emitted by the perl. You will
also need to rename the files to match the keytag in knot's zone_*.json
file.

Tony.
--
f.anthony.n.finch <[hidden email]> http://dotat.at/
public services available on equal terms to all

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Tony Finch
Milan Jeskynka Kazatel <[hidden email]> 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/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
      "ksk": false,
      "created": "2019-03-12T15:44:02+0000"
    }
  ]
}

$ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.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/cZmlxrwB1Be91lW0BvrOHN1SDZ 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  <[hidden email]>  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.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Milan Jeskynka Kazatel
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 7777AEB8EE54BE246EA6A83637E39EE47AB13EAD8B3E287D3BLABLABLA

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


Milan Jeskynka Kazatel <[hidden email]> 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/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
"ksk": false,
"created": "2019-03-12T15:44:02+0000"
}
]
}

$ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.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/cZmlxrwB1Be91lW0BvrOHN1SDZ 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 <[hidden email]> 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.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Tony Finch
Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> 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.

OK, referring to your previous message...

> > My original "keytag" is 43121.

The keytag calculation is a very simple checksum so the fact that the
correct and incorrect tags differ by 1 is a big clue :-) The KSK flag's
value is 1 (ZSK flags == 256, KSK flags == 257) so it looks like you
missed out the `-f KSK` option to dnssec-keygen when making the template
key files.

You can fix this by changing 256 to 257 in the .key file(s) that should be
KSKs and re-signing the zone. Double check that the key file names match
the key tags, e.g. this is wrong:

$ dnssec-dsfromkey Kexample.com.+013+19633.key
example.com. IN DS 19634 13 1 32CF6889AEBABD43F2A87A59D4EC13A18A91AA0A

(Unexpectedly, BIND does not always get upset when the keytag in a key
file name doesn't match the computed keytag, so it's possible to get
things slightly wrong and not notice unless you double check.)

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Southeast Iceland: Cyclonic, mainly northeasterly, 5 to 7, decreasing 4 at
times. Rough or very rough. Wintry showers. Good, occasionally poor.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Milan Jeskynka Kazatel
Hello Tony,

Awesome. 
Many thanks for your explanation and clarification. 

Now is everything as I expected.

Best regards,
--
Smil Milan Jeskyňka Kazatel


Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> 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.

OK, referring to your previous message...

> > My original "keytag" is 43121.

The keytag calculation is a very simple checksum so the fact that the
correct and incorrect tags differ by 1 is a big clue :-) The KSK flag's
value is 1 (ZSK flags == 256, KSK flags == 257) so it looks like you
missed out the `-f KSK` option to dnssec-keygen when making the template
key files.

You can fix this by changing 256 to 257 in the .key file(s) that should be
KSKs and re-signing the zone. Double check that the key file names match
the key tags, e.g. this is wrong:

$ dnssec-dsfromkey Kexample.com.+013+19633.key
example.com. IN DS 19634 13 1 32CF6889AEBABD43F2A87A59D4EC13A18A91AA0A

(Unexpectedly, BIND does not always get upset when the keytag in a key
file name doesn't match the computed keytag, so it's possible to get
things slightly wrong and not notice unless you double check.)

Tony.
--
f.anthony.n.finch <[hidden email]> http://dotat.at/
Southeast Iceland: Cyclonic, mainly northeasterly, 5 to 7, decreasing 4 at
times. Rough or very rough. Wintry showers. Good, occasionally poor.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Petr Mensik
In reply to this post by Tony Finch
Hi Tony and Milan,

softhsm2 contains useful tool that converts bind private key file into
PKCS#8 format: softhsm2-keyconv.

Or modify dnssec-keyfromlabel to be able read files from different file
formats as well?

Maybe, just maybe it would be easier to modify that tool to be able
producing also the other direction.

On 3/12/19 5:11 PM, Tony Finch wrote:

> Milan Jeskynka Kazatel <[hidden email]> wrote:
>>
>> I received a hint for a tool which allows converting .pem format used in
>> Knot to .key and .private used in BIND, but it, unfortunately, does not
>> support ECDSAP256SHA256 algorithm which I used.
>
> Ah, sounds like Knot uses a relatively familiar key format, so we can hack
> around with OpenSSL command line tools.
>
> Unless I have missed something, BIND doesn't have any support for non-BIND
> key files: it has its own code for reading and writing keys, which knows
> about OpenSSL's in-memory key format. (I think this is related to support
> for multiple crypto providers, and the fact that supporting PEM implies
> supporting ASN.1 which is not a task any wise programmer would take on.)
>
> So I think you'll have to get dirty with the key internals; fortunately
> the modern key types handle the private material as a blob so you don't
> have to fiddle around with half a dozen parameters.
>
> If you have an ECDSA key in PEM format, you can break it open like
> this. The short blob is the private key and the long one is the public
> key.
>
> $ openssl ec </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.pem |
>   openssl asn1parse -dump
> read EC key
> writing EC key
>     0:d=0  hl=2 l= 119 cons: SEQUENCE
>     2:d=1  hl=2 l=   1 prim: INTEGER           :01
>     5:d=1  hl=2 l=  32 prim: OCTET STRING
>       0000 - f5 60 92 ac fe 6f 49 3a-cf 32 b3 16 21 2c f7 37   .`...oI:.2..!,.7
>       0010 - 46 94 eb 06 4f 71 11 f1-71 92 84 f6 0d 16 73 de   F...Oq..q.....s.
>    39:d=1  hl=2 l=  10 cons: cont [ 0 ]
>    41:d=2  hl=2 l=   8 prim: OBJECT            :prime256v1
>    51:d=1  hl=2 l=  68 cons: cont [ 1 ]
>    53:d=2  hl=2 l=  66 prim: BIT STRING
>       0000 - 00 04 87 d7 36 06 dc d7-86 36 07 49 d2 c2 f9 7b   ....6....6.I...{
>       0010 - 2d 30 64 3a 1c 12 e0 a1-ea dc cd 1f be a4 0f e8   -0d:............
>       0020 - c2 d5 af fe 30 71 be 12-62 60 ba 07 ea 07 17 28   ....0q..b`.....(
>       0030 - 97 5d 08 cd c4 55 c1 88-bf db b6 e5 34 12 1d 0e   .]...U......4...
>       0040 - d2 ac                                             ..
>
> BIND wants these in base64. A not completely impossible way to do this is
> to feed the binary (DER) form of the key to a bit of perl. (PEM is base64
> encoded DER.) This involves some magic numbers for the offsets of the
> blobs derived from the asn1 dump above.
>
> $ openssl ec -outform der </var/lib/knot/keys/keys/c3e8539dc582bb2ceeca0ab9fb7b89d521a4f658.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 first line is the private key; the second and third lines are the
> public key. We can check it matches:
>
> $ 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/jBxvhJiYLoH6gcXKJddCM3EVcGIv9u25TQSHQ7SrA==",
>       "ksk": false,
>       "created": "2019-03-12T15:44:02+0000"
>     }
>   ]
> }
>
> Probably the easiest way to turn this into BIND key files is to run
> `dnssec-keygen -a ecdsa256 example.com` and edit the output to insert the
> short private and long public base64 blobs emitted by the perl. You will
> also need to rename the files to match the keytag in knot's zone_*.json
> file.
>
> Tony.
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/bind-users
>

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: [hidden email]  PGP: 65C6C973
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Tony Finch
Petr Mensik <[hidden email]> wrote:
>
> Maybe, just maybe it would be easier to modify that tool to be able
> producing also the other direction.

Definitely, if the key conversion isn't a one-off :-)

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Viking, North Utsire: Southwesterly 4 or 5, increasing 6 to gale 8, veering
westerly 3 or 4 later. Moderate or rough, occasionally very rough. Rain or
showers. Good occasionally poor.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Milan Jeskynka Kazatel
In reply to this post by Tony Finch
Hello Tony, 

could you please help me one more time?

your suggested workflow working for me in most of the cases. Unfortunately, it happens that the resigning mechanism creates whitespace in the DNSKEY and in the log I can see a message:
dns_dnssec_findzonekeys2: error reading private key file example.com/ECDSAP256SHA256/6786: file not found

I double checked the .private and .key also for any TYPO.

even if the signing process pass.
#dnssec-signzone -S -P -z example.com
Fetching KSK/ZSK 6786/ECDSAP256SHA256 from key repository.
example.com.signed

Whitespace is visible in dig.
from dig:
example.com.  300     IN      DNSKEY  257 3 13 nZwiBQ/QLbqqrdgh+Ailr2m1Mu2Mjot6IZ4fzkvAwR8wws5qoJyIqUMX ppcKGFPUg63z70WLgw9oyJOyBHZlIQ==

And in dnssec-dsfromkey command to.

Could be a glitch in the openssl command, that translate some character wrongly as a white space after signing process?

Many thanks for any advice,
best regards, 
--
Smil Jeskyňka Kazatel


Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> 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.

OK, referring to your previous message...

> > My original "keytag" is 43121.

The keytag calculation is a very simple checksum so the fact that the
correct and incorrect tags differ by 1 is a big clue :-) The KSK flag's
value is 1 (ZSK flags == 256, KSK flags == 257) so it looks like you
missed out the `-f KSK` option to dnssec-keygen when making the template
key files.

You can fix this by changing 256 to 257 in the .key file(s) that should be
KSKs and re-signing the zone. Double check that the key file names match
the key tags, e.g. this is wrong:

$ dnssec-dsfromkey Kexample.com.+013+19633.key
example.com. IN DS 19634 13 1 32CF6889AEBABD43F2A87A59D4EC13A18A91AA0A

(Unexpectedly, BIND does not always get upset when the keytag in a key
file name doesn't match the computed keytag, so it's possible to get
things slightly wrong and not notice unless you double check.)

Tony.
--
f.anthony.n.finch <[hidden email]> http://dotat.at/
Southeast Iceland: Cyclonic, mainly northeasterly, 5 to 7, decreasing 4 at
times. Rough or very rough. Wintry showers. Good, occasionally poor.

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: convert Knot DNS sigantures certs to BIND format.

Tony Finch
Milan Jeskynka Kazatel <[hidden email]> wrote:
>
> your suggested workflow working for me in most of the cases. Unfortunately,
> it happens that the resigning mechanism creates whitespace in the DNSKEY

That should be benign, provided it is horizontal space without newlines.
For example, BIND creates .key files with spaces in the base64 blob by
default, but when editing the files, it's easier to copy and paste blobs
without spaces.

So I don't think your "file not found" error is to do with white space.

I don't have enough information to know what is causing the error, but one
thing I noticed is that the key ID you mentioned 6786 is only four digits.
In the key file name this needs to be padded to 5 digits, like
Kexample.com.+013+06786.key - if you have already done that then I'm out
of guesses :-)

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Cromarty: Southwest 5 to 7. Slight or moderate. Occasional rain later. Good,
occasionally moderate later.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users