Using JSS CA to sign OSX Configuration Profiles

[mgshepherd]

I'm in the process of trying to creating a slimmed download mobileconfig file so that my machines that are running 10.13 will have the FV key escrowed. I've followed the recipe provided from this link however I've done everything down to step 7. At this point I got totally confused and frustrated when it comes to certificates and keys. From what I understand I can sign this mobileconfig using either a signing certificate from the Apple Dev. site or I can generate one using the JSS CA. I would much rather use the one provided from the JSS since my machines are already trusting this. In saying that I'm having a time getting the items in order so that I can accomplish this. If I log into my JSS Cloud instance and make my way over to the PKI section I can easily down the CA there. If I import this into my keychain and then try to sign the mobileconfig I get "Could not find signing identity for name: blah blah blah".

From what I understand you need both a self-signing certificate and the private keys to in order to sign something. Am I correct in this?

If someone could provide me with some guiadance on this I would greatly appreciate it!

[Jerneheim]

There are maybe more ways than one to skin a ca... but this seems to work as expected.

The built-in PKI in Jamf Pro is limited to three templates when requesting a certificate, a personal certificate, a web-server certificate and an SSO certificate. From what I have experienced it looks like the SSO Certificate is our best choice.

We start by downloading the CA certificate from our Jamf Pro server. We could probably find this in our keychain, as our admin computer most certainly is enrolled, but there is a very convenient downloads button in the PKI section of the Jamf Pro server, so why not make use of that. Save the downloaded pem file somewhere convenient. There will be a couple of files more and everything is easier if we keep them in the same place.

Now we open our favourite text editor and create a configuration file. someName.txt works fine, but for clarity codeSign.cnf or a like makes more sense. We will put some variables into this file that are necessary for our csr. How you name your files is of less importance, but keep in mind that it is easier to know what's what if their names make sense.

We could easily do a web search for a configuration file, but here is an example of how this file can look. Set default values as needed.

# Create a certificate request for code-signing [ req ] default_bits = 4096 # RSA key size encrypt_key = yes # Protect private key default_md = sha256 # MD to use utf8 = yes # Input is UTF-8 string_mask = utf8only # Emit UTF-8 strings prompt = yes # Prompt for dn distinguished_name = req_name # Template dn req_extensions = v3_req # Extra extensions [ req_name ] countryName = Country Name (2 letter code) countryName_default = SE stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = Se localityName = Locality Name (eg, city) localityName_default = Stockholm organizationalUnitName = Organizational Unit Name (eg, department) organizationalUnitName_default = Training commonName = Common Name (eg, server FQDN or YOUR name) commonName_max = 64 [ v3_req ] keyUsage = critical, digitalSignature extendedKeyUsage = critical, codeSigning subjectKeyIdentifier = hash

We save the codeSign.cnf and create our csr, a certificate signing request file. To do this we open Terminal and run the following command:

hostname:~ user $ openssl req -new -config /path/to/codeSign.cnf -keyout /path/to/codeSignPrivate.key -out /path/to/codeSignRequest.csr

We will be prompted for a passcode when generating the private key. Do not forget this passcode, as we will be needing it again later. Atfer that we are prompted for some standard certificate information. When finished and if curious we can verify the csr file and have a peek at what we are requesting.

hostname:~ user $ openssl req -text -noout -verify -in /path/to/codeSignRequest.csr

In the middle of the output we find something called "X509v3 Extended Key Usage", i.e what is the purpose of our certificate, and as it says below, it is Code Signing.

In Terminal use the cat command to read the csr file. We will copy the output of the cat command and paste it into the PKI section in our Jamf Pro server.

hostname:~ user $ cat /path/to/codeSignRequest.csr

The output will look something like this:

-----BEGIN CERTIFICATE REQUEST----- MIIE8TCCAtkCAQAwVDELMAkGA1UEBhsdkfMCU0UxCzAJBgNVBAgMAlNFMRIwEAYDVQQH gOgGeLigoGGeliBorkABorkAborK7FlaFLHGHJGgjhGJHGHgghljLJGHu20aC1u29C+HVfpnejTzD -----END CERTIFICATE REQUEST-----

It is extremely important that we get everything, including all of the Begin and End lines, when we copy the content of our csr file.

Now we go to the PKI section in Global Management and open Management Certificate Template. Click on the "Create certificate from CSR" and paste what we previously copied into the small box. Choose SSO Certificate from the pop-up menu and click Create. A certificate file should be automatically downloaded. The name would be something like CN=codeSign...pem or whatever we used for commonName in the csr.

Now we are going to combine both our certificate files and the private key to create the code signing certificate. So we need the newly downloaded certificate file, CN=something,something.pem, the CA certificate file from Jamf Pro and the private key file created previously. We will also need the passcode, just sayin'.

To combine these files into something useful we need to do the following:

hostname:~ user $ openssl pkcs12 -export -out codeSign.p12 -inkey codeSignPrivate.key -in ourCertificate.pem -certfile ourJamfProCA.pem

We will first be prompted for the passcode of the private.key, told you so..., then we again need to set a passcode to be able to generate our p12 identity certificate. And again, do not forget this passcode, as we will need it again in a couple of minutes.

When done we should now have a yet another certificate file together with the rest. This is the Code Signing certificate we all been waiting for. Double click the certificate to install in Keychain Access. Again we are prompted for a passcode, this time the passcode which we created when the p12 certificate was generated.

If all went well we should now have a code signing certificate signed by our Jamf Pro server, and as such inherently trusted by all enrolled devices, located in our certificate store, ready for use.

Good luck

//Patrik

[mgshepherd]

@Jerneheim , this gave me some great insight and allowed me to understand signing better. I was finally able to sign a mobileconfig file and upload it to my JSS. Thank you thank you

[Jerneheim]

Happy to help.

//Patrik

[pavanraju]

Works like a charm! Thank you sir @Jerneheim

[pavanraju]

Using the code signing cert created from above, now you can use the security command to sign any unsigned config profile :

/usr/bin/security cms -S -N "<common name of signing certificate>" -i <input path to unsigned profile> -o <output path for signed profile>