- This topic has 21 replies, 6 voices, and was last updated 2 years, 11 months ago by
.
-
Posts
-
Hi All
I feel like I’m missing a command in my Advanced Line configuration in WMS Cloud console. Devices that were setup from two years ago are having the certificates age out and during SCEP enrollment, its not autorenewing. It will go through the SCEP enrollment process and at the end a message in the logs states certificate already on machine. I can manually go in and renew the certificate using SCEP and when I do so its asks me to confirm I want to overwrite the existing, once I do that its fine and authenticating again. I feel there should be an INI parameter to confirm the overwriting of existing certificate.
Here’s my advanced line config:
ScepAutoEnroll=Yes AutoReNew=Yes InstallCACert=Yes ScepAdminUrl=”xxxxxxxxxxxxxxxxxxxxxxxxxxxxx/certsrv/mscep_admin” ScepUser=XXXXXXX ScepUserDomain=XXXXXXX ScepUserPwd=*************
dummy=command CommonName=$SN KeyUsage=digitalSignature;keyEncipherment KeyLength=2048 RequestURL=”xxxxxxxxxxxxxxxxxxxxxxxxxxxx/certsrv/mscep/mscep.dll” CACertHash=’XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX’ EnrollPwd=********************************
IEEE8021X=yes network=wired eap=yes eaptype=EAP-TLS tlsclntcert=$SN.pfx tlsauthtype=machine
What should this be? “dummy=command”
Have you all these parameters in one line? This will not work due to length restrictions.
There has to be a ” \” at the end of the first paragraph (ScepUserPwd=************), if you are using more than one line.On the other hand: With WMS 1.4 you have all SCEP options directly integrated in the GUI (last but one section)
CG
Thanks for the reply ConfGen
Using WMS Advanced line config, back in WMS 1.2 there was no SCEP as part of the GUI so this had to be setup as an advanced line config. We worked tirelessly with Dell Engineering to get the SCEP configuration setup in the advanced line and it would not take all on one line, there was apparently at character limitation per line back then. So the INI parameters had to be broken up into multiple lines, but then it would not read the second line using the commonly known INI parameters so Dell engineering suggested adding the “dummy=command” to the front of our second line of the SCEP configuration and that got it working. That was also around two years ago and i haven’t converted the primary policy to use the GUI SCEP section of WMS Cloud because its been working fine.
Regardless, I’ve tested a device with a SCEP certificate that should renew at the half life of the certificate in a test policy that utilized the SCEP GUI section and it still will not refresh the certificate. In the event logs you will see the following
10:44:02.047 ScepClient: init …
10:44:03.961 ScepClient: already has a certificate.So it goes out and performs a SCEP enrollment, sees that there is already a certificate on the device, but it will not overwrite the existing certificate at its half life as the AutoReNew=Yes parameter should be telling it to do. If I manually renew it on the device it works, but it prompts with a message “Do you wish to overwrite existing certificate” and click OK, it renews. That leads me to believe there should be an INI parameter for the certificate overwrite, but there doesn’t seem to be.
Dell engineering is investigating, but I believe this to be a bug. I don’t know if its ever worked because from the time we started deploying devices I would have to wait a year to see if certificates refresh at their half-life or test with a manually created certificate that last 3-4 days and that’s not something I tried.
As a workaround, I can manually refresh them as they start to expire but it is a painful manual process:
• Open (disable 802.1x) individual network port (involves network team resources)
• Bounce network port
• VNC to impacted machine
• Request certificate manuallyI also found that I can use the Delete Certificate feature in WMS and the name of the certificate to delete does recognize as $SN.pfx, but once the certificate is gone and the device reboots to do a SCEP enrollment, the network port shuts down because the $SN.pfx is no longer able to do EAP-TLS machine level authentication, so the network ports need to be opened again regardless.
Its a real pain…
Thanks ConfGen
I tested removing the “dummy=command” and adding the „ \“ (Space+backslash) and no longer receive invalid parameter as I used to when we had „ \“ (Space+backslash) in our configuration 2 years ago, so you are correct in the fact that we do not need that command any longer.
ScepAutoEnroll=Yes AutoReNew=Yes InstallCACert=Yes ScepAdminUrl=”xxxxxxxxxx.xxxx.xxxxxxxxxx.net/certsrv/mscep_admin” ScepUser=xxxxxxx ScepUserDomain=xxxxxxx ScepUserPwd=************ \
CommonName=$SN KeyUsage=digitalSignature;keyEncipherment KeyLength=2048 RequestURL=”xxxxxxxxxx.xxxx.xxxxxxxxxx.net/certsrv/mscep/mscep.dll” CACertHash=’xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx’ EnrollPwd=********************************IEEE8021X=yes network=wired eap=yes eaptype=EAP-TLS tlsclntcert=$SN.pfx tlsauthtype=machine
Unfortunately, the certificate still will not update. The $SN.pfx certificate shows valid from 2018-02-15 to 2020-02-15 and we are beyond the half-life at 2019-10-10 today.
I really appreciate your help and suggestions. Does the CA server need to be set to something specific for this to overwrite the existing certificate or is it up to the Thin Client to see the expiration date and know this needs to be overwritten? You’ll have to forgive my lack of knowledge around the CA Certs, its managed by our security group and its not my forte.
EDIT: I’m also testing this on a 3040 ThinOS running 8.6_019 and 8.6_027, with High privilege level locally so it shouldn’t be a privilege level issue.
If you have tested this with the latest firmware then I guess it is a bug.
CG
This is now with Dell Engineering. No bug ticket submitted yet but they’re looking at it.
Engineering has been able to recreate the issue, and have found that the code has time query to determine if it’s time to renew the certificate and that code parameter is not working as expected.( Per WTOS engineer)
I would be interested to know, if this issue has been solved in the end.
We’re currently also looking into implementing SCEP in the near future.
I know it’s been over a year, but do you have confirmation from Dell WTOS that this was fixed in any later version of the Firmware?
I have over 200 devices that are now expiring their certs (which are used for Wireless access), and I’m having to bring them to network ports to manually delete and recreate the certs.
Thanks in advanced.
This was recently resolved by building and testing a new certificate server with a cert half life of four hours, had no problem auto renewing so we then bumped the expiration date to 2 years and I have a calendar reminder to check certain devices at the 1yr mark to make sure they renew.
Worked with Dell engineering and connecting to one of their test WMS environments they proved it wasn’t a WTOS issue with auto-renew.
We haven’t triaged the old server to see what the difference is with the new server but the new server works for enrolling Wyse Thin Clients and also Google Chromebooks (which couldn’t enroll at all on the old server) so it must have been an issue with how the server was initially configured some years ago. Wish I had a better answer for you, this took me months to figure out and work with security to test a new server while working from home.
Did anyone found fix on this?. I have WMS 1.4 and have tried SCEP auto renewal setup through GUI and INI parameters which are almost same as brian. Unfortunately, there is no luck.
Can someone guide me if we have anything to do with WMS config or SCEP server config.I have uploaded a guide on how to set up SCEP and configure everything (wnos.ini, WMS, ThinOS 8/9)
CG
Hmm, let me think about that a second. Maybe in the Downloads section? 😉
Go to Downloads – ThinOS and look for “Installation and Configuration of MS SCEP and ThinOS”CG
Followed the guide and have replicated all the settings as per the guide, still no luck..
Below are logs, it just verifies if the client has certificate, device doesn’t check if the certificate is already expired or not
14:33:49.052 ScepClient: init …
14:33:49.053 Audio: start system[root] audio…
14:33:50.994 ScepClient: already has a certificate.
- You must be logged in to reply to this topic.