Vojtěch Bubník via curl-users
2021-04-07 12:04:26 UTC
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
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