starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 19:25:56 +03:00

[GH-ISSUE #1642] Support for EC keys #720

New issue

Open

opened 2026-03-15 23:58:17 +03:00 by kerem · 16 comments

kerem commented

2026-03-15 23:58:17 +03:00

Owner

Originally created by @LuckyTurtleDev on GitHub (Feb 19, 2022).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1642

Is your feature request related to a problem? Please describe.
The caddy webserver, save let's encrypt certificates as EC keys. Because of the missing support for this keys in trust-dns, I can sadly not use the certificate for dot.

Describe the solution you'd like
The current rustls version dose support this certificates. see https://github.com/rustls/rustls/pull/998
So updating the rustls dependency should be enough to solve this issue.

Originally created by @LuckyTurtleDev on GitHub (Feb 19, 2022). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1642 **Is your feature request related to a problem? Please describe.** The caddy webserver, save let's encrypt certificates as EC keys. Because of the missing support for this keys in trust-dns, I can sadly not use the certificate for dot. **Describe the solution you'd like** The current rustls version dose support this certificates. see https://github.com/rustls/rustls/pull/998 So updating the rustls dependency should be enough to solve this issue.

kerem commented

2026-03-15 23:58:23 +03:00

Author

Owner

@bluejekyll commented on GitHub (Feb 19, 2022):

Which version of rustls is needed? Can you check if the 0.21.0-alpha has that? If so, we’re probably going to release that branch next week.

@bluejekyll commented on GitHub (Feb 19, 2022): Which version of rustls is needed? Can you check if the 0.21.0-alpha has that? If so, we’re probably going to release that branch next week.

kerem commented

2026-03-15 23:58:28 +03:00

Author

Owner

@djc commented on GitHub (Feb 19, 2022):

Current rustls 0.20 supports it, so I think our alphas should be good.

@djc commented on GitHub (Feb 19, 2022): Current rustls 0.20 supports it, so I think our alphas should be good.

kerem commented

2026-03-15 23:58:33 +03:00

Author

Owner

@LuckyTurtleDev commented on GitHub (Feb 19, 2022):

rust tls does support EC since 0.20.3: github.com/rustls/rustls@5bda754ac1/rustls/src/sign.rs (L288)

0.21.0-alpha use rustls 0.20.0, witch does not support EC yet.
If you remove the Cargo.lock rustls 0.20.4 is used. So the lockfile must be updated.

@LuckyTurtleDev commented on GitHub (Feb 19, 2022): rust tls does support EC since 0.20.3: https://github.com/rustls/rustls/blob/5bda754ac18f37eb39132f89fb5522494b6202eb/rustls/src/sign.rs#L288 0.21.0-alpha use rustls 0.20.0, witch does **not** support EC yet. If you remove the `Cargo.lock` rustls 0.20.4 is used. So the lockfile must be updated.

kerem commented

2026-03-15 23:58:38 +03:00

Author

Owner

@djc commented on GitHub (Feb 19, 2022):

Actually rustls did support such keys, just not the particular encoding used. So you could still make it work by reencoding the key in (I believe) PKCS #8.

@djc commented on GitHub (Feb 19, 2022): Actually rustls did support such keys, just not the particular encoding used. So you could still make it work by reencoding the key in (I believe) PKCS #8.

kerem commented

2026-03-15 23:58:43 +03:00

Author

Owner

@LuckyTurtleDev commented on GitHub (Feb 19, 2022):

Actually rustls did support such keys, just not the particular encoding used. So you could still make it work by reencoding the key in (I believe) PKCS #8.

The problem is that I must happen automatically, because the keys does change, if I get a new key from let's encrypt. Which does often happen.

@LuckyTurtleDev commented on GitHub (Feb 19, 2022): > Actually rustls did support such keys, just not the particular encoding used. So you could still make it work by reencoding the key in (I believe) PKCS #8. The problem is that I must happen automatically, because the keys does change, if I get a new key from let's encrypt. Which does often happen.

kerem commented

2026-03-15 23:58:48 +03:00

Author

Owner

@djc commented on GitHub (Feb 21, 2022):

I'm pretty sure Let's Encrypt generally does not generate keys for you (though I guess some of the client libraries might?), so key generation should be fully under your control. Are you using a Rust client library?

@djc commented on GitHub (Feb 21, 2022): I'm pretty sure Let's Encrypt generally does not generate keys for you (though I guess some of the client libraries might?), so key generation should be fully under your control. Are you using a Rust client library?

kerem commented

2026-03-15 23:58:53 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 1, 2022):

