Swift中SSL连接错误求助（错误码-9800/-1200）

Hey there, let’s break down this frustrating SSL error you’re hitting—ATS (App Transport Security) can be picky, but we can work through this step by step without resorting to the insecure NSAllowsArbitraryLoads workaround.

First: Fix Your Info.plist ATS Configuration #

Looking at your full info.plist, there’s a critical syntax issue with the NSAppTransportSecurity entry: it’s just a key with no corresponding dictionary value. This breaks the plist structure entirely, so iOS isn’t reading any ATS rules correctly. Here’s how to fix it:

Replace the broken NSAppTransportSecurity line with a valid dictionary structure. If your server meets ATS requirements (which it should with TLS 1.2+ and a valid GoDaddy cert), you can start with a basic empty dict, or add specific exceptions if needed:

<key>NSAppTransportSecurity</key>
<dict>
    <!-- Optional: Add specific domain exceptions if needed (avoid NSAllowsArbitraryLoads!) -->
    <key>NSExceptionDomains</key>
    <dict>
        <key>yourserverdomain.com</key>
        <dict>
            <key>NSIncludesSubdomains</key>
            <true/>
            <key>NSTemporaryExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
</dict>

Make sure this comes before the NSPhotoLibraryUsageDescription key in your plist—your current plist jumps straight to the next key after NSAppTransportSecurity, which is invalid.

Next: Verify Your GoDaddy SSL Certificate Chain #

A super common issue with GoDaddy certs is missing intermediate certificates. iOS requires the full certificate chain (server cert + intermediate certs) to trust the connection, not just the server cert alone.

To check this, run this command in your terminal:

openssl s_client -connect myserver:port -servername myserver

Look for the Certificate chain section in the output. You should see at least two entries: your server’s certificate, and GoDaddy’s intermediate certificate. If only one entry shows up, you need to install the missing intermediate cert in Tomcat/httpd.

GoDaddy provides intermediate certs for their SSL products—download the correct one from their support resources, then add it to your server’s certificate store (in Tomcat, this usually means importing it into your keystore alongside the server cert).

Then: Confirm Your TLS Cipher Suites Meet ATS Requirements #

Even if you’ve enabled TLS 1.2+, ATS requires cipher suites that support Forward Secrecy (PFS). Old, non-PFS suites will trigger the -9800 error.

To check which suites your server supports, run:

openssl ciphers -v | grep ECDHE

ATS requires suites starting with ECDHE (these are PFS-compliant). Make sure your Tomcat/httpd config is set to prioritize these suites and disable non-PFS ones like AES256-SHA or RC4-SHA.

For example, in Apache httpd, your SSL cipher config might look like:

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

Finally: Re-Run ATS Diagnostics #

After fixing the plist and server configs, run the nscurl command again with verbose output to get more details:

nscurl --ats-diagnostics --verbose https://myserver:port

This will show exactly which ATS requirement is failing—whether it’s a certificate issue, cipher suite problem, or TLS version mismatch.

Let me know if you hit any roadblocks while checking these steps! Certificate chain issues are the most likely culprit here, so start there if you’re short on time.

内容的提问来源于stack exchange，提问作者John