Profiles with User-based certificates - takes ages to obtain

Airwatch by VMware
#1

Hello All,

we are currently facing an issue with profiles for WiFi which contains User-based certificates. The Certification Authority is generating the User-based certificates, but for some reason just some are pushed to the device. Sometimes the profile with certificate is pushed within 5 minutes, sometimes never.

We really get out of ideas. The communication between Device Services > Cloud Connector > Certificate Authority looks fine. But afterwards there is no communication on the device. Even though the device is checking in on regular basis (tried on WiFi and LTE same behaviour).

We were told by AW support that the Device Services is requesting the certificate when the communication with the device is established. But to me this looks as it is not right as on CA we see about 100+ certificated issued, but AW have delivered about 10+. What is even worst this is tried by AW just once and then the device profile is set as pending install, but the command queue is empty. All the build in checks towards the authority runs with success.

Have anybody encountered something similar? Any idea what to check to sort this out? This issue is even during the enrolment of the device, all profiles without the user-based certificate are delivered to the device without issue and on time (10-30 seconds), but the ones with the user-based certificate are lottery. Sometimes yes, sometimes with delay, sometimes never.

Thanks in advance.

Profile cant installed (WiFi & Exchange) - AirWatch
#2

Hi @RagnarBlack ,

On iOS, all profiles (even with certificats) are only installed if there is an action from an user while the device is locked. Which is the unclock action. You can see that the user has unclocked or not by checking the command Queue (troubleshooting) on each device. You will see that the mdm is waiting from the device an unclock action from the user.

otherwise you can try to check:

  • how many certificats your PKI can deliver. We use CMS4Mobile which manage 2 simulataneous demands every nearly 5 secondes.
  • the value you set in the certificat. Somes caracters may not be well manage for your PKI due to certificat encoding (UTF-8, …)

You can try to improve profile publishing by setting a value to 150 maximum temporaly (Airwatch doesn’t recommande to set a higher value due to perfomance consumption)
–> Settings / Installation / Performance Tuning / Certificate profile Publish Frequency

#3

AirWatch batches profiles that contain a certificate payload (generated on demand, not uploaded into the profile) in groups of 50 for deployment every 5 minutes. This is normal behavior. We have the same thing going on for cert based auth for email.

#4

Hello,

thanks for answers. The thing is that after restart of SQL server and Device Services server it is working 5minutes for an certificate approx. But after some time afterwards it stops deliver the profiles.

Currently with AW support we have found that there is some table completely missing in our SQL database. Pretty weird stuff, but hard to tell if that is the cause. As the sometimes works, sometimes not situation is not really saying why this is happening.

@Dara yes we have amended that value for better frequency. But as I say no progress. It looks that the SQL gets clogged after some time.

Thanks all for suggestions.

#5

Good morning RagnarBlack

You don’t mention if the method used to connect the CA is SCEP or DCOM.
If you are using SCEP, there is a limit on the “dynamic request password slot” you can use contemporary.
On your SCEP frontend, the Microsoft default value is 5.
Every password has a predefined lifetime. If a password doesn’t expire, your CA cannot accept a new request to enroll a certificate

To solve:

  1. Run regedit.exe to edit the PasswordMax value.
  2. The PasswordMax value is located at: HKEY_LOCAL_
    MACHINE\Software\Microsoft\Cryptography\MSCEP (or NDES/SCEP) within the registry.
  3. Increase the PasswordMax value to a number greater than the default value of 5 .

We are using here a value of 1000, as we have to manage the massive renewal of SCEP certificate over >24.000 device

1 Like
#6

Thanks for answer,

we are using DCOM. Actually we had an “fix” recently.

They amended following config:

<C:\AirWatch\AirWatch 9.5\Websites\WanderingWiFi.AirWatch.DeviceServices\Web.config>

and changed the value for RemoveDummyCertificates from true to false

add key="RemoveDummyCertificates" value="false"

This solved the issue, but we are still waiting for some technical background, what does this switch do.

#7

Hi RagnarBlack,

I know it has been a long time since you experienced this issue. Do you remember what caused it? I am experiencing same issue and have shared your troubleshooting steps with VMware. By any chance, do you have the support ticket number that I can give to VMware for reference.

Thanks,
Manshu

#8

Hello,

yes I recall it. It is this folder, that holds the certs before they are delivered to the device.
I recommend to rename the folder to backup and create a new.

C:\Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SystemCertificates\Request\

This works for us, and I am doing it once a while.

Cheers

#9

@RagnarBlack THANKYOU!! I renamed the folder on 3 out of 5 DS and profiles are now installing immediately without any issues. I will rename the folder on remaining 2 DS.
I didn’t change the removedummycertitificate value to false. Do I need to ?
Is this a VMware’s issue or windows server issue. I will update my VMware ticket and probably open another with MS.

Thanks again. Cheers!

#10

You are welcome, happy to be able to help. Actually the value change havent fixed the issue. AW should delete these shadow data once a while. But for some reason it didnt.