cloudflare/quiche · error

Can't use RPK when compiled without rpk feature

Error message

Can't use RPK when compiled without rpk feature

What it means

tokio-quiche's quiche_config_with_tls panics when a TlsConfig with CertificateKind::RawPublicKey is used but the crate was compiled without the "rpk" feature. Raw public key TLS requires the BoringSSL RPK API, which is only compiled in behind the feature flag, so the configuration cannot be honored at runtime.

Solutions

1. Rebuild with the feature enabled: add "rpk" to tokio-quiche's features (cargo build --features rpk or add it under [features] in your crate that depends on tokio-quiche)
2. Switch the TlsConfig to a standard CertificateKind (e.g. X.509 certificate/key paths) if RPK is not actually needed
3. Fail fast at config-parse time by validating tls.kind against compiled features before calling make_quiche_config

Example fix

// Cargo.toml
// before
tokio-quiche = "0.x"
// after
tokio-quiche = { version = "0.x", features = ["rpk"] }

// Fail fast before building the quiche config
if !cfg!(feature = "rpk")
    && matches!(tls.kind, CertificateKind::RawPublicKey)
{
    return Err(anyhow!(
        "RPK requested but tokio-quiche built without rpk feature"
    ));
}

fn rpk_supported(tls: &TlsConfig) -> bool {
    !matches!(tls.kind, CertificateKind::RawPublicKey) || cfg!(feature = "rpk")
}

// This is a panic, not a Result; avoid it by validating at config load:
let config = make_quiche_config(&params)
    .unwrap_or_else(|e| panic!("invalid TLS config: {e}"));
// Better: reject RPK configs when the feature is off, before this call.

When it happens

Trigger: Building tokio-quiche without --features rpk (default) and then supplying settings::TlsConfig with kind: CertificateKind::RawPublicKey, e.g. via make_quiche_config at server/client startup.

Common situations: Deploying a binary built with default features to an environment configured for raw public key certs; copying TLS config (YAML/env) that enables RPK into a build lacking the feature; CI builds that omit the feature flag used in production.

Related errors

• initial send failed
• The provided buffer is too large
• tokio task ID already in use
• Unsupported
• TimedOut

AI-assisted analysis of cloudflare/quiche@9f96daa2c2 (2026-09-08). Data as JSON: /api/errors/9d73d176b3c62432. Report an issue: GitHub.

Appendix: source

Thrown at tokio-quiche/src/settings/config.rs:240

    if should_log_keys {
        config.log_keys();
    }

    Ok(config)
}

fn quiche_config_with_tls(
    tls_cert: Option<TlsCertificatePaths>,
) -> QuicResult<quiche::Config> {
    let Some(tls) = tls_cert else {
        return Ok(quiche::Config::new(quiche::PROTOCOL_VERSION).unwrap());
    };

    match tls.kind {
        #[cfg(not(feature = "rpk"))]
        CertificateKind::RawPublicKey => {
            // TODO: Gate this variant on the `rpk` feature.
            panic!("Can't use RPK when compiled without rpk feature");
        },
        #[cfg(feature = "rpk")]
        CertificateKind::RawPublicKey => {
            let mut ssl_ctx_builder = boring::ssl::SslContextBuilder::new_rpk()?;
            let raw_public_key = read_file(tls.cert)?;
            ssl_ctx_builder.set_rpk_certificate(&raw_public_key)?;

            let raw_private_key = read_file(tls.private_key)?;
            let pkey =
                boring::pkey::PKey::private_key_from_pem(&raw_private_key)?;
            ssl_ctx_builder.set_null_chain_private_key(&pkey)?;

            Ok(quiche::Config::with_boring_ssl_ctx_builder(
                quiche::PROTOCOL_VERSION,
                ssl_ctx_builder,
            )?)
        },
        CertificateKind::X509 => {

View on GitHub (pinned to 9f96daa2c2)