Looking for help with NetSUS 5 CSR. The built-in GUI generated CSR does not meet our minimum key size of 4096 bit. I have generated a CSR manually using openssl command from my mac, submitted the CSR and received certificate & certificate chain from our MS PKI server. When attempting to submit the Private Key, Certificate and CA Bundle through the NetSUS GUI, I get a response of Invalid CA bundle. . Is there a way to submit certificate through the shelluser account / command line?
So @CGundersen - we made a private key using "certificate signing request" -> we used this then for open-ssl - csr on the web app (we were using Comodo) and then we used the CSR to request the cert -> for the CA bundle, it had to have the trust as root and not intermediary. It looks like it accepted after that.
I can't really detail too much more than that since one of our Linux Sys Admins was doing this, but I hope that helps, and I wanted to relay the information.
Ditto @Kmartin . I've run into the same issue. Actually, we had a vm built for 500GBs (as recommended), and it crashed because the sync ran over. I had one of our infrastructure guys get it back up and going; however, once it ran over, I could no longer log in (something to keep in mind). Since we only have about 50 machines in our environment, I just chose to grab the updates directly from Apple instead for now instead of downloading them locally. However, if we grow, we'll have to revisit the issue.
There's probably a way to look into the local updates and find the files and remove them; however, it's like netsus 5.0 isn't smart enough to delete the deselected catalogs and just keeps them stored.
Also, I think the purge only removes deprecated updates, not the most recently versions of the updates on the other OSes if I'm not mistaken.
On my end, if someone has been successful at getting https to work in the main server URL, please let me know how. It just comes up in red (even though I have a cert in there now), and that doesn't seem to work to just change it to https.
Is that a known bug, or is everyone else experiencing that once they got the cert entered? I'm about to throw in the towel and just use the workaround to use http instead via github's disabling route for Mojave, but just curious if anyone has had success/what you did.
@thomast I have see this issue too, as have others on Slack. However, it appears that I do have https working on my 10.14 Mojave managed clients (my Jamf SUS configuration profile has a https prefix and my clients appear to be honoring this setting).
I opened a case on this (an other NetSUS-related questions) but not get confirmation on this specific topic.
@ken.thepvongsa No, getting the Certificates to work is a nice to have and not a must for us. Only IT access our NetSUS portal and we ignore the https warning. As for the catalog files, we copy them to our externally hosted website so they are accessible internally and externally without VPN.
@thomast Correct. Profiles are using https 443. The server base URL is http 80 (as are the subsequent catalogs branch URLs).
Netstat shows SUS connections are working. Telnet works for both 80 and 443. SSL checker sites complain. Not sure I trust them. Need to dig into the server logs more before I go live.
Clients all have the required certs - also managed via Jamf.
Cert Bundle is the entire trust chain in a single archive I think. My cert team figured it out and even added a SAN (Subject Alternative Name).
I didn't see that specific issue (I was able to sync newest updates the same afternoon that they were released by Apple), but I did notice that my catalog branch that is set to automatically enable new updates didn't work as expected. I had to explicitly toggle 'Auto-Enable' off and back on again before 10.14.2 would show up on my clients assigned to that catalog.