ADCS: Format of server certificate uploaded to Jamfcloud?

[ChrisUrsich]

In Jamfcloud, when configuring a new ADCS certificate authority (Global Management > PKI Certificates > New Certificate Authority > ADCS), the interface requires me to upload a Server Certificate file.  What are the requirements for the format of this file?

Specifically, assuming that the file contains more than just a single, self-signed cert,

1. Which elements of the full certificate chain should be included in the file?
1. Leaf cert only
2. Leaf cert + intermediate(s), but not root (This is what’s normal for a web server.)
3. Full chain: Leaf cert + intermediate(s) + root
2. If more than just the leaf is needed, should the elements should be provided in a leaf-first PEM bundle, as is typical (for example) for Apache?
3. If the root isn’t included, is there someplace else where I am supposed to tell Jamfcloud to trust my internal CA root?

Thanks,

Chris

[ChrisUrsich]

Whether I use the two certificates that are created by the .\deploy.ps1 script, or instead use two certificates I generate from my own internal CA, a Wireshark packet capture shows that Jamfcloud is not accepting my AD CS Connector server's certificate, and closes the connection before even attempting any REST API calls.

That description is consistent with what @UserTBD said in

https://community.jamf.com/t5/jamf-pro/adcs-failed-to-inject-certificates-into-the-profile/m-p/26586...

Chris

[Tangentism]

In the two instances I helped set up for our customers recently, one worked with the self issued cert from the ADCS added to the PKI Certificates store, while the other we had to add their third party issued cert for it to get through their firewall.

Also, on the config profile, I added the issuing CA and the root CA certs as well.

Theres a good troubleshooting guide in a post a few below the one you linked thats stored here

[ChrisUrsich · Accepted solution]

After contacting Jamf Support, I can close this thread:

1. Regarding the main issue of how to format the server certificate, the answer is "leaf only."  Although it isn't phrased exactly that way, the excellent Implementation Note that @Tangentism and Support prompted me to re-read does say,
   1. Jamf Pro does not care what CA generated the server certificate. It only cares that the Server certificate is an exact match for the server public key you uploaded when you configured the PKI settings in Jamf Pro.
   2. the only requirement is that the public key that is uploaded in the ADCS Connector PKI entry in Jamf Pro matches the server's certificate.
      
      
2. Regarding the related issue of my server's certificate being rejected, Support informed me of a known bug, PI103922, introduced in JamfPro version 10.30:  When the admin uploads a certificate to Jamf Cloud as part of the ADCS Connector configuration, Jamf Cloud does not deploy the new certificate onto the secondary Jamf Cloud server, but only onto the primary one.  The secondary server does not receive the new certificate until the server's Tomcat component gets restarted, which does not happen regularly.  Therefore, the customer will get inconsistent results, depending on which Jamf Cloud server happens to perform the call to the Connector.  Until this bug is corrected, whenever the admin changes a certificate, he will need to tell Jamf Support to please cycle Tomcat (by opening a ticket).  Fortunately, this situation should arise quite rarely.