- This topic has 39 replies, 9 voices, and was last updated 2 years, 4 months ago by
.
-
Posts
-
Good Day All
I cannot get SCEP enrollment to work in WTOS 9.0.4024. The policy passes from WMS public cloud to the device, but it never enrolls. If I go to manually request a cert and plug in the password and submit, the cursor bounces up to the Server Request URL line and then nothing happens.
I believe ConfGen confirmed this was an issue in WTOS 9.1 beta which I verified the same behavior for that as well and it seems this is the case with WTOS 9.0.4024.
@ConfGen is this working for you in 9.0.4024?Can you go to “Troubleshooting” and export logs?
Then open the exported zip file and go to \system_log_20201125_134140.zip\compat\linux\tmp\wlogd.
Open the *.log.gz file and search for “SCEP”. Maybe you get some insights into why it is failing.CG
I’m seeing the same behavior.
I looked at the logs, and I’m seeing the following:
[20201130 11:49:07.289] D/WebUIProc/WebUIModule (1/1) scep auto enroll check …
[20201130 11:49:07.306] D/WebUIProc/WebUIModule (1/1) scep auto enroll failed: scep admin url format error
[20201130 11:49:07.307] D/WebUIProc/WebUIModule (1/1) scep error: “scep auto enroll fialed”The SCEP Admin URL is the same that works on 8.x, and matches the format: server.domain.com/certsrv/mscep_admin
That was it. I tried http://, but I hadn’t tried the trailing slash. Thanks!!
Yeah looks to be similar to my case, I got SCEP working now. In WTOS 8.6 you actually didn’t need the Admin URL and it would enroll and auto-renew fine (after I fixed the auto-renew issue with our enrollment server).
I was essentially plugging in the same policy entries in WMS from WTOS8 to WTOS9 so I didn’t have the Admin URL. When I added the Admin URL with the proper format it worked.
@the0duke0 have you done an upgrade in place from WTOS8 to WTOS9 on an 802.1x enforced port? I’m assuming you have to open the port (disable 802.1x) because when the device reboots during the upgrade and ALL certificates are wiped out, it won’t be able to authenticate against the port with no cert until it can enroll again in WTOS9.Bubbling this back up, SCEP was working in 9.0.4024, and while it works when I upgrade from 8.6 to 9.1 using $SN.pfx, if I reset the device to factory default and put it back in the same policy using $SN.pfx for the certificate name, the certificate comes out as SN.pfx.crt and when you go to select the certificate for machine authentication the name is *scep_cert_SN.pfx.crt which makes it impossible to set the certificate name by policy for 802.1x authentication.
Anyone else seen this?
Creates another cert with the terminal name but in the same fashion TN.pfx.crt and for some reason the CommonName keeps coming in as *scep_cert_TN.pfx.crt
When selecting the cert for machine auth this is how it’s seen.
I also found going to 9.1 that I had to switch to .crt instead of .pfx.
But in the SCEP settings under Common Name we have: $TN.<FQDN>
We do not include any file type here.When referencing the cert in the Wireless policy, we use this as the Filename:
scep_cert_$TN.<FQDN>.crtThanks @the0duke0
Just seems like thats not working as intended because for the Common Name the informational tag at the end of the box says to specify your client certificate name including extension, so its always been $SN.pfx, now it seems to force .crt to the end of whatever extension you specify which seems broken.
Just to be clear, the Common Name in the resulting certificate is $TN.<FQDN>, but the file name that is saved on the device is scep_cert_$TN.<FQDN>.crt, I’m not sure that it is wrong, but it is certainly different than 8.6 🙂
@the0duke0 so this works and I appreciate the reply, however I would think this is not working as intended. In WMS policy where you are supposed to have the option of the Common Name of the certificate, WMS seems to be automatically creating it as .crt, you don’t get the option of defining it. I’m guessing this is a bug in WMS 3.1 559.
I am managing over 3500 devices, with 75% of the devices configured for internal corporate network use that need to do SCEP for 802.1x enforcement on Ethernet and Wi-Fi. I can’t upgrade these devices to 9.1 until this gets fixed.
Can I make it work, yes, but what happens with the Common Name issue gets fixed? To make it work i’m listing the Common Name in the policy as simply $SN and not defining the extension as I previously did $SN.pfx. If WMS 3.2 fixes this issue I need to change the policy again because $SN won’t get me anything without defining the extension.
I don’t know why SCEP has been such a pain point with Dell since moving to WTOS9.
@ConfGen do you know if there is a bug reported for this in WMS? I know you still have an inside track to Dell you’re always in the beta’s that I sometimes get invited to.Appreciate everyone’s feedback on this.
EDIT: I believe this to be a WMS issue and not WTOS, since I had SCEP working before and then it must have been something I didn’t notice immediately when Dell upgraded to WMS 3.1 on December 4 for public cloud. When I did an upgrade from 8.6 to 9.0.4024 I see the same issue where previously I didn’t so the scep_cert appending in the certificate name and adding .crt to every Common Name choice occurs on 9.0.4024 and 9.1 which tells me its coming from WMS.
- You must be logged in to reply to this topic.