The SSL cert (DigiCert) assigned to my ICG is set to expire very soon. I have the updated cert added to the ICG keystore and all looks well. What’s strange is that when starting the update keystore procedure, the affected devices warning page is showing a little more than half of the remote devices as not having the necessary certificates. I deployed the updated cert a few weeks ago to try and get ahead of this, and I’m able to see the cert on the remote devices. When I compare devices that show as ready to switch between devices without the necessary certs, I’m not seeing anything of interest or concern. This makes me believe that the update keystore wizard might not be reporting correctly. I’m tempted to just “flip the switch”, but obviously if I do this and the wizard is correct, I’ll have a couple hundred devices to track down and remediate. Any thoughts?
I have a few, but let me ask first: which UMS / ICG / IGEL OS version?
UMS version = 6.07.100, ICG version = 2.03.100, IGEL OS = almost all of these devices are on 11.05.100
Can you SSH the device? If you go to /wfs
are the files identical between a device that reports wrong and one working?
/wfs/.icg.cfg
/wfs/icgcert.crt
/wfs/icg-checksums
Ok, so the good to go ones have an extra value in their .icg.cfg file (icg-server-list) that the “not good to go” do not have. In addition, the “not good to go” ones have an extra cert in the /wfs directory called “icgcert-new.crt”
Did you rebooted one of “not good to go”?
I have multiple times. But, I think I might know what’s up. Let me test something and I’ll update you
So, I have a profile that we use to “convert” internal IGEL OS devices to remote devices. The profile sets a structure tag and then runs a command to configure ICG. So far, all of the “no go” devices have this profile assigned, whereas, so far none of the “good to go” devices have the profile. I pulled the profile on 2 of the “no go” devices and had to reboot them twice; both are now in the “good to go list”
I’m going to obviously pull this profile from actual remote devices and the number should decrease significantly.
Question though is, would these devices still be able to connect when I update the ICG cert?
That will be the reason to 99%, which command are you using in that profile?
Since I’m never quite sure which phase to place a custom command into, I’m using the following as a final command — su -c “icg-config” -s <my ICG FQDN> -o <my ICG mass deployment key> -t <my structure tag>” for Base, Network, and Desktop
Remove it on one of your testdevices, reboot and you should be good to go.
This process is reconfiguring your ICG connection on every boot (and replaces the newer config you sent by Keystore update.
I tested and it is correcting the issue. I have a scheduled job in place to send UMS settings to the devices, and then later to reboot the devices in this particular view a couple of times. I should be able to remediate a large number before Sunday night. I do have an extra fall back for the devices, which is a shortcut on the start menu that calls a custom command to register with ICG. So for any devices that don’t make it before the cert update, I can at least have our service desk reach out and have the user try the shortcut method.
Continue reading and comment on the thread ‘After updating the ICG SSL certificate half the IGEL OS devices report not having the necessary certs’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?
Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.Submit a question, or Join Today!