I tested on iOS 15 and cannot get the device to accept the profile at all. It never even gets to the point of making a network call.
On Thu, Jul 01, 2021 at 8:40 AM, Michal Moravec < [email protected]> wrote: > For iOS reported a problem with accepting the GetCaCert message. > Apple reported it fixed in some beta version (iOS 15?) but I don't have a > device to install the beta on. > > MM > > On 1. 7. 2021, at 16:37, Nick Dawson <[email protected]> wrote: > > > (re-sending to the list…sent to wrong address by mistake ) > > Michal I'll check the various betas today and report back. > > What about on iPhones? Did you have any luck - seems like they require a > different profile? So far none of my iOS devices will even accept the > profile. > > > On Thu, Jul 01, 2021 at 12:40 AM, Michal Moravec <michal.moravec@ > logicworks.cz> wrote: > > Yes. Apple fixed it in macOS 12 BETA > I reported the problem via feedback back in May. They fixed it incredibly > fast (for Apple) > > Fix MIGHT be coming to macOS 11.5 but I haven't checked this beta yet. > > M > > On 30. 6. 2021, at 23:36, Nick Dawson <[email protected]> wrote: > > Michal - did you ever solve the 8 bit nonce issue? That's where I'm > currently stalled. > > > > On Tue, Jun 29, 2021 at 1:52 AM, Michal Moravec <michal.moravec@ > logicworks.cz> wrote: > > Few observations: > > Your mobileconfig file looks fine. Only thing to watch out for is > the CAFingerprint. In my experience it can be fingerprint of any > certificate macOS clients receives in GetCACert message. > When you get to stage macOS client is sending PKIOperation POST message > (CSR) to the SCEP server you are fine (CAFingerprint is correct). > > Here is mine: > > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple. > com/DTDs/PropertyList-1.0.dtd"> > <plist version="1.0"> > <dict> > <key>PayloadContent</key> > <array> > <dict> > <key>PayloadContent</key> > <dict> > <key>CAFingerprint</key> > <data> > QsjrzXwcnv1c+VxmjmfUWuxoH/Ul3yniHBb0EJQFT10= > </data> > <key>Challenge</key> > <string>SecretChallange</string> > <key>Key Type</key> > <string>RSA</string> > <key>Key Usage</key> > <integer>5</integer> > <key>Keysize</key> > <integer>2048</integer> > <key>Retries</key> > <integer>3</integer> > <key>RetryDelay</key> > <integer>10</integer> > <key>Subject</key> > <array> > <array> > <array> > <string>O</string> > <string>Foo</string> > </array> > </array> > <array> > <array> > <string>CN</string> > <string>Bar</string> > </array> > </array> > <array> > <array> > <string>UID</string> > <string>Foo</string> > </array> > </array> > <array> > <array> > <string>OU</string> > <string>Bar</string> > </array> > </array> > </array> > <key>SubjectAltName</key> > <dict> > <key>ntPrincipalName</key> > <string>michal.moravec</string> > <key>rfc822Name</key> > <string>[email protected]</string> > </dict> > <key>URL</key> > <string>http://url.company.tld/scep/testing</string> > </dict> > <key>PayloadDescription</key> > <string>Configures SCEP settings</string> > <key>PayloadDisplayName</key> > <string>SCEP</string> > <key>PayloadIdentifier</key> > <string>com.apple.security.scep.76F0EE2F-6B6F-4028-B600-37510809964C > <http://com.apple.security.scep.76f0ee2f-6b6f-4028-b600-37510809964c/> > </string> > <key>PayloadType</key> > <string>com.apple.security.scep</string> > <key>PayloadUUID</key> > <string>76F0EE2F-6B6F-4028-B600-37510809964C</string> > <key>PayloadVersion</key> > <integer>1</integer> > </dict> > </array> > <key>PayloadDisplayName</key> > <string>SCEPTest</string> > <key>PayloadIdentifier</key> > <string>MacBook-Air.343E039D-FFE1-4FDA-B046-BF6399DDA3DF</string> > <key>PayloadRemovalDisallowed</key> > <false/> > <key>PayloadType</key> > <string>Configuration</string> > <key>PayloadUUID</key> > <string>9FC15BA2-1317-410A-A5C6-1BEBF031BAC0</string> > <key>PayloadVersion</key> > <integer>1</integer> > </dict> > </plist> > > > > About the trusted signer issue. Default OpenXPKI enrollment workflow does > not work well with the self-signed CSR Apple SCEP clients are sending. > I made two changes (diff it against default version): > > head: > prefix: * enrollscepapple* > label: I18N_OPENXPKI_UI_WORKFLOW_TYPE_CERT_ENROLL_LABEL > > ... > > description: I18N_OPENXPKI_UI_WORKFLOW_TYPE_CERT_ENROLL_DESC > > # shortcut to inital if no signer cert is set > READY_TO_PROCESS: > autorun: 1 > action: > - set_mode_initial > START_INITIAL ? !global_is_signed_request > global_is_subject_valid > - * global_noop* > SIGNED_REQUEST ? global_is_signed_request > global_is_subject_valid > - global_set_error_invalid_subject > FAILURE ? > !global_is_subject_valid > > ... > > > SIGNED_REQUEST: > autorun: 1 > action: > - set_mode_initial > START_INITIAL ? is_self_signed > #- set_mode_onbehalf > START_ONBEHALF ? > !signer_key_matches_subject_key !signer_subject_matches_csr_subject > - set_mode_onbehalf > * START_INITIAL* ? > !signer_key_matches_subject_key !signer_subject_matches_csr_subject > - set_mode_renewal > START_RENEWAL ? > signer_subject_matches_csr_subject !signer_key_matches_subject_key > > > > I can't believe this, but apparently Apple requires the requested x.500 > subnect to begin with the country: > /C=US/O=DZsec/CN=andesite > having the org or just a CN was not enough. > > This is weird. I am no using the country field. > What would happe if you reorder the original fields backwards? > > S přátelským pozdravem, > [image: Logicworks] <https://logicworks.cz/> > Michal Moravec Apple system administrator > Logicworks, s.r.o. <https://logicworks.cz/> > Argentinská 1621/36, Praha 7 > <https://www.google.cz/maps/place/Etnetera+Logicworks,+s.r.o./@50.1078991,14.4517256,17z/data=!3m1!4b1!4m5!3m4!1s0x470b94b2b61cb52d:0x6c88178df7f3ff49!8m2!3d50.1078957!4d14.4539143> > www.logicworks.cz <https://logicworks.cz/> | 778745013 > > On 29. 6. 2021, at 7:35, Oliver Welter <[email protected]> wrote: > > Hi Nick, > > congrats! Well this is explained quickly - the authorized_signer rule only > works with certificates that have a "chain of trust" inside OpenXPKI which > is not the case with this self signed one. Have a look at this commit > https://github.com/openxpki/openxpki-config/commit/ > 802162e6d4ae719c0728ddc392be7f76de1d7815 - it was made for exactly this > problem and modifies the workflow so you can disable the onbehalf mode by > removing the authorized_signer node from the config. The request should > then go into "MANUAL APPROVAL". > > Oliver > > Am 29.06.21 um 03:30 schrieb Nick Dawson: > > At long last! I'm almost at the finish line… once I get this working (with > LDAP auth for the challenge, but that's next) I'll get started on some docs > for Apple devices and installing on FreeBSD with NGINX. > > Here's what I've done: > > 1. rolled my server back to before the updates - returned to a state > where SSCEP works > 2. changed my MDM profile to use /C=US/O=.... > > Now it mostly works… I'm having trouble with Sign on Behalf > > 2021/06/28 19:22:53 openxpki.application.INFO > <http://openxpki.application.info/> SCEP try to start new workflow for > 4CED648C98809DF64716E8D2296F00502418D699 > [pid=2943|sid=kjjA|sceptid=4CED648C98809DF64716E8D2296F00502418D699] > 2021/06/28 19:22:55 openxpki.application.INFO > <http://openxpki.application.info/> Rendering subject: > CN=andesite,DC=DZsec,DC=net > [pid=2943|sid=kjjA|wftype=certificate_enroll|wfid=26111|sceptid=4CED648C98809DF64716E8D2296F00502418D699] > 2021/06/28 19:22:56 openxpki.application.INFO > <http://openxpki.application.info/> Trusted Signer chain - certificate is > self signed > [pid=2943|sid=kjjA|wftype=certificate_enroll|wfid=26111|sceptid=4CED648C98809DF64716E8D2296F00502418D699] > 2021/06/28 19:22:56 openxpki.application.INFO > <http://openxpki.application.info/> Trusted Signer not found in trust > list (C=US,CN=MDM SCEP SIGNER 504B8F03-2278-4815-A203-9ABA6EDA31D1). > [pid=2943|sid=kjjA|wftype=certificate_enroll|wfid=26111|sceptid=4CED648C98809DF64716E8D2296F00502418D699] > 2021/06/28 19:22:57 openxpki.application.INFO > <http://openxpki.application.info/> SCEP started new workflow with id > 26111, state FAILURE > [pid=2943|sid=kjjA|sceptid=4CED648C98809DF64716E8D2296F00502418D699] > 2021/06/28 19:22:57 openxpki.application.ERROR SCEP Request failed without > error code set - default to badRequest > [pid=2943|sid=kjjA|sceptid=4CED648C98809DF64716E8D2296F00502418D699] > > my generic.yaml now includes (you can see I've tried a few version… > clearly I'm not a pearl regex expert): > > authorized_signer: > rule1: > #subject: C=US,CN=MDM.* > #subject: C*.US*.CN*.MDM* > subject: C=.*,.* > > > > > > On Mon, Jun 28, 2021 at 3:52 PM, Nick Dawson <[email protected]> > wrote: > > I got it!!! > Well, sort of. > > I can't believe this, but apparently Apple requires the requested x.500 > subnect to begin with the country: > /C=US/O=DZsec/CN=andesite > having the org or just a CN was not enough. > > That small change fixed it. Except something else is no broken. Using > SSCEP or an MDM profile, I get this error in catchall.log: > > openxpki.system.ERROR Error while executing API command; __caller__ => / > usr/local/lib/perl5/site_perl/OpenXPKI/Service/LibSCEP/Command/ > PKIOperation.pm:495, __command__ => create_workflow_instance, __error__ > => Can't call method "debug" on an undefined value at /usr/local/lib/ > perl5/site_perl/Workflow/Action.pm line 120. > > [pid=70324|sid=6tYO|wftype=certificate_enroll|wfid=27391|sceptid=37BA270B8A3E734A7409F7BB3DFF94E1] > 2021/06/28 15:22:27 openxpki.system.ERROR Error executing SCEP command > 'PKIOperation': Error while executing API command; __caller__ => /usr/ > local/lib/perl5/site_perl/OpenXPKI/Service/LibSCEP/Command/PKIOperation. > pm:495, __command__ => create_workflow_instance, __error__ => Can't call > method "debug" on an undefined value at /usr/local/lib/perl5/site_perl/ > Workflow/Action.pm line 120. > > [pid=70324|sid=6tYO|wftype=certificate_enroll|wfid=27391|sceptid=37BA270B8A3E734A7409F7BB3DFF94E1] > > my scep config > cat /usr/local/etc/openxpki/config.d/realm/dzsec/scep/generic.yaml > > > renewal_period: 000060 > > revoke_on_replace: > reason_code: keyCompromise > delay_revocation_time: +000014 > > > workflow: > type: certificate_enroll > param: > # key: name in workflow context, value: parameter from scep wrapper > # server and interface are always set, the mapping below is > # the default set that is used when no map is given > transaction_id: transaction_id > signer_cert: signer_cert > pkcs10: pkcs10 > _url_params: url_params > #_pkcs7: pkcs7 > > authorized_signer: > rule1: > Full DN > subject: CN=.+:pkiclient,.* > subject: .*,CN=US > #rule2: > # Full DN > subject: CN=my.scep.enroller.com > <http://cn=my.scep.enroller.com/>:generic,.* > > policy: > > allow_man_authen: 1 > > allow_anon_enroll: 0 > > allow_man_approv: 1 > > approval_points: 0 > > max_active_certs: 1 > > auto_revoke_existing_certs: 1 > > allow_replace: 1 > > response: > getca: > ra: fullchain > issuer: fullchain > > > profile: > cert_profile: tls_server > cert_subject_style: enroll > > profile_map: > pc-client: tls_client > > hmac: verysecret > > challenge: > value: LongRandomPassword > > eligible: > initial: > value@: connector:scep.generic.connector.initial > args: '[% context.cert_subject_parts.CN.0 > <http://context.cert_subject_parts.cn.0/> %]' > expect: > - Build > - New > > renewal: > value: 1 > > onbehalf: > value: 1 > > > connector: > initial: > LOCATION: /home/pkiadm/cmdb.yaml > > > > On Mon, Jun 28, 2021 at 2:13 PM, Oliver Welter <[email protected]> wrote: > > Am 28.06.21 um 19:30 schrieb Nick Dawson: > > "We're not in windows" :) :) :) > > should be "on windows" I guess, but my fingers tend to be to large > sometimes ;) > > I thought I'd found a breakthrough hint > here: https://support.apple.com/en-us/HT210176 > <https://support.apple.com/en-us/HT210176> > So I made yet another new scep cert/key with the DNS names in the SAN > field. Still no luck. > > This is related to TLS certificates and should not be relevant to SCEP > (which is plain HTTP on the transport layer) > > I'm starting to think, unless anyone has demonstrated otherwise, that the > way apple handles SCEP is just not compatible. > > One other curiosity: > Apple requires an SHA1 or MD5 fingerprint of the SCEP cert. Makes sense. > I've been using sscep getca to see what openxpi is sending and I have been > using the MD5 fingerprint from the SCEP cert from that output. Any reason > that would be an incorrect process? I've also used > > Either I don't understand the purpose or you got that wrong, an SCEP > message includes several digests/encryption steps (also in the reply) which > is something you can configure but I never heard of the need to add the > value of a fingerprint soemwhere. > > here's the request, as decoded from the scep.log file (not sure how to > change log level to debug) > > /etc/openxpki/scep/log.conf (restart apache after changing it) > > cat request.txt | perl -pe 'use > MIME::Base64;s/%([0-9a-f]{2})/sprintf("%s",pack("H2",$1))/eig;$_=MIME::Base64::decode($_);' > > | openssl pkcs7 -inform DER -print_certs -text > > Print certs just gives you the signer cert which we already saw earlier, > the CSR is in the payload of this message here > > 238:d=3 hl=4 l= 271 prim: BIT STRING > > The value in this section is the CSR wrapped in a PKCS7 container > encrypted with the SCEP RA key (at least it should be and I think this is > the problem). You should be able to extract the payload this with > "openssl cms" and pipe it to asn1parse > > openssl cms -inform PEM -in scep.p7 -verify -noverify | openssl > asn1parse -inform der -i > Verification successful > 0:d=0 hl=4 l=1343 cons: SEQUENCE > 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData > 15:d=1 hl=4 l=1328 cons: cont [ 0 ] > 19:d=2 hl=4 l=1324 cons: SEQUENCE > 23:d=3 hl=2 l= 1 prim: INTEGER :00 > 26:d=3 hl=4 l= 647 cons: SET > 30:d=4 hl=4 l= 643 cons: SEQUENCE > 34:d=5 hl=2 l= 1 prim: INTEGER :00 > 37:d=5 hl=2 l= 107 cons: SEQUENCE > 39:d=6 hl=2 l= 83 cons: SEQUENCE > 41:d=7 hl=2 l= 11 cons: SET > 43:d=8 hl=2 l= 9 cons: SEQUENCE > 45:d=9 hl=2 l= 3 prim: OBJECT :countryName > 50:d=9 hl=2 l= 2 prim: PRINTABLESTRING :DE > 54:d=7 hl=2 l= 17 cons: SET > 56:d=8 hl=2 l= 15 cons: SEQUENCE > 58:d=9 hl=2 l= 3 prim: OBJECT :organizationName > 63:d=9 hl=2 l= 8 prim: UTF8STRING :OpenXPKI > 73:d=7 hl=2 l= 12 cons: SET > 75:d=8 hl=2 l= 10 cons: SEQUENCE > 77:d=9 hl=2 l= 3 prim: OBJECT > :organizationalUnitName > 82:d=9 hl=2 l= 3 prim: UTF8STRING :PKI > 87:d=7 hl=2 l= 35 cons: SET > 89:d=8 hl=2 l= 33 cons: SEQUENCE > 91:d=9 hl=2 l= 3 prim: OBJECT :commonName > 96:d=9 hl=2 l= 26 prim: UTF8STRING :OpenXPKI Demo > Issuing CA 1 > 124:d=6 hl=2 l= 20 prim: INTEGER > :5243CE43D4216F8CAFD5A7F73809259AA84CBD2C > 146:d=5 hl=2 l= 13 cons: SEQUENCE > 148:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption > 159:d=6 hl=2 l= 0 prim: NULL > 161:d=5 hl=4 l= 512 prim: OCTET STRING [HEX > DUMP]:0B1....71F83 > 677:d=3 hl=4 l= 666 cons: SEQUENCE > 681:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data > 692:d=4 hl=2 l= 17 cons: SEQUENCE > 694:d=5 hl=2 l= 5 prim: OBJECT :des-cbc > 701:d=5 hl=2 l= 8 prim: OCTET STRING [HEX > DUMP]:803B9371AD89BDFC > 711:d=4 hl=4 l= 632 prim: cont [ 0 ] > > The upper part denotes the IssuerSerial of the used encryption certificate > with the value at pos 124 being the serial number of the encryption > certificate, the lower part is the symetric key material and the encrypted > payload. > > Oliver > > -- > Protect your environment - close windows and adopt a penguin! > > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users > > > > > _______________________________________________ > OpenXPKI-users mailing > [email protected]https://lists.sourceforge.net/lists/listinfo/openxpki-users > > > -- > Protect your environment - close windows and adopt a penguin! > > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users > > > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users > > > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users > > > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users > > > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users > > > _______________________________________________ > OpenXPKI-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openxpki-users >
_______________________________________________ OpenXPKI-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
