[英]Why is my server's wildcard SSL certificate being rejected?
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.我使用
NSURLConnection
连接到带有通配符 TLS 证书(如“*.domain.com”)的服务器,并且当我在NSURLConnectionDelegate
的-connection:willSendRequestForAuthenticationChallenge:
方法中调用SecTrustEvaluate
时,证书被拒绝为无效。 Another server that has a fully-specified TLS certificate (like "server2.domain.com") is accepted.接受另一台具有完全指定 TLS 证书(如“server2.domain.com”)的服务器。 Both certificates are issued by the same CA, and I have added the CA certificate to my device's trusted certificate list.
两个证书均由同一个 CA 颁发,并且我已将 CA 证书添加到我设备的受信任证书列表中。
I am seeing the same behavior from Safari on my iPhone / iOS 8.1.我在 iPhone/iOS 8.1 上看到 Safari 的相同行为。 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.
所以看起来iOS的默认证书验证拒绝通配符证书。 Is this the case?
是这种情况吗?
Is there a way to tell SecEvaluateTrust
to allow wildcard certificates?有没有办法告诉
SecEvaluateTrust
允许通配符证书? Here's an excerpt from my -connection:willSendRequestForAuthenticationChallenge:
这是我的
-connection:willSendRequestForAuthenticationChallenge:
的摘录-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.编辑我们软件的 Android 版本接受通配符证书就好了,所以我怀疑这里有一些特定于 iOS 证书处理的东西。 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. Android 客户端使用
BrowserCompatHostnameVerifier
来验证证书,据我所知,它执行与SecPolicyCreateSSL
相同的功能——对浏览器执行的证书执行相同的检查。
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.由于您在 Safari 中也看到了相同的行为,因此可能是证书问题或您期望证书匹配的内容。 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
.示例:仅包含
*.example.com
条目的证书将匹配foo.example.com
,但不匹配example.com
或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.此外,有关名称的任何信息都应在 SAN 部分(主题备用名称)中,因此不赞成使用通用名称。
Another reason why we faced the same issue with the newest iOS devices: Apple doesn't allow underscores (_) in domain names .我们在最新的 iOS 设备上遇到同样问题的另一个原因是: Apple 不允许域名中包含下划线 (_) 。
Without underscores everything started to work.没有下划线,一切都开始工作。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.