@Lukas1818, can you see if 0.21.1 meets your needs? Recently released.

@bluejekyll commented on GitHub (Mar 1, 2022): @Lukas1818, can you see if `0.21.1` meets your needs? Recently released.

kerem commented

2026-03-15 23:58:58 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 6, 2022):

ping @Lukas1818, did this resolve the issue for you?

@bluejekyll commented on GitHub (Mar 6, 2022): ping @Lukas1818, did this resolve the issue for you?

kerem commented

2026-03-15 23:59:03 +03:00

Author

Owner

@LuckyTurtleDev commented on GitHub (Mar 6, 2022):

hi, sorry I have not much time at the moment, I will checkout this at the next week.

@LuckyTurtleDev commented on GitHub (Mar 6, 2022): hi, sorry I have not much time at the moment, I will checkout this at the next week.

kerem commented

2026-03-15 23:59:08 +03:00

Author

Owner

@LuckyTurtleDev commented on GitHub (May 13, 2022):

hi, I was finally able to test this.
I have use the following config file:

listen_addrs_ipv4 = ["0.0.0.0"]

tls_cert = { path = "/home/lukas/test/****.de.key", endpoint_name = "****.de" }

But I get this error:

1652464733:INFO:named:550:loading cert for DNS over TLS: "/home/lukas/test/****.de.key"
1652464733:INFO:trust_dns_server::config::dnssec:348:loading TLS PKCS12 certificate from: "/home/lukas/test/lukas1818.de.key"
thread 'main' panicked at 'error loading tls certificate file: "badly formatted pkcs12 from: /home/lukas/test/****.de.key: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto/asn1/tasn_dec.c:1149:, error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:309:Type=PKCS12"', src/named.rs:556:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I have also try to use the .crt file instead.
But I have get the same error.

I have use the the dns-over-openssl feature.
If I use dns-over-tls instead I get the following error instead:

thread 'main' panicked at 'error loading tls certificate file: "PKCS12 is not supported with Rustls for certificate, use PEM encoding"', src/named.rs:556:14

@LuckyTurtleDev commented on GitHub (May 13, 2022): hi, I was finally able to test this. I have use the following config file: ```toml listen_addrs_ipv4 = ["0.0.0.0"] tls_cert = { path = "/home/lukas/test/****.de.key", endpoint_name = "****.de" } ``` But I get this error: ``` 1652464733:INFO:named:550:loading cert for DNS over TLS: "/home/lukas/test/****.de.key" 1652464733:INFO:trust_dns_server::config::dnssec:348:loading TLS PKCS12 certificate from: "/home/lukas/test/lukas1818.de.key" thread 'main' panicked at 'error loading tls certificate file: "badly formatted pkcs12 from: /home/lukas/test/****.de.key: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag:crypto/asn1/tasn_dec.c:1149:, error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error:crypto/asn1/tasn_dec.c:309:Type=PKCS12"', src/named.rs:556:14 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` I have also try to use the `.crt` file instead. But I have get the same error. I have use the the `dns-over-openssl` feature. If I use `dns-over-tls` instead I get the following error instead: ``` thread 'main' panicked at 'error loading tls certificate file: "PKCS12 is not supported with Rustls for certificate, use PEM encoding"', src/named.rs:556:14 ```

