Discussion:
self signed certificates evaluation fails on Windows and OSX using the system provided back end
Vojtěch Bubník via curl-library
2021-04-07 15:11:54 UTC
Permalink
We are using libcurl 7.58.0 in our PrusaSlicer application. PrusaSlicer is
an open source 3D printer slicer.

http://github.com/prusa3d/PrusaSlicer

We are using libcurl to communicate with Raspberry PI based print servers
using SSL and self signed certificates. Now since we switched libcurl to
use the system provided back-end, self-signed certificates evaluation fails
on Windows and OSX.

On OSX (Darwin, darwinssl.c, function verify_cert()) we
get kSecTrustResultRecoverableTrustFailure from SecTrustEvaluate(). Digging
deeper, calling SetTrustCopyResult() will return a dictionary with
StatusCodes 133 and AnchorTrusted null. We suppose that verification of the
self signed certificate was refused by the OSX built in certificate system
and it looks as if there is no way to convince the OSX certificate back end
to accept such a certificate without bundling it with a signed application.
Is it true?

On Windows, we get the following log:

[2020-12-22 11:27:49.454782] [0x00000cc8] [info] OctoPrint: Get
version at: https://octo/api/version
* Trying 192.168.aa.bb...
* TCP_NODELAY set
* Connected to octo (192.168.aa.bb) port 443 (#0)
* schannel: SSL/TLS connection with octo port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: ALPN, offering http/1.1
* schannel: sending initial handshake data: sending 190 bytes...
* schannel: sent initial handshake data: sent 190 bytes
* schannel: SSL/TLS connection with octo port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with octo port 443 (step 2/3)
* schannel: encrypted data got 3547
* schannel: encrypted data buffer: offset 3547 length 4096
* schannel: next InitializeSecurityContext failed: Unknown error
(0x80092012) - The revocation function was unable to check revocation
for the certificate.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with octo port 443
* schannel: clear security context handle
[2020-12-22 11:27:49.716445] [0x00000cc8] [error] OctoPrint: Error
getting version: SSL connect error:
schannel: next InitializeSecurityContext failed: Unknown error
(0x80092012) - The revocation function was unable to check revocation
for the certificate.
[Error 35], HTTP 0, body: ``

Problem with connection to Octoprint using SSL (HTTPS) · Issue #5506 ·
prusa3d/PrusaSlicer (github.com)
<https://github.com/prusa3d/PrusaSlicer/issues/5506#issuecomment-749495597>

Frankly we are out of our witts. What should we do to have the self-signed
certificate accepted by Darwin back-end and by Windows back-end?

Why is Darwin back-end refusing the self-signed certificate even if it has
been marked as trusted in the keychain?

Why is Microsoft back-end refusing the self-signed certificate? Why is the
Microsoft back-end give us "The revocation function was unable to check
revocation for the certificate" if we know that there is no way to verify
revocation of a self-signed certificate?

Shouldn't libcurl offer a switch to disable revocation check of self-signed
certificates?

I am sorry if I sound confused, because I am.

Thank you,
Vojtech
Daniel Stenberg via curl-library
2021-04-10 22:05:00 UTC
Permalink
since we switched libcurl to use the system provided back-end, self-signed
certificates evaluation fails on Windows and OSX.
I'll let you in on a secret: Schannel and Secure Transport are weird beasts
and not at easy to get to do what you want as some of the other TLS
libraries... That's just my opinion of course.
it looks as if there is no way to convince the OSX certificate back end to
accept such a certificate without bundling it with a signed application. Is
it true?
What happens if you add the CA cert to the normal CA bundle and use that?
Doesn't that work?
Why is Darwin back-end refusing the self-signed certificate even if it has
been marked as trusted in the keychain?
I don't know. Debug and find out?
Shouldn't libcurl offer a switch to disable revocation check of self-signed
certificates?
libcurl doesn't know "self-signed". but you can ask it to disable revocation
checks with CURLOPT_SSL_OPTIONS's CURLSSLOPT_NO_REVOKE bit.
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://www.wolfssl.com/contact/
Tomalak Geret'kal via curl-library
2021-04-11 11:47:34 UTC
Permalink
Post by Daniel Stenberg via curl-library
Post by Vojtěch Bubník via curl-library
Shouldn't libcurl offer a switch to disable revocation
check of self-signed
certificates?
libcurl doesn't know "self-signed". but you can ask it to
disable revocation checks with CURLOPT_SSL_OPTIONS's
CURLSSLOPT_NO_REVOKE bit.
For what it's worth, I am turning this option on for any
build using Schannel in an environment that may use
self-signed certificates, or root certs that do MITM on a
corporate network; security issues with this aside, it's
common practice in many corporate networks, and adding this
option mimics what browsers do in this scenario.

It is kind of a shame that the optoin is an all-or-nothing
proposition, but I get why.

Cheers

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette

Loading...