3.0.0 making PFX user certificates OS X doesn’t like

Home Page Forums Network Management ZeroShell 3.0.0 making PFX user certificates OS X doesn’t like

This topic contains 3 replies, has 0 voices, and was last updated by  cdpearce 4 years, 9 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #43860

    cdpearce
    Participant

    I recently upgraded to 3.0.0 from 2.0.RC3
    Since the upgrade, when I create a new user and export a PFX certificate it does not create a certificate that imports properly into OS X Mavericks. It does not appear to properly include the CA Certificate data in a way that OS X understands. It ends up as a key that cannot be matched back to the CA cert even though the CA cert was previously imported as well. Users created before the upgrade still export/import ok.

    Using openssltool to analyze the certificates for 2 users, first one created before the upgrade and second from after (but both exported after upgrade):

    openssl pkcs12 -in BEFORE.pfx -cacerts
    Enter Import Password:
    MAC verified OK
    Bag Attributes:
    subject=/C=US/ST=California/L=Palo Alto/O=midpenmedia.org/OU=IT/CN=Media Center Local CA/emailAddress=it_admin@midpenmedia.org
    issuer=/C=US/ST=California/L=Palo Alto/O=midpenmedia.org/OU=IT/CN=Media Center Local CA/emailAddress=it_admin@midpenmedia.org


    BEGIN CERTIFICATE


    .
    .

    .
    .


    END CERTIFICATE


    Bag Attributes
    localKeyID: C4 FC DA CD 26 FF 68 1D BF FE 34 C7 26 5A 8A 08 45 EF 76 3F
    Key Attributes:

    … and then the certificate created after the upgrade:

    openssl pkcs12 -info -in AFTER.pfx -cacerts
    Enter Import Password:
    MAC Iteration 2048
    MAC verified OK
    PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
    Certificate bag
    Certificate bag
    Bag Attributes:
    subject=/C=US/ST=California/L=Palo Alto/O=midpenmedia.org/OU=IT/CN=Media Center Local CA/emailAddress=it_admin@midpenmedia.org
    issuer=/C=US/ST=California/L=Palo Alto/O=midpenmedia.org/OU=IT/CN=Media Center Local CA/emailAddress=it_admin@midpenmedia.org


    BEGIN CERTIFICATE


    .
    .

    .
    .


    END CERTIFICATE


    PKCS7 Data
    Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
    Bag Attributes
    localKeyID: 04 3C E4 EA 1C 9B 77 0A 6F 27 02 F8 DB AC 1F E2 98 23 95 4F
    Key Attributes:

    Note that the omitted certificate data matches in both cases.
    The “AFTER” certificate contains some extra lines in the output:
    PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
    Certificate bag
    Certificate bag

    and later…
    PKCS7 Data
    Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048

    I don’t know enough about X.509 certificates and PFX files to interpret this. But, perhaps OS X doesn’t understand a “Shrouded Keybag”? (whatever that is)

    #53192

    cdpearce
    Participant

    So I may have misled with the extra info in my previous post. I found I can export a PEM file representation of the BEFORE user certificate and then use the command:

    openssl pkcs12 -export -in BEFORE.pem -out BEFORE.pfx

    and create a .pfx file that displays the same structure as the AFTER.pfx file I used above. But, the file will import and work correctly.

    The bottom line remains. I cannot use ZeroShell to export a certificate file for a user that was created since updating to 3.0.0 that will work in OS X. The certificate imports fine into the login keychain. But, it cannot be used to authenticate via EAP-TLS to get onto my WPA2 Enterprise Wi-Fi network. Certificates for users created before the upgrade work fine.

    #53193

    cdpearce
    Participant

    This may all be a false alarm. I have now managed to create a couple of users where the X.509 certificates/keys were processed correctly by OS X.

    However, there is definitely some kind of problem. It may not be unique to this version of ZS. But, I did create 2 users for which the PFX certificate/key was not handled correctly by OS X. The failure mode was 100% repeatable for those users even after revoking the certificates and recreating them. The failures were 100% repeatable on a second Mac computer. I could not find anything wrong with the certificates/keys when analyzing them with openssl. If I exported them as a PEM file and then used openssl to translate them to PFX, they still failed the same way. I could not discern a difference between a “good” certificate and a “bad” certificate by comparing them. Obviously the data values were different but the structures appeared consistent.

    I even completely deleted the user and recreated it. The certificate/key still didn’t work. Perhaps there is something special about a username of “sib-laptop-mac” that doesn’t work, whereas “staff-laptop-mac” does.

    I have no idea what is going on and can’t troubleshoot further. But, as long as these bad users are rare perhaps it doesn’t matter.

    #53194

    imported_fulvio
    Participant

    Do you have enabled the field [Protected by password]?
    The password which has to be used to import the certificate and the private key is that user password.
    Regards
    Fulvio

    #53195

    cdpearce
    Participant

    Yes, I did have the “Protected by password” box checked. I wouldn’t have been able to get any of the certificates to work without it.

    This really should be a “host” certificate, since it authenticates a laptop computer, not the user of the laptop. But, it is not possible to check the password box for a “host” certificate, so I had to create a ZS “user” to represent the laptop instead.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.