Skip to main content

I am in the process of updating our JSS instance to have a third party cert. This is in anticipation of possibly opening up self enrollment for some users, hate to see them get an unverified prompt when they connect. I have been following the directions from the following article.



https://jamfnation.jamfsoftware.com/article.html?id=115



I was able to generate a keystore fine. I was able to import the root certificate fine. However when I try to import the signed certificate I get an error.



keytool error:java.lang.Exception:Failed to establish chain from reply.



I thought maybe I needed the other certificates listed in the certificate chain but if I try to import them I get an error.



keytool error: java.lang.Exception: Certificate not imported, alias <root> already exists.



Which I take to be expected since I have already imported the top certificate in the chain.



Not sure what I'm doing wrong here, or if I've imported the chain wrong.



Side question, switching the cert from the JSS built in CA to a public won't break anything correct?

Actually I should be more smart.



I changed the aliases of the 2 intermediate certs to inter1 and inter2.



Certificate reply was installed din the keystore.

One more question (other than this won't break anything probably right?). I did this on my local machine, now that I have the .jks file with the correct chain of certificates can I just upload that via the JSS web interface?

Well everything is going swimmingly. Tomcat works, no untrusted SSL cert box required. And HTTPS downloads work finally from the IIS share.

Somewhat off-topic, but if we have an internal CA on-prem, can I use it to sign everything instead of JSS CA? The root and intermediate certificates for internal CA are already installed on all the Macs. If so, would that then make me "trusted"?

Do you mean the tomcat ssl cert or the certs the clients get? You can use an external certificate authority for the device certs, but I don't know exactly what that entails. We currently don't have a requirement for end to end trust in that manner, though we probably should.



IF your just talking about the Tomcat SSL certificate as long as there is a trusted root certificate on the system you shouldn't get the This certificate is not valid or self signed errors when you go to your web interface if you get a signed certificate from your internal CA.



The public cert thing was twofold for me.
A. If we open up end user self enrollment I didn't want them getting an unverified certificate error. If you were self enrolling you wouldn't be able to get your internal root cert on the system until it was enrolled (may not be an issue in your environment).
B. I was never able to get HTTPS working on the distribution point with the IIS self signed certificate. Now I'm just using the cert for the FQDN for tomcat and the IIS share.



B was really the main reason for getting a signed 3rd party certificate. HTTP transfers are fine right now when the JSS is only accessible by internal trusted networks but in the next few months I will be putting a JSS and second distribution point in the DMZ. I want all communication between client and server to be encrypted.



Take all of this with a grain of salt, I only know enough about certificate chains to be dangerous.

Terms & ConditionsCookie settings