ok! Good news, I applied the patches and I'm able to issue the request from a Mac and have it trigger a manual approval workflow.
Unfortunately, it seems that Apple devices won't wait for a response like SSCEP will. The result is that the client fails right after the workflow starts. I'm pasting the MacOS logs below. the final error, NSOSStatusErrorDomain:-67686> , seems to result from the connection terminating unexpectedly (unexpected because it didnt return a signed cert). This, of course, feels like a MacOS problem not an OpenXPKI issue, just documenting in case someone else finds this thread. I'm going to try to get and LDAP connector working for the challenge secret, if so, I have no problem auto-accepting the request. MacOS Logs: default 15:06:13.343128-0600 CertificateService [1366478549:Cert_PI:HTTPUtil:<0x76a5a5>] >>>>> Sending HTTP request (GET) [SCEP:GetCACaps] >>>>> default 15:06:14.822747-0600 CertificateService [1366478549:Cert_PI:HTTPUtil:<0x76a5a5>] <<<<< Received HTTP response (200) [SCEP:GetCACaps] <<<<< default 15:06:14.823383-0600 CertificateService GetCACaps bitmask: 0x7e <== <private> default 15:06:14.823502-0600 CertificateService Sending GetCACert request default 15:06:14.826046-0600 CertificateService [1366478549:Cert_PI:HTTPUtil:<0x76a5a5>] >>>>> Sending HTTP request (GET) [SCEP:GetCACert] >>>>> default 15:06:16.324302-0600 CertificateService [1366478549:Cert_PI:HTTPUtil:<0x76a5a5>] <<<<< Received HTTP response (200) [SCEP:GetCACert] <<<<< default 15:06:16.325014-0600 CertificateService ProcessGetCACertResponse: Content-Type: 'application/x-x509-ca-ra-cert' default 15:06:16.325107-0600 CertificateService ProcessGetCACertResponse: application/x-x509-ca-ra-cert; err = errSecCertificateCannotOperate default 15:06:16.325289-0600 CertificateService ProcessGetCACertResponse: CFArrayGetCount(returnedCerts) > 1 default 15:06:16.325366-0600 CertificateService SortAndSetCACertificates: (CFArrayGetCount(returnedCerts) = 3 default 15:06:16.325509-0600 CertificateService SortAndSetCACertificates: use heuristics to determine which is which, namely find the encryption and signature certificates default 15:06:16.325583-0600 CertificateService SortAndSetCACertificates: certs[0] default 15:06:16.333256-0600 CertificateService SortAndSetCACertificates: bits & kSecKeyUsageDigitalSignature; certs[0] default 15:06:16.333312-0600 CertificateService SortAndSetCACertificates: bits & kSecKeyUsageDataEncipherment; certs[0] default 15:06:16.333364-0600 CertificateService SortAndSetCACertificates: session->raCert != NULL && session->raEncCert != NULL (MS SCEP) default 15:06:21.088694-0600 CertificateService Converting SignedAttributes (CreateSCEPMessage) default 15:06:21.088953-0600 CertificateService CreateSignedAttrsForSecFW returned 4 attributes default 15:06:21.419747-0600 CertificateService SecCMSCreateSignedData returned message 2718 in length default 15:06:21.419867-0600 CertificateService Sending 'PKIOperation' request via POST default 15:06:21.424325-0600 CertificateService [1366478549:Cert_PI:HTTPUtil:<0x76a5a5>] >>>>> Sending HTTP request (POST) [SCEP:RequestCert] >>>>> error 15:06:27.893491-0600 com.apple.preferences.configurationprofiles.remoteservice [ERROR] Profile installation (scep test (andesite.6BF88F76-C55C-4560-BEEE-11E8DF8EA9F2:0B178EA8-E395-46B3-ADA1-0AC9B111BB5B)) ( <NSOSStatusErrorDomain:-67686>) On Mon, Jun 28, 2021 at 11:35 PM, 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
