@valkyrie Is there a configuration in ADCS for the timeout delay before giving up on a certificate request? I was seeing the problem you describe when using the Jamf PKI Proxy for Venafi issued certificates with the default timeout, and increasing the timeout resolved the issue.

@sdagley How would one increase the timeout as you described? I do not see that anywhere in Jamf's documentation for Configuring the Jamf PKI Proxy and Venafi Connection.

Edit: Nevermind. I found the answer by poking around my own server. For anyone wondering, just run the following command replacing ## with the actual number of seconds you want your timeout to be:

AFAIK, we don't have a timeout delay configured. Would increasing the timeout do anything then?

@valkyrie You'd probably want to check with Jamf Support regarding  timeout setting adjustment in ADCS. If your profile has requested  certificate, and one isn't available from the ADCS within the timeout period, that could be why you'd get the failed to inject error message because there's nothing to inject.

@valkyrie You might need to verify that your systems are getting renamed before the push of the configuration profile. I discovered recently that the process does not like default Mac names with spaces in them, e.g. "MacBook Pro" or "So-and-So's Mac Mini", so I had to modify scope for the configuration profile to only include systems that have been renamed properly instead of just all systems since that generally pushes it out immediately after enrollment.

@sdagley Were you able to resolve your issue? We are running into the same issue on newly provisioned macs, wanted to see if you made any headway 

@icolombage I think you meant to tag @valkyrie , I'm not seeing any certificate injection issues in my environment after adjusting the timeout in the Jamf PKI Proxy settings.

@valkyrie Were you able to resolve your issue? We are running into the same issue on newly provisioned macs, wanted to see if you made any headway 

@icolombage We managed to get it working again last week. Our system admin team had changed something for our sys-account, but hadn't changed it on the server that runs our Jamf Connector, so the sys-account couldn't get through, and as such didn't get any certificates back to inject into the profile.

Thanks @valkyrie - we went through our creds and confirmed nothing changed on our end. Working through with Jamf support to identify why it doesn't work consistently 

Hey, have you fixed this issue? Would you mind to share how?

@rochama what we isolated it to was a timing issue. It seems that the certificate profile was trying to pull a cert before some other policies had run. Our team noticed clearing the pending profiles/policies and allowing it to re-apply resolved the issue. So now we are looking into calling the certificate policy later in our deployment. Not a real resolution to our issue, but it unblocks us to move forward. 

We fixed that but in my case it was a misconfiguration in the SCEP server side, a device certificate was required to make the handshake with NPS server then the cert from SCEP could be issued. There was some minus settings we had to change as well like the Common Name had to have $EMAIL instead of $USERNAME because the NPS server was expecting the user´s email to authenticate. But that´s it it was the SCEP server configuration in the end.

Has anyone seen this when using the Jamf AD CS Connector?  The jamf-pki-proxy command wouldn't be applicable for that, so i'm not sure if the timeout can be increased (or is even an option)

Hi @ChrisCox nice find! Where did you run this command. We are experiencing the same issues with failed to inject certificates into the profile. Any documentation would be be helpful. Thanks 

we are getting a similar issue using JAMF AD CS but so far have been unable to resolve it.

will probably contact JAMF support and see if they can help out.

Hi nexus0000,

We also have similar issues and i was wondering if you had help from JAMF Support and if so what was the solution?

Hi @nexus0000 and @nadsad .  I was able to get this working in my environment.  The issue for us was a conflict between Group Policy on the Windows Server and the local account that is created by deploy.ps1

deploy.ps1 creates the local "AdcsProxyAccessUser" account, adds it to IIS_IUSRS group, then in IIS adds it to Sites > AdcsProxy > Configuration Editor > system.webServer/security/authentication/iisClientCertificateMappingAuthentication/oneToOneMappings.

For us at least, local accounts are blocked from remotely logging in.  So we created a new domain service account to get around that.  I then added that account to IIS_IUSRS and gave it the "Allow log on locally" user rights assignment.  I went to the oneToOneMappings configuration and added in that user ID and password, replacing AdcsProxyAccessUser. Lastly, I set the domain in the oneToOneMappings to match our domain.  

All good after that, no more Failed to Inject error.

Hi Jason,

Thank you for your reply!

Basically we have gotten it to work but its not working that great. It doesn't matter if we run the locally created account AdcsProxyAccessUser or a domain service account (we are using a domain service account).

For some reason the configuration profile doesn't apply most of the times because it has issues getting the certificate but sometimes it works.

Basically what we do - we scope 2 test computers - nothing happens - descope one of the computers and adding it again after - we keep doing this and then suddenly the profiles applies and the certificates are installed and we can see on the Windows Server on the IIS logs that follow entries:
(I have x the IP adresse)

2022-04-20 10:35:32 x.x.x.x POST /api/v1/certificate/request - 443 SVC-ADCS x.x.x.x Java-SDK - 200 0 0 78
2022-04-20 10:35:32 x.x.x.x POST /api/v1/certificate/retrieve - 443 SVC-ADCS x.x.x.x Java-SDK - 200 0 0 31

Do you have any idea of why it's behaving like this?

Could it be firewall issues/routing issues? Cus my thoughts are there to be honest - something like it takes to long to respond sometimes and the config profile fails with the "Failed to inject.."

We are experiencing the same issue where it works about half the time, It looks like when Jamf Pro reaches our external firewall, the failed attempts are having SSL/TLS cert issues, and in these scenarios the connection fails. We are using a Sectigo/Comodo cert and I'm wondering if there is a Root cert trust issue on the Jamf side. 
Have you made any progress on the intermittent issues? 

Make sure there is no cached copy of an old/incorrect cert on the Parent or Child AWS node of your Jamf Pro instance. This would contribute to the inconsistent behavior (whenever the node with cached cert tries to service the request). This is a known Product Issue: PI103922, where a child node caches an older certificate. :) 

Seeing the same issue. Certificate install success is very sporadic. Sometimes it takes 30 seconds and sometimes it takes 3-4 days.

Actually we have gotten it to work every time now. The thing is that they made some configurations in the loadbalancer for us from our network team side.

"configure more advanced LB with SSL-offloading, which will inject X-Forwarded-For HTTP header."

But the documentation on this link is very helpful - i think it might help anyone having issues to figure out something :)

https://github.com/jamf/ol/tree/master/adcsc/doc - Jamf ADCSC Implementation notes.pdf 

Hi guys, I was scratching my head on this one and realized the machines were not being renamed by the deployment team. They were getting the default name which contains an illegal character and / or too long, therefore a failed to inject error.

"Tom Jones's Macbook Pro"

My issue turned out to be a firewall problem. Adjusting the firewall traffic resolved the issue. Even if the machine has a long name like "Brandon Wood's Macbook Pro", it still get the cert within seconds.