Unable to Decrypt Profile? ADCS Connector

Assuming your device is domain bound, which is required for issuing ADCS certs to Macs. Is the machine certificate being deployed by a Certificate Configuration profile and in you keychain?

@miyonfaga - happy to help on this one, I've recently also had issues with ADCS Connector not working, and that was an error I got during the troubleshooting.

I do now have this working, so if this is still an issue for you, happy to help further.

Worth looking at the inetpub logs on the ADCS connector server - do you have an response code?

Logs are at C:\\inetpub\\logs\\LogFiles\\W3SVC2

This article was quite useful, but only got me so far:

https://travellingtechguy.blog/jamf-adcs-connector/

@statusBrew I'm getting 403 in the IIS logs at that path - any ideas? Everything is setup per that blog.. 

403 is a slightly different error that I was getting.

I got 401, meaning unauthorised, but 403 means forbidden, suggesting there might be a connection issue between JamfCloud and your ADCS connector.

https://travellingtechguy.blog/troubleshooting-with-postman-testing-the-jamf-adcs-connector-client-certificate/

The link above might be helpful, as it does specifically mention 403 errors and how to further diagnose what it is.

QQ - is your ADCS connector sat behind a LB of some kind?

It could be that if it is, the LB is intercepting the conneciton and breaking the MTLS auth - the traffic needs to be allowed through without any inspection or altering of the connection in anyway, else the MTLS breaks. (As per my understanding, I'm not a network engineer so very basic understanding!)

Weird.. ok, i'll check that - No, its just a single server, no LB involved at all.

Following this thread as I had a functioning ADCS that has now started to show an Unable to Decrypt Profile error when deploying profiles with 403s in the log.

We think that Jamf Cloud cannot talk to the ADCS connector any more is there a good way to confirm this?

Do you see 403 errors in the logs on your ADCS server?
If you do, then it could suggest that Jamf Cloud can connect to the ADCS Connector server, else how would it know to attempt to retrieve a cert, and then get an error back?

My previous link above is a good troubleshooting page from TTG talking about various errors, including 403 errors. Did you have a go at any of those steps? Where did you get a failure/get stuck?

We are also having problems. We have asked our network team to setup a NAT rule in the firewall to allow the Jamf Pro IP addresses to be allowed on our ADCS server but still getting 'Unable to decrypt' error after they made the change.

C:\\inetpub\\logs\\LogFiles\\W3SVC2 gives the following:

2024-03-20 18:44:10 ::1 GET / - 443 - ::1 Mozilla/5.0+(Windows+NT+10.0;+WOW64;+Trident/7.0;+rv:11.0)+like+Gecko https://localhost/ 403 14 0 2574

Is the NAT rule set to inspect the traffic, or pass through with no interception?

Following this thread as well, we just started seeing this error too. 

Also seeing this error as of April 26

Just a point of clarification: you mean the ADCS server itself needs to be bound--not the Jamf-managed Mac endpoints, correct? Because isn't that the whole point of ADCS--to be able to deliver certs to unbound, but managed, devices?

Seeing something similar, did things get better for some of you?

If you are using Jamf Pro 11.9 and ADCS Connector, please read at https://learn.jamf.com/en-US/bundle/jamf-pro-release-notes-11.9.0/page/Important_Notices.html

" Integrations with Active Directory Certificate Services (AD CS) now require Jamf AD CS Connector 1.1.0.
Jamf AD CS Connector 1.1.0 requires .NET Framework 4.8 or later. "

Then take a look at https://www.rocketman.tech/post/update-your-jamf-ad-cs-connector and https://learn.jamf.com/en-US/bundle/technical-paper-integrating-ad-cs-current/page/Upgrading_the_Jamf_AD_CS_Connector.html on how to update.

Correct. Most environments that would use an ADCS Server would be binding the Windows server the ADCS Connector is running on.

The ADCS connector builds itself with a PowerShell script, one of the functions of that script makes a local admin account to do the things on the host server. Considering this is within a domain environment, there are likely controls to prevent this kind of behavior as it is very insecure. Jamf should really have a popup where you enter service account credentials, and it builds the connector around that account. The admin account is for things like accessing the certificate templates and the keystore as well as some directories on the device, and if the account does not have the correct permissions, you will receive all kinds of issues like you are seeing right now.

We had the rather niche 403 16 error due to some certs being erroneously placed in the root trust store. What's weird is that while at present I can request certs whilst on prem, or VPNed in, requests fail when hitting our layer 4 proxy, but curiously openssl when run against this proxy seems to receive a cert, but errors with line indicating some sort of layer 3 error.