Bug 38946 – WebKit Mac/Obj-C API needs way to determine SSL/TLS X.509 certificate used with document/resource

• Component: WebKit API
• Status: RESOLVED INVALID

There's no way that I can find in the public WebKit Mac Objective-C API (WebKit.framework) to determine which X.509 certificate is used on SSL/TLS sites. Being able to determine the certificate is important in determining the specific veracity of the certificate (differentiating between normal and "green" certificates) as well as showing the name of the associated organization; standard features in every current major browser.

There are two documented delegate methods in the WebResourceLoadDelegate (webView:resource:didReceiveAuthenticationChallenge:fromDataSource: and ..:didCancelAuthenticationChallenge:..), which sound relevant because of references like this Stack Overflow question, <http://stackoverflow.com/questions/1578121/https-with-nsurlconnection-nsurlerrorservercertificateuntrusted>, noting that the certificate is probably available through the challenge -> protection space -> server trust path. Alas, in my experiments, those delegate methods are not called until a resource actually needs username/password authentication.

(Inspired by the Stack Overflow question, I found a private resource load delegate method that appears to wrap NSURLConnection's delegate method for shouldUseCredentialStorageForDataSource, but implementing it does not supply a useful object nor cause the other relevant delegate methods to be called.)

What does real-world browsers built on the system version of WebKit.framework - i.e. Safari - do to acquire this information right now? class-dump and Google finds the CertificateUtilities class with the class method sslPolicyForHost:client:. I'd rather not use a private API, but if it's the case that a new, supported, public API is developed and Safari, distributed in millions of copies, currently uses a private API, one could solve the problem by looking for the new API, falling back to looking for the private API and using it if it's available, in the same manner that some undocumented Foundation, AppKit and UIKit methods have been blessed for public use on older Mac OS X/iPhone OS versions retroactively.

[Mark Rowe (bdash)]

The certificate is a function of the network layer.  That’s below WebKit.  You should file an enhancement request at <http://bugreport.apple.com/> asking for the API that you’d like to be exposed.  I’d guess that it would make sense for something to be exposed on NSHTTPURLResponse or a related class.

(In reply to comment #1)
> The certificate is a function of the network layer.  That’s below WebKit.  You should file an enhancement request at <http://bugreport.apple.com/> asking for the API that you’d like to be exposed.  I’d guess that it would make sense for something to be exposed on NSHTTPURLResponse or a related class.

When you say "below WebKit", do you mean the entire WebKit codebase itself or the WebKit.framework API layer? There definitely seems to be methods inside WebKit code that could be made public that would make the certificate information reachable without asking for adjustments in the NSURL*-related classes in Foundation.

[Alexey Proskuryakov]

I think that this is best to track in Radar, even if it's a valid WebKit API request.

(In reply to comment #3)
> I think that this is best to track in Radar, even if it's a valid WebKit API request.

Fair enough.