These are chat archives for CZ-NIC/knot-resolver

15th
Feb 2018
Jörg Thalheim
@Mic92
Feb 15 2018 07:51 UTC
@vcunat do you know, why knot decided to pin certificates instead of public keys? Public keys could remain stable, while certificates are updated
Vladimír Čunát
@vcunat
Feb 15 2018 08:57 UTC
@Mic92: I perhaps don't understand. Knot-resolver supports both pinning and certificates.
(Or is this about knot-dns?)
Jörg Thalheim
@Mic92
Feb 15 2018 10:45 UTC
@vcunat It does? Then I have not seen this.
Vladimír Čunát
@vcunat
Feb 15 2018 10:47 UTC
e.g. { '2620:fe::fe', hostname = 'dns.quad9.net', ca_file = '/etc/ssl/certs/ca-bundle.crt' }
Jörg Thalheim
@Mic92
Feb 15 2018 10:52 UTC
@vcunat right, this is about pinning the ca. There is also pin_sha256 - I assume this is the certificate pin. I tried to compute the sha256 of the public key. echo | openssl s_client -connect '9.9.9.9:853' 2>/dev/null | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64
Vladimír Čunát
@vcunat
Feb 15 2018 10:54 UTC
I'm myself not sure how the pin should be computed, but it's some standard thing.
Note that Quad9 have not announced a SPKI pinset.
Base 64 encoded form of SPKI pin(s) for TLS authentication (RFC7858)
Jörg Thalheim
@Mic92
Feb 15 2018 10:57 UTC
On the long run I want to have my own server, shared with some other folks. But it would be good to have a working example, people can use, in the nixos example section
I tried pinning 9.9.9.9 to the letsencrypt root ca, but apparently I am missing something.
just using https://letsencrypt.org/certs/isrgrootx1.pem.txt is not enough
Jörg Thalheim
@Mic92
Feb 15 2018 11:27 UTC
But at least knowing that pin_sha256 follows a standard, is helpful
Vladimír Čunát
@vcunat
Feb 15 2018 11:28 UTC
Well, I had tested the above config with the bundle.
They use root x3
Ah, not root x3.
Well, I'm no expert on TLS. This is what I get
$ openssl s_client -connect dns.quad9.net:853
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = dns.quad9.net
verify return:1
Vladimír Čunát
@vcunat
Feb 15 2018 11:47 UTC
It's possible knot-resolver has some issue when there are multiple trust paths "to choose from". By default, dns.quad9.net chooses to send this one, because this root is commonly trusted by browsers, and using it works in kresd https://www.identrust.com/certificates/trustid/root-download-x3.html (with added -- BEG/END CERT -- lines).
to track this.