After following up with our hospital IT, the problem was related to certificates. As a preferably temporary solution, they added an exception to SSL inspection for slicer-packages.kitware.com. This resolved the issue and enabled downloading of extensions via the extension manager.
However, they did ask me to investigate adding a certificate to Slicer so that they could remove this exception. The discussions in this thread seem quite relevant:
but I have to admit I don’t really follow how this all works. If I go to slicer.org (as an example domain) in a browser and check the certificate viewer, the “Issued By” section says:
This was also the case for slicer-packages.kitware.com before the exception was added, and, if I am understanding correctly, it was the absence of this Zscaler certificate in the Slicer crt file which led to the failed download. Zscaler is the software installed on hospital issued laptops for use outside the hospital network so that they can behave as if they are inside the hospital network (I would call this a VPN but since we’re actually talking about details of networking and security I don’t want to accidentally misuse a technical term).
I’d love to find a solution for this which both allowed the hospital to remove the exception for slicer-packages.kitware.com in their firewall AND allowed Slicer users inside the network to use the extension manager normally. I can try to rebuild Slicer.crt with an additional Zscaler certificate added following the thread linked above, but I don’t yet understand how to do that (and, as @muratmaga pointed out, this isn’t a great general solution for clinical Slicer users who may not be technically savvy). On the other thread, there is some discussion of “self-signed” certificates, but I am not sure how to tell if this certificate is self-signed or not. The hospital IT person I worked with was competent and helpful, and I think would be willing to help me troubleshoot further if I knew what questions to be asking or what solutions to be trying.
I find some potentially helpful information on this page: Choosing the CA Certificate for SSL Inspection | Zscaler. I am guessing the hospital is using the first option, SSL Inspection Using Zscaler’s default intermediate CA certificate, which looks like it uses a dynamically generated and signed certificate.
Here are some options for moving forward:
- explore turning off ssl verification from the Slicer side of the connection so that Slicer does not cancel the download because it doesn’t recognize the zscaler certificate
- explore adding the zscaler certificate to Slicer’s set of trusted certificates
- explore having Slicer get the set of trusted certificates from the OS (or something like that) so that it will trust the zscaler certificate the same way the browser does
- explore pushing to have the zscaler certificate added to the outside trusted repository that Slicer builds its list of trusted certificates from (looks like maybe mozilla?). I think maybe this is essentially what is meant by having it not be self-signed? However, if the certificate is being dynamically generated and signed and involves intercepting and inspecting traffic (see zscaler link above), this approach probably isn’t possible.
Any suggestions about which of these I should pursue? @lassoan