kerem commented

2026-03-15 23:59:13 +03:00

Author

Owner

@LuckyTurtleDev commented on GitHub (May 13, 2022):

I am a bit confused, why I can not use Rustls for PKCS12, because I had though that Rustls does support it now:
https://github.com/rustls/rustls/pull/998

@LuckyTurtleDev commented on GitHub (May 13, 2022): I am a bit confused, why I can not use Rustls for PKCS12, because I had though that Rustls does support it now: https://github.com/rustls/rustls/pull/998

kerem commented

2026-03-15 23:59:18 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 14, 2022):

If rustls supports pkcs12, this is probably just a gap in support in trust-dns. We just need to add it to the logic for reading keys.

@bluejekyll commented on GitHub (May 14, 2022): If rustls supports pkcs12, this is probably just a gap in support in trust-dns. We just need to add it to the logic for reading keys.

kerem commented

2026-03-15 23:59:24 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 15, 2022):

This is where we read the key:

github.com/bluejekyll/trust-dns@df82c60b34/crates/server/src/config/dnssec.rs (L397-L401)

So if you specify pkcs12, we will bail directly. It looks like based on the code in the linked issue you showed, that maybe there's a simpler way to construct these keys directly from the der formats? (pem might be a different story)

@bluejekyll commented on GitHub (May 15, 2022): This is where we read the key: https://github.com/bluejekyll/trust-dns/blob/df82c60b341115e5b9117959cd022d5172461377/crates/server/src/config/dnssec.rs#L397-L401 So if you specify pkcs12, we will bail directly. It looks like based on the code in the linked issue you showed, that maybe there's a simpler way to construct these keys directly from the der formats? (pem might be a different story)

kerem commented

2026-03-15 23:59:29 +03:00

Author

Owner

@LuckyTurtleDev commented on GitHub (Dec 5, 2022):

I test this again with version 0.22.0 and I notify that my certificate is a SEC1 key.

-----BEGIN EC PRIVATE KEY-----
*******
-----END EC PRIVATE KEY-----

So I think the problem is that trust-dns mistakes it for a Pkcs12 key and abort.

@LuckyTurtleDev commented on GitHub (Dec 5, 2022): I test this again with version 0.22.0 and I notify that my certificate is a SEC1 key. ``` -----BEGIN EC PRIVATE KEY----- ******* -----END EC PRIVATE KEY----- ``` So I think the problem is that trust-dns mistakes it for a Pkcs12 key and abort.

kerem commented

2026-03-15 23:59:34 +03:00

Author

Owner

@LuckyTurtleDev commented on GitHub (Oct 29, 2023):

Based on my experience with crab-hole EC keys works fine with the hickory libs and it is an artificial limitation of the hickory binary.

@LuckyTurtleDev commented on GitHub (Oct 29, 2023): Based on my experience with [crab-hole](https://github.com/LuckyTurtleDev/crab-hole) EC keys works fine with the hickory libs and it is an artificial limitation of the hickory binary.

kerem commented

2026-03-15 23:59:39 +03:00

Author

Owner

@djc commented on GitHub (Oct 30, 2023):

A BEGIN EC PRIVATE KEY is still PEM (and supported by rustls and rustls-pemfile) and is completely unrelated to PKCS12. I think the problem is that TlsCertConfig::private_key_type only understands Pkcs8 and DER which is more limiting than what rustls supports (in particular, AIUI the "EC keys" are PKCS8 keys but wrapped in additional SEC1 encoding).

@djc commented on GitHub (Oct 30, 2023): A `BEGIN EC PRIVATE KEY` is still PEM (and supported by rustls and rustls-pemfile) and is completely unrelated to PKCS12. I think the problem is that `TlsCertConfig::private_key_type` only understands `Pkcs8` and `DER` which is more limiting than what rustls supports (in particular, AIUI the "EC keys" are PKCS8 keys but wrapped in additional SEC1 encoding).