Revocation server offline?  

RE: Revocation server offline?

Okay... I don't know if someone at Prusa did something, but it is now working.  Both download of Configuration Updates and sending to the printers is okay now.

To whoever fixed it... Thank you. 

RE: Revocation server offline?

Well... It's not working again. Same error. I was just printing earlier today and within 10 minutes after my last print, I started getting this error again.

I haven't changed anything in Prusa Slicer or my computer or anything else.

Does anyone have any ideas what is going on and how to fix it... permanently?

Thanks!

RE: Revocation server offline?

I suspect that the slicer cannot contact a server to confirm the certificates.  SSL (Secure Socket Layer) is a security method.  Certificates are revoked from time to time and depending on how the software is written, it may need to confirm with the server.  I had a similar issue on a laptop where the battery died.  Certificates were out of date since the laptop went back in time.  🙂

There may be nothing you can do and may be related to an internet issue.

RE: Revocation server offline?

Thank you for the response, @Robin_13.

You are correct. Prusa Slicer isn't able to contact a server for some reason, but I don't believe it's an internet issue.

While a transient internet issue can happen, I have already verified that there is no internet issue between my workstation or network and the Prusa3D servers and the certificate revocation servers. The revocation servers that appear to be applicable ( http://r13.c.lencr.org/46.crl and http://c.pki.goog/we1/T58q3x0jyXI.crl) are online and reachable, and I pulled the CRLs (certificate revocation lists) with no problem on my Linux server (same network as the Prusa Slicer). I've also connected directly to the Prusa3D servers with no issue.

Accessibility of the Prusa servers is also evident because Prusa Slicer accesses Prusa Connect to show printer status, manage files on the printers, and stop/start prints that are already uploaded to the printer. The only functions that don't work are "Send to Connect" from within the Plater tab and "Check for Configuration Updates" from the menu bar. "Configuration Wizard" also throws the error, but it somewhat works because it's using cached configuration information. It just can't get any updates that are published by Prusa.

Using Wireshark on my workstation (where I run Prusa Slicer) I can see that it isn't even attempting to access the CRLs via the published CRL URL, which is on HTTP port 80, as per applicable attributes in the certificates. The only traffic I see is on HTTPS port 443.

It fails while "Downloading Resources: prusa-fff archive" or when trying to upload a print to Prusa Connect. It's sad that the error message doesn't specify which site is being affected/accessed to help narrow down the issue.

My Prusa printers (MK4S and CORE One) are online and I can monitor them via the Slicer (they use different, internal certficates). And I can send prints via the web interface (connect.prusa3d.com) to the printers. But I cannot send prints via the Slicer or "Check for Configuration Updates". I'm guessing it's a peculiar issue with  the API on connect.prusa3d.com, but haven't had time to dive deep enough to have a definitive answer. 

FYI: Certificates are not normally revoked periodically. They expire based on the Certificate Authority policy used to create the certificate. I've already checked the certificates that Prusa Slicer uses. They are not expired. The certificates show validity into 2026.  Additionally, a certificate is usually only revoked if it is compromised to prevent exploitation by bad actors.

IMO, Prusa Slicer should not stop dead in its tracks if a CRL server is unreachable. At most, it should prompt the user to ask permission to continue.

Workaround: Slice in Prusa Slicer. Export G-code. Upload G-code file to printer via Prusa Connect (either web or Slicer app), set to Print.  It's not ideal and adds extra steps, but at least I can print this way without needing to shuffle USB flash drives back and forth. 🙁

RE: Revocation server offline?

Good description of the problem. 

I don't use Prusa slicer to connect to my printer.  I have used Octoprint early in the game.

I feel that certificates today should be on a secure port, not port 80.  Many servers won't even allow http access anymore, for this purpose.  Many severs will redirect a http connection to https so people don't have to specify https in the configuration.  It can be a pain when browsers do that.

It may be a server load issue.  Wireshark is a good tool for finding these issues.

As more and more devices get connected to the net, these types of issues are going to get worse.  Especially with IP6 and privacy.

For a test, I tried to connect to both of your links.  First one allowed me to download a file with an insecure warning.  Second one came up with file not found and insecure.  Both tested in Firefox.  I can ping the server.

I wonder if there is a process that downloads from both sites and does a comparison.   One fails, no check.

RE: Revocation server offline?

Certificates are on a secure port. The Certificate Revocation List (CRL) server, however, is on port 80 to prevent a "circular reference" when a certificate tries to validate itself. It wouldn't be able to validate itself on the same port that it's trying to secure. 😉  Thus, CRL servers must operate on port 80 to prevent this conflict.

It's not a load issue. Wireshark didn't give me any evidence of load issue. And the CRLs pulls up just fine on all other workstations on my network (either in a browser or a cURL command-line. So it's not my network that's the problem.

Yeah. I'm getting 404 on the 2nd link, too. I'm not at my workstation to check what changed there. It's likely that the certificate was updated as it was nearing its expiration, and the CRL URL likely changed as well.

There shouldn't be any comparison. The CRL is an authoritative source for revocation. A comparison would defeat the purpose of being an authoritative source because the application wouldn't know which one to trust.

It's still not working for me and it used to work 100% reliably until I first posted about this issue. IMO, the app still should NOT just refuse to work if the CRL is unreachable. It should prompt the user and allow the app to continue. This is *not* a mission critical app or critical infrastructure. It's a hobby 3D printer! LOL

Thanks for the thoughts on this annoying issue. I'll still keep fighting it. I have a technical workaround I can try, but it involves setting up a DNS server to trick Prusa Slicer to look at another server for the CRL. It's a lot of work for little gain - especially since I have a workaround for the moment.

Thanks, again.