[bugfix] remove SecCertificateRef that will cause tls handshake failed

[yacosdad]

Before deleting the 'cert' code, the package info of client for exchange had two certificates which were same with each other. The screenshot is below:


After deleting that, everything was OK!

The SecIdentityRef contains a SecCertificateRef, so we do not add another SecCertificateRef again!

Please fix it and release a new pod version, thanks!

[ckrey]

@yacosdad Thanks for spotting and fixing this

[yacosdad]

@yacosdad Thanks for spotting and fixing this

@ckrey Em...but why the CI executed failed？Does this PR will be merged as soon as possible？

[jcavar]

Don't worry about CI - that is just flakiness.
But should we return only cert instead of identityRef?

[yacosdad]

Don't worry about CI - that is just flakiness.
But should we return only cert instead of identityRef?

@jcavar No，we can not. The kCFStreamSSLCertificates Discussion shows that the SecIdentityRef must be first item in the array.

[jcavar]

Hmm, I am still not sure I understand.
Could you please share how you use certificates returned by this method?
Where do you set them?

[yacosdad]

Hmm, I am still not sure I understand.
Could you please share how you use certificates returned by this method?
Where do you set them?

• (NSArray *)clientCertsFromP12:(NSString *)path passphrase:(NSString *)passphrase
  I use this method to general client certificate and use the result to initialize mqttsessionmanager's certificaties parameter.

Finally, the certificates was used in "open" method of MQTTSSLSecurityPolicyTransport class. That was set into the key kCFStreamSSLCertificates of ssloptions to set kCFStreamPropertySSLSettings property of CFReadStreamRef/CFWriteStreamRef.

This is the demo:

[jcavar]

Ok, I see. But the docs state that it should be an array of SecCertificateRefs except first SecIdentityRef. With this change, we only leave SecIdentityRef?

Also, implementation of this other library does the same thing as we are doing now:
https://github.com/daltoniam/Starscream/blob/master/Sources/Starscream/SSLClientCertificate.swift

[yacosdad]

Ok, I see. But the docs state that it should be an array of SecCertificateRefs except first SecIdentityRef. With this change, we only leave SecIdentityRef?

Also, implementation of this other library does the same thing as we are doing now:
https://github.com/daltoniam/Starscream/blob/master/Sources/Starscream/SSLClientCertificate.swift

YES, my code works fine and the package screenshot in the issue topic shows that the communication process is right. You can grab the network package and take a test.

[jcavar]

I understand what you are saying, but I don't understand why that is the case. Documentation confirms what our current code is doing. (and other library is doing the same thing).

Maybe there is an issue somewhere else?