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/265862/highlight/true#M243966
Chris
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
After contacting Jamf Support, I can close this thread:
- 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,
- 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.
- 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.
- 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.