Posted on 09-27-2014 02:35 AM
I've got a CentOS VM (yes, I know, not actually supported) with JDS installed. When I try to enroll with the JSS, I get this error in the log:
2014-09-27 02:13:34,352 INFO Creating configuration file for https://casper.lynda.com:8443/
2014-09-27 02:13:34,932 INFO Starting Enrollment
2014-09-27 02:13:34,939 ERROR Communication error with the JSS
2014-09-27 02:13:34,939 ERROR (77, 'Problem with the SSL CA cert (path? access rights?)')
Traceback (most recent call last):
File "<string>", line 1143, in _perform
error: (77, 'Problem with the SSL CA cert (path? access rights?)')
Solved! Go to Solution.
Posted on 09-30-2014 05:46 AM
We have the same issue, it works perfect to connect with Curl from the JDS to casper but the jamfds cannot run.
In our case the update coincided exactly with a security release for some NSS tools. A downgrade to these versions made everything come back to life:
nss x86_64 3.16.1-4.el6_5 sl6rolling-security nss-sysinit x86_64 3.16.1-4.el6_5 sl6rolling-security nss-tools x86_64 3.16.1-4.el6_5 sl6rolling-security nss-util x86_64 3.16.1-1.el6_5 sl6rolling-security
Posted on 09-30-2014 11:58 AM
Hey all,
Just to let you know, we did get this behavior filed as a defect this afternoon. For reference, the ID number is D-007767.
If you'd like to contact your Technical Account Manager to open up a case and get it attached to the defect for tracking, please feel free to get in touch with them by sending an e-mail to support@jamfsoftware.com, giving them a call, or using the My Support section of JAMF Nation.
The current workaround is to roll back the packages that @paesbiger posted further up in the thread.
Thanks!
Amanda Wulff
JAMF Software Support
Posted on 09-27-2014 12:20 PM
Have you already ruled potential firewall issues?
Have a look at :
http://stackoverflow.com/questions/17064601/curl-not-working-error-77-for-ssl-connections-on-centos-for-non-root-users
Posted on 09-28-2014 08:16 AM
RHEL6.5 here. We just upgraded our test environment from 9.31 to 9.51 and are seeing this message after upgrading the root JDS. Our child JDSs have not been updated yet and are still communicating with the JSS as usual. Firewall rules are fine and permissions on the certs look fine.
I'll be playing with this today and let you know if I find anything.
Posted on 09-28-2014 11:01 AM
Me too. :(
Posted on 09-29-2014 09:07 AM
ditto...
This does appear to be related to the upgrade to JAMF 9.51 as our pre-upgrade environment (through testing) works without a hitch. Any previous to 9.51 JDS downloaded package works, but nothing since the upgrade was enacted. An upgrade fails with error 77 as well. So that is now NEW packages get replicated/deployed and no upgrade from a non 9.51 JDS can occur.
UPDATE: Some other JDS sites are using Ubuntu and those were upgraded without issue. So it appears to be limited to RedHat-based distributions, if anyone else would like to confirm that. In the meantime, I have opened up a ticket with JAMF so see if they are aware of the issue.
Posted on 09-29-2014 11:36 AM
Strange thing is, we're still on Casper 9.32 and so I'm trying to install JDS 9.3. It seems this is not just a 9.51 issue.
Posted on 09-30-2014 05:46 AM
We have the same issue, it works perfect to connect with Curl from the JDS to casper but the jamfds cannot run.
In our case the update coincided exactly with a security release for some NSS tools. A downgrade to these versions made everything come back to life:
nss x86_64 3.16.1-4.el6_5 sl6rolling-security nss-sysinit x86_64 3.16.1-4.el6_5 sl6rolling-security nss-tools x86_64 3.16.1-4.el6_5 sl6rolling-security nss-util x86_64 3.16.1-1.el6_5 sl6rolling-security
Posted on 09-30-2014 11:00 AM
Rolling back to the previous nss packages fixed it for us to - thanks. Now if we can just get JAMF and RedHat to figure out what is broken.
Posted on 09-30-2014 11:58 AM
Hey all,
Just to let you know, we did get this behavior filed as a defect this afternoon. For reference, the ID number is D-007767.
If you'd like to contact your Technical Account Manager to open up a case and get it attached to the defect for tracking, please feel free to get in touch with them by sending an e-mail to support@jamfsoftware.com, giving them a call, or using the My Support section of JAMF Nation.
The current workaround is to roll back the packages that @paesbiger posted further up in the thread.
Thanks!
Amanda Wulff
JAMF Software Support
Posted on 09-30-2014 01:30 PM
Thanks @amanda.wulff and @paesbiger!
Posted on 09-30-2014 02:02 PM
yum downgrade nss nss-sysinit nss-tools nss-util nss-softokn
Once NSS was downgraded, I was able to enroll successfully. Thanks again!
Posted on 10-01-2014 07:20 AM
This worked for us as well. Although initially I re-ran the installer after downgrading instead of just enrolling...which was hilarious since the packages just end up getting upgraded again.
Posted on 10-06-2014 04:13 AM
My, do you have in the meantime a fix for that ? When will ads be compatible with rhel7 ?
Posted on 10-06-2014 08:47 AM
Downgrading didn't work for an install today, any other ideas.
Posted on 10-06-2014 08:52 AM
As @rdwhitt alluded to, you install JDS and have the enrollment fail, then downgrade nss, then re-enroll with ```
sudo jamfds enroll
```
In my experience, doing a full reinstall after downgrading nss didn't work.
Posted on 10-06-2014 05:19 PM
Thanks @stevehahn ! Tried to run the full installer again and got the error, even after a downgrade. Ran the jamfds enroll command and all is well now!
@jonny74bit Downgrade the packages and just run jamfds enroll. Don't run the full installer again.
Posted on 10-06-2014 05:20 PM
Something cake'ed up the downgrade. After a few magic 'yum' commands to fix the downgrade the "jamf enroll" worked fine. Thanks for the help!
Posted on 10-15-2014 01:33 PM
Jonny what perhaps were those magic yum commands?
Posted on 10-20-2014 01:16 PM
Hit the same issue. Downgrade did not help.
Posted on 10-27-2014 03:04 PM
Keep in mind that right now you will likely have to downgrade twice in a row since the NSS packages were updated again.
If you run "yum list nss" and see 3.16.1-4.el6_5, you should be good.
If you see 3.16.1-14.el6, run the downgrade command twice.
Posted on 10-28-2014 07:33 PM
During a jumpstart today we noticed that you needed to create a symlink of the /usr/bin/httpd binary to /usr/bin/apache2
Apparently the script is designed for Ubuntu, and on Red Hat the binaries have different names.