为什么 iOS 拒绝 LetsEncrypt 驱动的证书?

Why iOS rejects LetsEncrypt-powered certificate?

我正在尝试制作一个 Bitwarden iOS 应用程序来与我的自托管 Bitwarden 服务器一起使用。 服务器由反向代理 (nginx) 支持。我使用了 letsencrypt 驱动的证书,以便通过 HTTPS 访问它。它通过网络界面工作正常(不排除 iOS 15 中的 Safari),但在 iOS app:

中失败

不过,此应用似乎接受 https://bitwarden.com 的证书。至少它显示身份验证错误,我认为 TLS 套接字已正常建立。有趣的是,该证书也由 LetsEncrypt 提供支持。实际上,一点都不好笑,因为它让我完全困惑。

我发现的影响 iOS 15 的 TLS 证书的唯一要求在 Requirements for trusted certificates in iOS 13 and macOS 10.15 中说明。它对证书进行了五项限制,我的证书似乎符合所有条件。这是其文本表示的重要部分以及相应的注释。

    Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            04:3a:cc:90:eb:09:ca:f2:76:60:11:30:1a:30:27:dc:64:1b
    //>>>>>>
    //>>>>>> TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=R3
        Validity
            //>>>>>> 
            //>>>>>> TLS server certificates must have a validity period of 825 days or fewer
            Not Before: Nov 10 20:51:04 2021 GMT
            Not After : Feb  8 20:51:03 2022 GMT
        Subject: CN=bw.ivan-kondratyev.ru
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            //>>>>>> 
            //>>>>>> TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits.
                Public-Key: (2048 bit)
                Modulus:
                    00:c0:0b...
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            //>>>>>> 
            //>>>>>> TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier: 
                FD:FF:3D:B7:C9:C3:B4:E2:6A:2E:1B:52:56:FC:B4:F8:78:84:9F:6E
            X509v3 Authority Key Identifier: 
                keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

            Authority Information Access: 
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/
            //>>>>>>   
            //>>>>>> TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate
            X509v3 Subject Alternative Name: 
                DNS:bw.ivan-kondratyev.ru
            X509v3 Certificate Policies: 
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org

我的nginx配置有ssl相关的参数:

    ssl on;
    ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers         AES256-SHA:RC4-SHA:DES-CBC3-SHA;
    ssl_certificate /etc/letsencrypt/live/bw.ivan-kondratyev.ru/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/bw.ivan-kondratyev.ru/privkey.pem; # managed by Certbot
    ssl_session_cache   shared:SSL:10m;
    ssl_session_timeout 10m;

非常感谢任何精通该主题的人解释我做错了什么,是否有机会通过 iOS 15.

使用自托管的 Bitwarden

Why IOS rejects LetsEncrypt-powered certificate?

错误消息没有具体说明证书问题,在我看来这不像是证书问题。相反,SSL 配置非常不安全:

ssl_protocols       SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers         AES256-SHA:RC4-SHA:DES-CBC3-SHA;

虽然 AES256-SHA 可能仍然可以接受,但其他密码多年来一直被认为是不安全和过时的。 iOS 可能不接受其中的任何一个,因为其中 none 提供前向保密,这会导致您看到的错误。

另外提供 SSLv3 也不安全。

It works fine via web interface

由于浏览器必须在各种各样的方面工作,它们通常更宽容,并且仍然可以在稍微不安全的设置下工作。在这种情况下,浏览器可能会选择 AES256-SHA 作为足够安全的。

对于应用程序,默认情况下通常会应用更严格的安全设置,因为假定应用程序的开发人员也控制后端,因此能够以更安全的方式进行设置。从这个角度来看,AES256-SHA 是不可接受的,因为它不提供前向保密。

我不确定你是怎么想到这个不寻常的配置的,但对于现代设置,请参考 moz://a SSL Configuration Generator