New extension manager and issues with corporate certificates

Manually adding the certificates inside the Slicer.crt fixed the problem. I can now use the extension manager.

But where do we go from here? This is not a solution for us, just in our center there about 30-40 different installations of Slicer in dozens of computers (each user account needs to be fixed individually). There are many other clinical centers and researchers at SCH who use Slicer that will suffer from this.

@mikebind @ezgimercan do you encounter this certificate issue at your work computers? (try with a new installation)

Try to figure out why wget does not have this issue.

  • Is it because curl can find the certificate on your system? Can you check where self-signed certificates are stored on your computer?
  • Maybe because curl uses the system OpenSSL? You can consult with @jcfr, currently evaluating building Slicer without bundling OpenSSL - see #5663)
  • Is it because SSL verification is turned off? By default it should be enabled, but if your system has a special OpenSSL configuration and the user is not concerned about security then we could allow disabling SSL verification.

Only about 1 of 10 Slicer downloads are on Linux, and they are expected to be able to deal with things like installing self-signed certificates. It would be important to know if this is an issue on Windows and macOS as well.

This happens on both windows and Linux computers that are connected to our network. We are primarily a windows shop, which is the concern. As you said, most Linux users are used to following these kinds of instructions, but quite concerning for windows.

Our windows desktops use a centralized image, in which I presume the certificates are baked. I can try to find path where those are, if that’s helpful.

On Windows, there is a certificate store where you all the trusted certificates are saved to. It would be nice if you could check that Python curl and requests retrieve certificates from there (you can try that for example by temporarily removing your self-signed certification from the store).

By the way, I don’t understand how a large organization cannot afford to pay a few hundred dollars to get the certificate properly registered. This investigation already costs more than what they would need to pay for it. Doesn’t this untrusted certificate cause all kinds of issues for many other applications? How can you connect devices that do not allow installing self-signed certificates?

I have no idea why they are not doing this, and I unfortunately i have no answer for it…

I primarily work on my personal laptop, but I can confirm that I ran into the same problem on computers within the hospital corporate network, @muratmaga.

Could you try using the updated Slicer.crt associated with ?

For reference, certificate bundle was re-generated following these instructions. See Base/QTCore/Resources/Certs#readme

Moving forward, I suggest we also add a weekly GitHub Actions workflow that would be automatically run the script and create a pull-request.

If you mean, I just replace the default Slicer.crt in today’s preview with this one, it didn’t work. (same issue with extension manager).

I believe Jc meant to download this one and if it works then he’ll merge the PR and it will be in tomorrow’s preview.

As far as I understand, the problem is that the certificate that @muratmaga’s institution is using is not trusted (self-signed). This untrusted certificate has to be manually merged into the Slicer.crt file.

The interesting thing is that curl in the Slicer interpreter works. It would be nice to do the same what curl does.


Every Tuesday at 11.30am UTC (7.30am ET), a GitHub workflow will now be triggered to re-generate the Slicer.crt bundle and create a pull-request if has changed since the last run. See update-slicer-certificate-bundle.yml

That’s what I did. Downloaded that crt file, overwrite the one preview version came with. Had no effect (errors persist). As Andras said the only mitigating solution we have right now is to copy and paste the root certificates in SLicer’s certificate. But since this needs to be done on per user basis, it is not much of a solution.

As also andras pointed out I do NOT encounter the SSL handshake error when I use wget inside the Slicer’s python environment, but get the error if I try to access the file directly via QT. So somehow wget is finding the correct certificates from the windows and but not QT.

Have you confirmed that wget does not simply skip the SSL verification? Does wget fail if you temporarily remove the self-signed certificate from your system?

Have you checked if you disable SSL verification in the Qt request then it completes successfully?

Could you ask your IT admins about why don’t they get a proper certificate from a trusted authority? If there is a valid use case then it can justify investing Slicer development time into this; but if this is just a bad decision of a single organization then it does not make sense for Slicer developers to pay the price.

It is not easy to remove the certificates fro`

It is not easy to remove the certificates from these windows boxes as far as I can tell. In normal wget you have to explicitly specify to skip ssl via --no-check-certificate parameter. I am not how it is done in its python implementation, but will check.

I agree and already reached out to the institutional security team that this is turning to be a big issue for us. However, whatever/why ever they are doing is not impacting regular windows operation. So from their perspective this is also a corner case that they need to get more info to come up with a solution. It appears to be a combination of QT and Slicer build settings. The only other QT based application I used on these windows machines is Rstudio, and I have no issue getting https:// resources on them (no handshake error).

You can open the local machine certificate manager by hitting the windows key and typing certlm.msc. You can then find the self-signed certificate and disable all uses, restart the computer, and see if wget in python still works.

You can also run wget step by step in a Python debugger to see what certificates it is using and from where it gets them.