Anyway thank you very much for your help 
I am almost 100% sure that problem is because some fields are missing in root cert file or server cert file generated by minica.
I did point out earlier (on my first post):
And followed with this on my second post:
So we are kind of on the same page there.
But I don't know where/how to modify that code to be more... aesthetically inline with (my perception of) generally accepted fields in certs (mind you, I'm no subject matter expert on this - and root certs may well be expected to be as yours currently is)
We have to wait for @jsha answer.
He is owner of minica and could help fixing its code with proper fields.
We have started conversation here https://github.com/jsha/minica/issues/16 then move here
As expected, checking the root certs on this pc - they are all similarly unpleasantly.
So the CN and lack of SAN are a non-issue.
lack of SAN could be the issue when using it on IOS.
I read somewhere that SAN is neccessary for certs on IOS
I don't think that is where the problem lies (see prev post)
If you could somehow allow Internet access to the site, you should point SSLlabs at it and see what they find.
In the meantimeâŚ
Letâs see what we can find out about the curves served and/or their ordering.
I will forward temporary port 443 on my router to my local server and will do SSLabs tests later
SSLlabs only starts their testing on FQDNs (not for IPs).
So have one ready.
Although, the site doesnât need to match the FQDN to be checked - just accept the âmismatchâ and post the results here.
Using a FQDN is going to confound the test (since it may be a policy issue relating to x.509 verification). SSL Labs doesnât matter, once the host is exposed to the internet, we can just try connect directly from Apple devices and see what the problem is.
I also have my doubts about rusttls being bug free âŚ
As I said on the GitHub issue, minica does in fact always set the SAN fields in end entity certificates. You can check this yourself with openssl x509 -text.
From the error you get in Mobile Chrome, it sounds like your server is expecting a client authentication certificate. My guess is that you already set up a client authentication certificate on your computer, but on your mobile you donât have one set up. Does that ring a bell for you?
That would be ideal but I'm not certain he would like unknown Internet connections to this system.
SSLLabs uses a known test network: 64.41.200.0/24
https://whois.arin.net/rest/net/NET-64-41-200-0-1/pft?s=64.41.200.0
https://github.com/dani-garcia/bitwarden_rs doesnât appear to sport any mention or implementation of mTLS ⌠and itâs not unheard of to see errors that appear to be about client auth, but are just the TLS handshake being wonky.
1 Like
I added root cert generated by minica on my iphone. Should I import server cert as well?
Currently I dont have access to my router admin panel. Later I will forward port 443 and will do checks on https://www.digicert.com/help or https://www.sslchecker.com/sslchecker because it support IP
If your only reason to not use SSLLabs is not having an FQDN, send me your IP and I can put one up instantly.
I would definitely include SSLLabs in your testing.
I found out that self signed cert for my NAS is working great on my ios.
But canât find any differences https://pastebin.com/raw/veRSsVSc
Please show output of:
openssl s_client -connect {YOUR.NAS.IP}:443
https://pastebin.com/raw/WbnNyHDv
Maybe port other than 443 is the answer
And maybe changing the curve in use is the answer:
Your NAS uses:
Server Temp Key: ECDH, P-256, 256 bits