Octoprint HTTPS Validation on Mac with 2.3.0  

RE: Octoprint HTTPS Validation on Mac with 2.3.0

We will test it, it may be broken.

RE: Octoprint HTTPS Validation on Mac with 2.3.0

I don't know what is going on. HTTPS connections are established using the curl library, which we updated to a newer version for PrusaSlicer 2.2.0, so there may be dragons.

However, the same curl library is used for downloading print profile updates and this seems to be working fine, the files.prusa3d.com certificate is resolved correctly. Unfortunately the PrusaSlicer team is homeofficed due to the COVID19 and the developers who have Mac don't have R-PI and vice versa, so it will be difficult to verify.

* Issue another request to this URL: 'https://files.prusa3d.com/wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaResearch/index.idx'

*   Trying 185.115.1.124...

* TCP_NODELAY set

* Connected to files.prusa3d.com (185.115.1.124) port 443 (#1)

* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

* Server certificate: files.prusa3d.com

* Server certificate: Let's Encrypt Authority X3

* Server certificate: DST Root CA X3

> GET /wp-content/uploads/repository/PrusaSlicer-settings-master/live/PrusaResearch/index.idx HTTP/1.1

Host: files.prusa3d.com

User-Agent: PrusaSlicer/2.2.0+

Accept: */*

< HTTP/1.1 200 OK

< Server: nginx

< Date: Thu, 26 Mar 2020 16:57:06 GMT

< Content-Length: 6871

< Connection: keep-alive

< Last-Modified: Thu, 26 Mar 2020 16:00:25 GMT

< ETag: "1ad7-5a1c415432a40"

< Accept-Ranges: bytes

RE: Octoprint HTTPS Validation on Mac with 2.3.0

Certainly understand the current developer circumstance, and I am happy to try to help from my end (though I haven't looked at the PrusaSlicer source myself).  I can directly test from my shell using curl 7.64.1, and the request to Octoprint is successful, so I assume that either the curl lib in PrusaSlicer isn't querying Key Chain for the CA certs correctly now, or there is a problem with that lib on MacOS.

I'll clone the repo on my end to see if I can poke around. But, if you have any source files are something that are likely candidates to point me to (for break points, testing, etc.), then it might help get me started faster. 😀 

Thanks and stay safe!

RE: Octoprint HTTPS Validation on Mac with 2.3.0

I verified, that PrusaSlicer 2.2.0 should be using the same libcurl as PrusaSlicer 2.2.1. We are now building on a new build server, that may make a difference. Also PrusaSlicer 2.2.0 is now notarized, which may put some more constraints on what the application may or may not do, I am not sure.

Where did you get your certificate from? Is it self signed? PrusaSlicer never supported self-signed certificates out of the box. Maybe you marked your self signed certificate somewhere in the keychain, that PrusaSlicer 2.1.1 could use it even if it is self signed? I have little idea, the way OSX handles certificates is a mystery to me and based on my experience with signing PrusaSlicer there are outright bugs in OSX and error reporting is really bad. It is a nightmare to debug.

> I also re-downloaded 2.2.1, and tried to connect from it, and my test is successful. 

Is that on the same computer with the same certificate installed in the keychain and with the same OctoPrint IP address and API key?

RE: Octoprint HTTPS Validation on Mac with 2.3.0

> Certainly understand the current developer circumstance, and I am happy to try to help from my end (though I haven't looked at the PrusaSlicer source myself). 

That would be very welcome.

https://github.com/prusa3d/PrusaSlicer/blob/master/doc/How%20to%20build%20-%20Mac%20OS.md

but the script may not be quite up to date.

> I can directly test from my shell using curl 7.64.1, and the request to Octoprint is successful, so I assume that either the curl lib in PrusaSlicer isn't querying Key Chain for the CA certs correctly now, or there is a problem with that lib on MacOS.

libcurl uses SSL implementation of OSX. We build libcurl statically, so you executing curl from command line executes a different libcurl.

> I'll clone the repo on my end to see if I can poke around. But, if you have any source files are something that are likely candidates to point me to (for break points, testing, etc.), then it might help get me started faster. 😀 

Unfortunately I don't know. The OctoPrint happens in OctoPrint.cpp as expected, I have no more hints. As said, the same libcurl downloads data from Prusa's CDN using certified SSL, so at least for some certificates it seems to be working.

It may quite be possible that your self compiled slicer will work. You may also try to remove signature from PrusaSlicer.app, this may lift some sandboxing.

RE: Octoprint HTTPS Validation on Mac with 2.3.0

The cert is signed using an internal CA.  I have the CA marked as trusted in KeyChain, which is why the cert is trusted using the other tools that I mentioned (browsers, curl -- in a shell, wget, etc.).  Previous versions of PrusaSlicer trusted the remote cert successfully; I have both the 2.3.0 and 2.2.1 release installed on the same system, and the error only presents in 2.3.0.

I doubt the notarization would impact the functionality since the app sandbox constraints are managed via the build process and not notarization...but, I could be wrong.

Looks like there have been changes to Http.cpp lately, too.  I'll see if I can build the app on my end and debug a bit.

RE: Octoprint HTTPS Validation on Mac with 2.3.0

> Looks like there have been changes to Http.cpp lately, too.

I don't see anything suspicious in there.

This commit 1123689a226b243c15ca0748ebb5f9f029abe830

is not contained in PrusaSlicer 2.2.0, though it solves a similar issue on Linux, where each Linux distro stores the CA file somewhere else.

RE: Octoprint HTTPS Validation on Mac with 2.3.0

I am also running into the same issue as Scott with a trusted root ca self signed cert not working on macOS 10.13 and the latest version of Slicer. If I downgrade to 2.1.1, I am able to connect with the same settings. Happy to help troubleshoot!

RE: Octoprint HTTPS Validation on Mac with 2.3.0

Hi, i have not found a solution yet (other then just not using https) but I would like that I have the same issue with a internal CA signed certificate deployed on Octoprint.

RE: Octoprint HTTPS Validation on Mac with 2.3.0

Has this been resolved?  I am unable to find a solution  Running current version of Octopi, prusaslicer and macOS Catalina 10.15.7. Prusaslicer will not connect to octopi.  Any help would be helpful.

Thanks

RE: Octoprint HTTPS Validation on Mac with 2.3.0

Just found I have the same problem. As with the OP, SSL is working everywhere else -- even in Safari on a Mac. Running my own trusted CA and an HAProxy SSL cert with SAN data included (Safari insists).

I can use curl (v7.64.1 macOS Catalina) to manually access and verify my OctoPrint API's SSL certificate over HTTPS:// as follows ...

curl --insecure -v  https://opi0.home/api/files  -X GET -H "X-Api-Key: 13285378953B444F89CFEEE61E52E7E4" bryan@mellow
Note: Unnecessary use of -X or --request, GET is already inferred.
* Trying 192.168.1.177...
...
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: C=NZ; ST=Wellington; L=Upper Hutt; O=Gruvin & Co.; OU=Workshop; emailAddress=******@gmail.com; CN=opi0.home
* start date: Feb 6 05:43:01 2021 GMT
* expire date: Feb 6 05:43:01 2022 GMT
* issuer: C=NZ; ST=Wellington; L=Upper Hutt; O=Gruvin & Co.; CN=OPI0 CA
* SSL certificate verify ok.
> GET /api/files HTTP/1.1
> Host: opi0.home
> User-Agent: curl/7.64.1
> Accept: */*
> X-Api-Key: ********************************
...
...
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Content-Length: 1110
< Etag: "96547596f087180483ee2fac8e3304ea5d2b27cf"
< Last-Modified: Sat, 06 Feb 2021 02:23:34 GMT
< Cache-Control: max-age=0
< X-Clacks-Overhead: GNU Terry Pratchett
< X-Robots-Tag: noindex, nofollow, noimageindex
< X-Content-Type-Options: nosniff
< X-Frame-Options: sameorigin
<
{"files":[...],"free":13184163840,"total":15105363968}
* Connection #0 to host opi0.home left intact
* Closing connection 0

The "Test" button in "Edit Physical Printer" within PrusaSlicer v2.3.0 however complains same as for OP ...

Could not connect to OctoPrint: SSL peer certificate or SSH remote key was not OK:
SSL: certificate verification failed (result: 5)
[Error 51]
Note: OctoPrint version at least 1.1.0 is required.

Running OctoPrint v1.5.3, under Python 3.8

Anything else I can do to help?

RE: Octoprint HTTPS Validation on Mac with 2.3.0

This is our conversation with the libcurl author:

-----------------------

[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: ``

--------------------------------

from the libcurl author:

--------------------------------

> 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.

RE: Octoprint HTTPS Validation on Mac with 2.3.0

We have two distinct errors here:

• revocation check failure
  • https://github.com/prusa3d/PrusaSlicer/issues/5506
  • https://github.com/prusa3d/PrusaSlicer/issues/3120
• certificate verification failure
  • https://github.com/prusa3d/PrusaSlicer/issues/5984.

With the following versions I can reproduce the certificate verification failure:

• Prusa Slicer 2.3.3+x64
• OctoPrint 1.6.1
• macOS 11.3

OctoPrint: Error getting version: SSL peer certificate or SSH remote key was not OK:
SSL: certificate verification failed (result: 5)
[Error 51], HTTP 0, body: ``

A manual curl (7.64.1) request to OctoPrint via macOS Terminal or even with Safari is successful and shows no errors. So the verification of the certificate is working in general but not in Slicer.

Is there any known workaround next to using HTTP?

RE: Octoprint HTTPS Validation on Mac with 2.3.0

I brute forced a self signed certificate onto the end of /etc/ssl/cert.pem on Mac os 11.5.2 and the test and connection works i.e. outside of the keychain process. So I will try and test on a clean virtual mac build and see if this is part of the problem.

RE: Octoprint HTTPS Validation on Mac with 2.3.0

Temporarily moved cert.pem and generated failure

Error uploading to print host:
Problem with the SSL CA cert (path? access rights?):
SSL: can't load CA certificate file /etc/ssl/cert.pem
[Error 77]

Tried loading as file in /etc/ssl/certs/octoxx.xx.pem  and doesn't work

several articles about the problem offer a similar hack to export keys from keychain using "security" function to generate a /etc/ssl/cert.pem  as it will be overwritten during osx upgrades.  So more investigation required. 

Prusa Slicer 2.2

I think I'm encountering the same problem with 2.2, MacOS 10.15.7.  I would love for this to "just work" with my System Keystore.  But it doesn't.  I would be happy if I could just give it a PEM file and have it used that. Everything I've read is that even built-in curl doesn't use that keystone.

RE: Octoprint HTTPS Validation on Mac with 2.3.0

I found a potential work around for this. It has been working for myself at least.

TLDR:

Remove or comment out the following line in your haproxy.cfg

redirect scheme https if !{ hdr(Host) -i 127.0.0.1 } !{ ssl_fc }

 Then in PrusaSlicer make sure you have "Hostname, IP, or URL" field to http NOT https.

Explanation

I followed this guide: Setup a New Self-Signed SSL Certificate on OctoPrint (“Enable HTTPS”) and connecting worked great from my Mac using any web browser, but couldn't connect with PrusaSlicer. Same error as everyone above is getting.

By disabling/removing that single line it seems to let haproxy accept both encrypted and un-encrypted requests. So I have PrusaSlicer working through standard http and all my web browsers force https.

I am sure there is a security risk by doing this, but now I don't get "warnings" from Chrome/Firefox because OctoPrint supports SSL/https and also PrusaSlicer is happy to use the unsafe/http connection. Hopefully they can get this fixed soon.

Software Version

PrusaSlicer version : 2.3.3
OctoPrint version    : 1.7.2
OctoPi version         : 0.18.0
macOS                     : 11.6 (20G165)

RE: Octoprint HTTPS Validation on Mac with 2.3.0

@dcorbin13

> Everything I've read is that even built-in curl doesn't use that keystone.

Unfortunatelly it may be the only "solution" on OSX: To recompile PrusaSlicer's built-in libcurl to use OpenSLL library, not the "secure sockets" library built into OSX. The integrated library is considered "wonky" by the libcurl developers and if @dcorbin13 claims that even the built-in curl distributed with OSX may be compiled against OpenSSL, we likley should. I believe the claims that some very old PrusaSlicer or Slic3rPE worked may just mean the same, that libcurl (maybe as a Perl plugin at that time) was linked against OpenSSL. We will not do that before PrusaSlicer 2.4.0 release though.

@AhoJmQGATdXi

> Then in PrusaSlicer make sure you have "Hostname, IP, or URL" field to http NOT https.

I don't think this is a solution, you may just disable the haproxy in general.

You would not believe how much time we already invested into this OSX wonkiness issue. The documentation by Cuppertino is very bad, errors reported by the library undocumented. We are stumbled in the darkness and replacing with OpenSSL on OSX is likely the only way. 

On Windows 10 we are using the system provided "secure sockets" library, which behaves a bit better than OSX, thus we were able to work around self-signed certificate issues in PrusaSlicer.

RE: Octoprint HTTPS Validation on Mac with 2.3.0

@vojtech-bubnik

> I don't think this is a solution, you may just disable the haproxy in general.

Thank for your clarifying and you are correct that this is not a solution what so ever. However, at least for myself, this workaround solves the "this website is not secure" warning in Chrome & Safari while also letting me upload to OctoPrint/OctoPi directly from PrusaSlicer. It is simply a convenience and cosmetic band-aid around this frustrating macOS wonkiness.