I'm trying to make a Bitwarden iOS application to work with my self-hosted Bitwarden server. The server is backed by reverse proxy (nginx). I used letsencrypt-powered certificate in order to make it accessible via HTTPS. It works fine via web interface (not excluding Safari in iOS 15), but fails in iOS app:
Although, this app seems to accept certificate of https://bitwarden.com. At least it shows authentication error, from which i supposed that TLS socket was established normally. The funny thing that this certificate is powered by LetsEncrypt as well. Not funny at all, actually, cause it makes me totally confused.
The only requirements for TLS certificates, affecting iOS 15 I found are stated in Requirements for trusted certificates in iOS 13 and macOS 10.15. It imposes five restrictions on certificates, and it seems that my certificate meets all of them. Here is essential part of its text representation with corresponding comments.
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
There are ssl-related parameters of my nginx config:
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;
I would be very gratitude to anyone proficient in this subject for explanation what i done wrong and is there any chance to utilize self-hosted Bitwarden via iOS 15.
CodePudding user response:
Why IOS rejects LetsEncrypt-powered certificate?
The error message says nothing specifically about certificate issues and it does not look like a certificate problem to me. Instead the SSL configuration is pretty insecure:
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers AES256-SHA:RC4-SHA:DES-CBC3-SHA;
While AES256-SHA might still be still kind of acceptable, the other ciphers are considered for several years insecure and obsolete. iOS might not accept any of these because none of these provides forward secrecy, which then results in the error you see.
Additionally offering SSLv3 is insecure too.
It works fine via web interface
Since browsers have to work on a wide variety of sides they are usually more tolerant and will still work with slightly insecure settings. In this case the browser will likely pick AES256-SHA as sufficiently secure.
With apps instead usually more strict security settings are applied by default since it is assumed that the developer of the app also controls the backend and thus is able to set it up in a more secure way. From this perspective AES256-SHA is not acceptable since it does not provide forward secrecy.
I'm not sure how you came up with this unusual configuration, but for modern settings please consult moz://a SSL Configuration Generator