grokability / jamf2snipe

Import and sync assets from a JAMFPro instance to Snipe-IT asset management.
MIT License
108 stars 55 forks source link

JamfPro Failure with Self-Signed SSL Cert #15

Closed apizz closed 4 years ago

apizz commented 4 years ago

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, so JAMF_UP becomes False.

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:

requests.exceptions.SSLError: HTTPSConnectionPool(host='jss.<our_org>.com', port=8443): Max retries exceeded with url: /JSSResource/computers (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1076)')))

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.

ParadoxGuitarist commented 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!