WTOS 9.0.4024 and SCEP Enrollment

Tagged: ,

Viewing 15 posts - 1 through 15 (of 22 total)
  • Author
    Posts
  • #53602
    Avatarbrian1020
    Participant
    • Total Post: 186
    • Jacked into The Matrix
    • ★★★★★★

    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?

    #53620
    ConfGenConfGen
    Keymaster
    • Total Post: 11270
    • Jedi Master
    • ★★★★★★★

    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

    #53651
    Avatarthe0duke0
    Participant
    • Total Post: 5
    • Newbie

    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

     

     

    #53652
    ConfGenConfGen
    Keymaster
    • Total Post: 11270
    • Jedi Master
    • ★★★★★★★

    Add http:// in front and a „/„ at the end.

    CG

    #53654
    Avatarthe0duke0
    Participant
    • Total Post: 5
    • Newbie

    That was it. I tried http://, but I hadn’t tried the trailing slash. Thanks!!

    #53657
    Avatarbrian1020
    Participant
    • Total Post: 186
    • Jacked into The Matrix
    • ★★★★★★

    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.

     

    #72702
    Avatarbrian1020
    Participant
    • Total Post: 186
    • Jacked into The Matrix
    • ★★★★★★

    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?

    #72725
    ConfGenConfGen
    Keymaster
    • Total Post: 11270
    • Jedi Master
    • ★★★★★★★

    Try $TN instead.

    CG

    #72726
    Avatarbrian1020
    Participant
    • Total Post: 186
    • Jacked into The Matrix
    • ★★★★★★

    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

    #72727
    Avatarbrian1020
    Participant
    • Total Post: 186
    • Jacked into The Matrix
    • ★★★★★★

    When selecting the cert for machine auth this is how it’s seen.

    #72794
    Avatarthe0duke0
    Participant
    • Total Post: 5
    • Newbie

    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>.crt

     

    #72795
    Avatarbrian1020
    Participant
    • Total Post: 186
    • Jacked into The Matrix
    • ★★★★★★

    Thanks @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.

    • This reply was modified 2 months, 4 weeks ago by Avatarbrian1020.
    #72796
    Avatarthe0duke0
    Participant
    • Total Post: 5
    • Newbie

    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 🙂

    #77106
    Avatarbrian1020
    Participant
    • Total Post: 186
    • Jacked into The Matrix
    • ★★★★★★

    @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.

    • This reply was modified 2 months, 3 weeks ago by Avatarbrian1020.
    #77551
    ConfGenConfGen
    Keymaster
    • Total Post: 11270
    • Jedi Master
    • ★★★★★★★

    Brian1020, the best would be to open a ticket with Dell support. They can escalate this to engineering to get it sorted out.
    I cannot open these tickets internally.

    CG

Viewing 15 posts - 1 through 15 (of 22 total)
  • You must be logged in to reply to this topic.