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 list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
