Is your feature request related to a problem?
Hey there, first I just want to thank you for all the great work - it’s very much appreciated.
Problem:
I was unable to find a proper way to handle whitelisted invalid certificates using the libcpr API.
Use case:
Accessing a server with an invalid certificate and explicitly choosing to proceed despite the risks (e.g., as browsers allow).
Common handling:
Temporarily trusting the specific certificate or its public key, rather than disabling verification entirely, so that future connections succeed if either the default verification passes or the certificate matches one of the trusted certificates/keys.
Current API:
libcpr supports pinned public key verification, but without “either/or” semantics - meaning verification fails for any certificate that doesn't match the pinned key/s:
cpr::SslOptions sslOpts = cpr::Ssl(
cpr::ssl::PinnedPublicKey{<pinned_key/s_hash>});
Workaround:
A retry-based approach (hacky and inefficient):
// 1. Attempt connection using default verification
cpr::SslOptions defaultOpts = cpr::Ssl(<default_options>);
// 2. On failure, retry with verification disabled and only pinned key enforced
cpr::SslOptions fallbackOpts = cpr::Ssl(
cpr::ssl::PinnedPublicKey{<pinned_key/s_hash>},
cpr::ssl::VerifyPeer{false},
cpr::ssl::VerifyHost{false}
/*...*/ );
Possible Solution
Introduce a new SSL option: TrustedPublicKey (distinct from PinnedPublicKey) with the following semantics:
- The connection succeeds if either:
- The default verification passes or
- The server’s public key matches any of the provided trusted keys.
Alternatives
No response
Additional Context
No response
Is your feature request related to a problem?
Hey there, first I just want to thank you for all the great work - it’s very much appreciated.
Problem:
I was unable to find a proper way to handle whitelisted invalid certificates using the
libcprAPI.Use case:
Accessing a server with an invalid certificate and explicitly choosing to proceed despite the risks (e.g., as browsers allow).
Common handling:
Temporarily trusting the specific certificate or its public key, rather than disabling verification entirely, so that future connections succeed if either the default verification passes or the certificate matches one of the trusted certificates/keys.
Current API:
libcprsupports pinned public key verification, but without “either/or” semantics - meaning verification fails for any certificate that doesn't match the pinned key/s:cpr::SslOptions sslOpts = cpr::Ssl( cpr::ssl::PinnedPublicKey{<pinned_key/s_hash>});Workaround:
A retry-based approach (hacky and inefficient):
Possible Solution
Introduce a new SSL option:
TrustedPublicKey(distinct fromPinnedPublicKey) with the following semantics:Alternatives
No response
Additional Context
No response