Replace rcgen with custom X.509 certificate generation #106
Conversation
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
TheBlueMatt
left a comment
TheBlueMatt
left a comment
There was a problem hiding this comment.
I'm not actually clear on why we want support for building a self-signed cert? In such cases shouldn't we just not use TLS?
ldk-server/src/util/tls.rs
Outdated
| // Clear the high bit to ensure the number is positive. | ||
| serial[0] &= 0x7F; | ||
|
|
||
| // Validity period: now to now + 10 years |
There was a problem hiding this comment.
Just fix constants 2025 through 2100?
There was a problem hiding this comment.
did til 2049 because its a different encoding after that year
| tokio = { version = "1.38.0", default-features = false, features = ["time", "signal", "rt-multi-thread"] } | ||
| tokio-rustls = { version = "0.26", default-features = false, features = ["ring"] } | ||
| rcgen = { version = "0.13", default-features = false, features = ["ring"] } | ||
| ring = { version = "0.17", default-features = false } |
There was a problem hiding this comment.
Given we're gonna ship a binary, I do very much wonder whether we shouldn't use native-tls across the stack in ldk-server. That would avoid us being responsible for shipping updates to ring and rustls in case of a security issue (though honestly I'm not entirely clear on why we want TLS for the RPC to begin with)
There was a problem hiding this comment.
Note that if we did so we could retain the cert-building logic here by switching to secp256k1 rather than secp256r1-via-ring.
| Ok(der_sequence(&san_ext)) | ||
| } | ||
|
|
||
| fn build_san_extension(hosts: &[String]) -> Result<Vec<u8>, String> { |
There was a problem hiding this comment.
given its self-signed anyway why are we building a SAN? Can't we just have a fixed CN of localhost and call it a day?
There was a problem hiding this comment.
There's been many times where I need to do this with lnd. A lot with docker containers where we need to add the container's name to the cert so other containers can call on the rpc
There was a problem hiding this comment.
Right but its a self-signed cert so the hostname is usually not validated? Or are there things that validate the hostname even for a self-signed cert?
There was a problem hiding this comment.
I am pretty sure the hostname is validated because I normally am not able to get anything to work unless I add it to the cert
ldk-server/src/main.rs
Outdated
| let mut rng = rand::thread_rng(); | ||
| let mut key_bytes = [0u8; 32]; | ||
| rng.fill(&mut key_bytes); | ||
| getrandom::getrandom(&mut key_bytes) |
There was a problem hiding this comment.
rand as a dep isn't actually removed?
There was a problem hiding this comment.
yeah its still a transitive dep but if our underlying crates stop using it, we will be fine now
There was a problem hiding this comment.
it never was in there
Implement self-signed certificate generation using ring directly, removing the rcgen dependency along with its transitive dependencies (yasna, time). ring was already in our dependency tree via tokio-rustls. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
benthecarman
force-pushed
the
rm-rcgen
branch
from
7b39d0b to
31e8feb
Compare
there are definitely cases where you want encryption but dont want to go through the hassle of the CA and can just share the certificate directly |
3 participants
Implement self-signed certificate generation using ring directly, removing the rcgen dependency along with its transitive dependencies (yasna, time). ring was already in our dependency tree via tokio-rustls.