为什么 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
我正在尝试制作一个 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.
使用自托管的 BitwardenWhy 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