Why is my server's wildcard SSL certificate be

问题:

I am using an NSURLConnection to connect to a server with a wildcard TLS certificate (like "*.domain.com"), and when I call SecTrustEvaluate in my NSURLConnectionDelegate's -connection:willSendRequestForAuthenticationChallenge: method, the certificate is rejected as invalid. Another server that has a fully-specified TLS certificate (like "server2.domain.com") is accepted. Both certificates are issued by the same CA, and I have added the CA certificate to my device's trusted certificate list.

I am seeing the same behavior from Safari on my iPhone / iOS 8.1. The server with the wildcard certificate is reported as having an untrusted certificate, while the other server works fine. So it looks like iOS's default certificate verification rejects wildcard certificates. Is this the case?

Is there a way to tell SecEvaluateTrust to allow wildcard certificates? Here's an excerpt from my -connection:willSendRequestForAuthenticationChallenge:

- (void)connection:(NSURLConnection *)connection
    willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
  if ([challenge.protectionSpace.authenticationMethod
         isEqualToString:NSURLAuthenticationMethodServerTrust]) {
    SecTrustRef trust = [challenge.protectionSpace serverTrust];
    SecTrustResultType trustResult;
    OSStatus status = SecTrustEvaluate(trust, &trustResult);
    if (status == noErr) {
      if (trustResult == kSecTrustResultProceed
          || trustResult == kSecTrustResultUnspecified) {
        // Success. server2 gets here
      } else {
        // Server authentication failure. server1 gets here
      }
    }
  }
}

EDIT The Android version of our software accepts the wildcard certificates just fine, so I suspect there is something specific to iOS's certificate handling that is going on here. The Android client is using BrowserCompatHostnameVerifier to verify the certificate, which as far as I understand performs the same function as SecPolicyCreateSSL — performing the same checking on the certificate that a browser does.

回答1:

Since you see the same behavior with Safari too it is probably a problem of the certificate or what you expect the certificate to match. Please check (or post) the details of the certificate and how you access it. Example: A certificate which contains only an entry for *.example.com will match foo.example.com, but not example.com or bar.foo.example.com. Also, any information about the names should be in the SAN section (subject alternative names), the use of common name for this is depreciated.