User Profile

Posts

Posts

Post not yet marked as solved
2 Replies
1.9k Views

During debug output (po) of an iOS app Swift/ObjC, bridging headers cannot be found (Version 13.2.1 (13C100)

The bridging header works fine for compilation, and with previous version of xcode there were no problems running and debugging the app. But after switching to 13.2.1, poing a variable leads first to error: expression failed to parse, unknown error, and then to an error hinting at not being able to find header files. Example: (lldb) po recipientType error: expression failed to parse, unknown error (lldb) po recipientType warning: Swift error in scratch context: error: /Users/dirk/projects/pEp/src_iOS/pep4ios/pEpForiOS/pEpForiOS-Bridging-Header.h:14:9: error: 'AccountSettings.h' file not found #import "AccountSettings.h"         ^ error: failed to import bridging header '/Users/dirk/projects/pEp/src_iOS/pep4ios/pEpForiOS/pEpForiOS-Bridging-Header.h' . Shared Swift state for pEp has developed fatal errors and is being discarded. REPL definitions and persistent names/types will be lost. error: expression failed to parse, unknown error I have experimented with using <> for the import, instead of "", and also setting the framework header path, but no luck so far.
Posted
by DSec.
Last updated
.
Post not yet marked as solved
0 Replies
397 Views

UTI type for .p12, .pfx

For being able to pick client certificates, I thought I can simply create my own UTI for certain extensions and feed that to UIDocumentPickerViewController(documentTypes:) to change the way it displays files. This works for fantasy extensions and .cert, for example, but not .p12 or .pfx. Which may be because these are already used in other UTIs. But this list of UTIs - https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/UTIRef/Articles/System-DeclaredUniformTypeIdentifiers.html doesn't contain them. Is there an existing UTI for certificates that I could use?
Posted
by DSec.
Last updated
.
Post marked as solved
5 Replies
720 Views

TCP with self-signed server certificate

What are the options doing TCP and supporting self-signed server certificates? It's about IMAP/SMTP connections. We are currently using NSStream. Is there a higher-level API that automatically supports certificates that have been imported and trusted by the user (as hinted at here - https://support.apple.com/en-us/HT204477)? If not, is connecting with kCFStreamSSLValidatesCertificateChain disabled, and then querying kCFStreamPropertySSLPeerTrust, involving the user in self-made "trust UI" the way to go? Sample error: 2021-01-21 14:03:13.673788+0100 pEp[77676:8086560] CFNetwork SSLHandshake failed (-9807) 2021-01-21 14:03:13.673968+0100 pEp[77676:8086560] TCP Conn 0x6000033b89a0 SSLHandshake failed (-9807)
Posted
by DSec.
Last updated
.
Post marked as solved
1 Replies
1.6k Views

Expiry Date and other meta data of SecIdentity and attached certificates parsed through SecPKCS12Import on iOS

TLDR; Is there a way (on iOS 11 upwards) to get the expiry date of a SecIdentity's certificate imported with SecPKCS12Import?In order to support client certificates for NSStream based TLS TCP connections in an iOS app we're importing the certificates with SecPKCS12Import, extracting the common name and related emails of the certificate for displaying information to the user, generating our own UUID to re-identify this identity later and store it in the keychain. The UUID is packed into the label, which does not help in directly looking the identity up later, but together with equality on SecIdentity helps to identitfy already imported certificates and link them to our own DB.Now a typical use case for a client certificate is to let it expire every now and then, send out new ones to the users and let them handle the update. Knowing the expiry date of identities (which really means the expiry dates of their related certificates) is needed in this case, otherwise I don't see any other data that could let the user easily differentiate between the old, no longer valid identity and the new one.
Posted
by DSec.
Last updated
.