Is it possible to disable the cert verification?
Opened this issue · 9 comments
I would like to connect to services with self signed certificates.
Are you able to insert that certificate into your system's trust store? That's the preferred method for dealing with self signed certificates.
I'm not sure. Is it possible to extract the cert on a random non-http tls connection?
I'm trying to communicate with an android app which generate a new self-signed cert on every device.
I think the app use cert verification after the two devices are paired with users confirmation and the cert is added to a cert pool.
I think what should work here is to provide access to the schannel state after a failed handshake. That'll let you in particular have access to the peer's certificate. I'll be working on adding support to provide extra trust roots on a per-connection level soon, so you'll be able to reconnect with that certificate trusted.
This is also a problem with using Fiddler to intercept https connections. Currently InitializeSecurityContext fails with CRYPT_E_NO_REVOCATION_CHECK 0x80092012 The revocation function was unable to check revocation for the certificate. which is a valid error (Fiddler's trusted root doesn't have a valid revocation URL).
curl took the approach of providing a CLI flag to pass SCH_CRED_IGNORE_NO_REVOCATION_CHECK | SCH_CRED_IGNORE_REVOCATION_OFFLINE to AcquireCredentialsHandle
That certainly seems reasonable - I'd be happy to take a PR with that option.
Do you know why Fiddler's root would have an invalid revocation URL rather than not having one at all?
It doesn't have one at all - I think that's what makes it invalid unless SCH_CRED_IGNORE_NO_REVOCATION_CHECK is passed in. It's probably because it's dynamically generated when you enable the "Decrypt HTTPS traffic".
That said, I'm not sure where the error is actually coming from. SchannelCred::acquire only sets SCH_USE_STRONG_CRYPTO and MSDN says SCH_CRED_IGNORE_NO_REVOCATION_CHECK would be ignored in this case.
I'll build a debug rustup and schannel and check.
Sorry, ignore me. The error is from rustup's curl backend. If I force it to use the hyper backend (that uses rust-native-tls and thus schannel-rs) there's no problems with Fiddler.
Ah, great!