Closed apizz closed 4 years ago
My suggestion would be to add the the self signed cert as a trusted system cert to the OS and not modify any of the script. This is the expected behavior when running python from linux if you have an untrusted certificate. If you're running some other OS I would do a little googling: python ssl certificate store <your OS>
.
Alternatively you can modify all of request lines with verify=false
which isn't nearly as safe imho, but it's up to you. Either way, I probably won't be working on any code to accommodate this myself. Good luck!
After finally getting the bulk of our assets imported into Snipe-IT, I've started testing syncing them with jamf2snipe ...
We use Jamf's built-in cert authority and as a result, we're getting failures when trying to run jamf2snipe as it's trying to verify the Jamf connection. In my browser, when I go to our JamfPro instance I can confirm in the console that the return code is
401
, and yet it's still saying it can't reach the host, soJAMF_UP
becomesFalse
.To test, I temporarily changed https://github.com/ParadoxGuitarist/jamf2snipe/blob/master/jamf2snipe#L299 to be
JAMF_UP = True
. However, after making this change I get a different error:We use another tool git2jss and which has a script, download.py to pull scripts and EAs into version control and sync.py to push them back up to Jamf. In both, there is a flag to not verify SSL.
I'm wondering if that code could be borrowed so that those of us with self-signed Jamf certs can still use this awesome tool to sync assets to Snipe-IT.
Let me know if you need more details.