LocalSend Onboarding LabChapter VII — Core Protocol Crate: Crypto, HTTP & WebRTC✓ 0/6Contents
Chapter VII

Core Protocol Crate: Crypto, HTTP & WebRTC

The core crate is the protocol-authoritative Rust implementation of LocalSend, shared by the app's Rust bridge and the standalone signaling server via cargo features (crypto, http, webrtc). It handles mutual-TLS certificate verification, the HTTPS client/server that speaks the LocalSend v2/v3 REST protocol, and WebRTC signaling plus an application-level handshake (nonce/token/PIN) layered on top of a raw data channel for P2P file transfer.

walkthrough

Verifying a peer certificate

core/src/crypto/cert.rs · lines 24–46
lines 25–27

Rejects expired or not-yet-valid certificates before doing any expensive crypto work.

lines 29–38

LocalSend certificates are self-signed, so there's no CA chain to trust — instead the caller can pass an expected public key (learned during a prior pairing) and the function checks the certificate's embedded key against it, catching key mismatch as a distinct error from signature failure.

line 40

Finally verifies the certificate signs itself correctly (self-signed check), passing None as issuer since there's no external CA.

fn verify_cert_from_cert(cert: X509Certificate, public_key: Option<&str>) -> anyhow::Result<()> {    if !cert.validity.is_valid() {        return Err(anyhow::anyhow!("Time validity error"));    }     if let Some(public_key) = public_key {        let cert_public_key = cert.tbs_certificate.subject_pki.parsed()?;         let (public_key_pem, _) = Pem::read(Cursor::new(public_key.as_bytes()))?;        let (_, public_key_spki) = SubjectPublicKeyInfo::from_der(&public_key_pem.contents)?;        let expected_public_key = public_key_spki.parsed()?;         if cert_public_key != expected_public_key {            return Err(anyhow::anyhow!("Public key mismatch"));        }    }     cert.verify_signature(None)?;     Ok(())}
step 1 of 3
pub(super) fn create_reqwest_client(    private_key: &str,    cert: &str,) -> Result<reqwest::Client, ClientError> {    let _ = rustls::crypto::ring::default_provider().install_default();     let identity = {        let pem = &[cert.as_bytes(), "\n".as_bytes(), private_key.as_bytes()].concat();        reqwest::Identity::from_pem(pem)?    };     let client = reqwest::Client::builder()        .use_rustls_tls()        .danger_accept_invalid_certs(true)        .tls_info(true)        .identity(identity)        .build()?;     Ok(client)}
core/src/http/client/mod.rs · lines 146–165
Figure I · LocalSend doesn't use a CA-trusted PKI: the client deliberately disables standard cert-chain validation (danger_accept_invalid_certs) and instead relies on crypto::cert::verify_cert_from_res afterwards to check the peer's self-signed cert against an expected public key. Every client also presents its own identity (cert+key) for mutual TLS, which the server-side CustomClientCertVerifier accepts unconditionally.
Figure II · data modelFileDto — the wire representation of an offered filecore/src/model/transfer.rs
{
: String,
: "photo.jpg",
: u64,
: "image/jpeg",
: Option<String>,
: Option<String>,
: {
: Option<String>,
: Option<String>
}
}
checkpoint

Check your understanding

Answered in place — nothing is graded, everything is explained. 0 / 2 passed

Since LocalSend certificates are self-signed with no CA, how does the HTTP client actually establish trust in a peer's certificate?

In the WebRTC send_offer flow, when does the sender challenge the receiver for a PIN (as opposed to being challenged)?