iOS Question SecKeychainItemImport: Unknown format in import.

wl

Well-Known Member
Licensed User
Longtime User
Hi,

I needed to recreate my keys and have the same issue I had in August (see: https://www.b4x.com/android/forum/threads/seckeychainitemimport-unknown-format-in-import.133821/).
I have this both on my local builder *and* with a hosted builder account.

What I did (in a final attempt):
- reinstalled b4i 7.80 on my Windows environment (probably nothing to do with the issue, but just a next attempt)
- removed my apple certificate, provisioning profile, wildcard app id
- recreated a private key in b4i (using hosted builder)
- recreated certificate, wildcard app id and provision profile
- create an empty b4i application with package name matching the wildcard app id
- set the build server to the hosted builder account
- tried to build B4i-bridge app

as stated: I initially did the same steps but then using my local builder. After many hours/days of retrying I got it working in August and as far as I know nothing changed on my environment, except the recreating of all keys etc....

certificate: iOS Distribution (App Store and Ad Hoc)
app id: wildcard
profile: distribution / add hoc

B4X:
Sending data to remote compiler.    Error
Error: security: SecKeychainItemImport: Unknown format in import.
 

Attachments

  • Capture d’écran 2022-01-03 191200.png
    Capture d’écran 2022-01-03 191200.png
    14.8 KB · Views: 66

aeric

Expert
Licensed User
Longtime User
How is your wildcard app id looks like?
Have you tried using Development certificate?
 
Upvote 0

wl

Well-Known Member
Licensed User
Longtime User
Thanks aeric ... but unfortunately ...

the wildcard app id looks like "com.example.*" and the package name "com.example.myapp"
I just tried with an "ios development" certificate, with a "ios development" profile ...
Same results...

It seems the error message is also sporadically encountered in other environments (ionic) and is most probably to be located at the apple/server side, though something incorrect is probably sent from my dev environment ... Hopefully Erel can look at it from the server side now that I used the hosted builder platform ...
 
Last edited:
Upvote 0

wl

Well-Known Member
Licensed User
Longtime User
I noticed the following while removing the certificate, provision profile, app ID and recreating them all on Apple's website

I created a new certificate:
it says: expiration date = 2023/01/04 (in my timezone it is currently January, 4th)

When I create a provisioning profile and I select this certificate (my only certificate)
it says: ...(ios Distribution), Jan 03, 2023

So there seems to be a mismatch of a day ?
Could it be that on Apple's website the old (already removed) certificate was taken (some caching or batch processing issue) ?

Just some farfetched guessing ?

PS: sent the certificate & provisioning to Erel.
 

Attachments

  • provision.jpg
    provision.jpg
    31.7 KB · Views: 66
  • certificate.jpg
    certificate.jpg
    22 KB · Views: 72
Last edited:
Upvote 0

wl

Well-Known Member
Licensed User
Longtime User
When I start from from following files that Erel generated
  • B4i.keystore
  • B4i.p12
  • certSigningRequest.csr
(and then generate the distribution certificate and provisioning profile etc) I can build a bridge app (also locally)

If I remove these three files and generate them in my B4I environment I get the error and do the same steps I get the error.

I just create these field by asking b4i to generate a private sign key...

Therefore: is the Java JDK somewhere involved in generating these files and could the problem be related somehow to these files ?
Or could it have to do with local clock settings? I'm just guessing ...

I looked at the B4i.p12 I generated myself and the one generate by Erel with certutil -dump and I see nothing that really differs ...
 
Last edited:
Upvote 0

wl

Well-Known Member
Licensed User
Longtime User
Erel, yes indeed ... otherwise I get another error (which seems obvious)

If I take your files and create another certificate and provisioning profile then it works ...

I am running Jdk 8 (on Windows 11 arm)

Update: now that I know that JDK is involved somewhere I tried Open JDK 11: on exactly the same environment I did exactly the same steps but using Open JDK 11 instead of (Sun) JDK 8 and it seems to work !
 
Last edited:
Upvote 0
Top