Have to disable 'Domain Name Validation' to get TLS working

[windsource]

I use OwnTracks 13.1.7 on iOS 13.3 with an iPhone 8. The broker is mosquitto with TLS enabled on port 8883 and a self-signed certificate. I transferred the CA cert to the iPhone and enabled it. But in order to get a connection I had to enable 'Use Custom security policy' and disable 'Validate Domain name'. Disabling domain name validation is scary to me. The broker certificate works fine with mosquitto_sub/pub and other apps like OwnTracks recorder.
I don't use certifcate pinning, Mode is 'None', 'Validate Certificate Chain' is disabled and 'Allow Untrusted Certificates' is disabled as well. I also double-checked that the correct domain name is entered in the common name field of the certificate.

Does anyone have an idea what's the reason why I have to disable 'Domain Name Validation' ?

[windsource]

The CN is the domain name in the form www.example.com and I do not have a SAN. With Let's Encrypt I can only create a server certificate but I also use client certificates and that's why I have my own CA.

[windsource]

Just found the page Requirements for trusted certificates in iOS 13 and macOS 10.15. So generating a mosquitto TLS certificate, that is also accepted by iOS seems to be much more complicated than explained in https://mosquitto.org/man/mosquitto-tls-7.html.

Does anyone has a hint or script for that?

[jpmens]

This has worked well for people.

[windsource]

Thanks for the hint. But I think generate-CA.sh also does not set the ExtendedKeyUsage (EKU) extension, does it?
I finally used XCA do generate the broker certificate with the fields required by Apple and it works. I was also able to disable 'Use Custom security policy'.

[jpmens]

@windsource would you be willing to give this updated version a spin before I commit the code?

I’ve added:

• larger keysizes (4096 bits)
• max validity days 825, as required by Apple
• extendedKeyUsage extension for TLS Web Server Authentication (1.3.6.1.5.5.7.3.1)

I believe this should cover iOS/macOS requirements for trusted certificates and would appreciate your feedback.

[windsource]

@jpmens I am not sure how to use the script in the right way. My MQTT broker runs as part of my Kubernetes cluster to which a lot of DNS entries point to, one of them - let's assume mqtt.mydomain.com - for the broker. I generate the certificates from my development laptop at home.

So I call the script with

export HOSTLIST="mqtt.mydomain.com"            
./generate-CA.sh 

But then the CN is the name of dev laptop and the SAN also contains localhost and some IP addresses which is not what I want.

[jpmens]

@windsource you can specify any number of host names or IP addresses (with IP list) which are then added as SAN. The CN is ignored by Apple clients anyway according to their documentation and oughtn't to hurt your tests I should think, but you can specify it as argument:

export IPLIST="172.13.14.15 192.168.1.1"
export HOSTLIST="a.example.com b.example.com"
./generate-CA.sh my-server.name

Invoking ./generate-CA.sh without arguments creates a CA certificate.

[windsource]

I think the script does not work correctly. When I call

./generate-CA.sh my-server.name

sometimes my-server.name is put in 'Subject Alternative Name' and sometimes is not. Might depend on the server name but I am not sure.

[jpmens]

I might have lied to you if/when I said the host name you pass is added to the SAN list; please add that to HOSTLIST explicitly

[ckrey]

@windsource are you now happy with the amended ./generate-CA.sh together the app configured with iOS standard TLS (without Custom SSL Security Policy) or do we need to put in some more attention to this?

[windsource]

I am happy with my solution that consists of using XCA to generate the certificates. So the problem for this issue is solved (I actually closed the issue before it was re-opened). Regarding ./generate-CA.sh maybe someone else should check it as I do not use that script.

[brummbrum]

just tried with certificates created with https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh on iPhone 8 iOS 13.5.1.
CA.cert imported fine into iOS profile, but:

In order to get a connection I also had to enable 'Use Custom security policy' and disable 'Validate Domain name'. Mode is 'None', 'Allow Untrusted Certificates' is disabled. 'Validate Certificate Chain' can be ENABLED.

However, the broker certificate works fine with mosquitto_sub/pub --cafile ....

[ckrey]

see #605

Does your server's certificate adhere to the new checking policy Apple introduced with iOS 13?

https://support.apple.com/en-us/HT210176

FWIW, we've fixed our certificate generation utility to adhere to those rules: server certificates are issued with a validity of 825 days.

[brummbrum]

Thx for the feedback! Maybe that is indeed the reason. My server certificate (I am not using a client certificate) generated with @jpmens utility is still using the longer validity period, i.e. maxdays() till the year 2032. Since I have already deployed the certificate to a couple of users I am wondering if I should simply keep it with the current settings in the app.

Is there any difference in the actual connection set up? I.e. by choosing "Custom Security Policy" Mode = "None" the iOS app still establishes a TLS 1.2 channel with the server in the exact same way: same cipher suite and using the server certificate, right? Or does "None" mean it ignores the server certificate? If the channel is established in the same way I would rather leave everything as is right now instead of having to reconfigure all clients and the server.

[ckrey]

The new app version 13.3.5 does not support "Custom Security Policy" mode anymore.

I am not sure if this is in any way related to TLS1.2 or cipher suites.

"None" means you did not provide any server certificate or fingerprint on the client.

To establish a TLS connection with a self signed server certificate you will need to update the server certificate (no need to update the server certificate on the clients).

If you have to " disable 'Validate Domain name'" then your server's certificate does not contain your servers name!? Why not?

[brummbrum]

Hmm, will have to give it a try again when I find some time.

So you say that I can keep the CA certificate (which also is valid until 2032) on the clients - Apple has no problem with that? I.e. it is just the long validity of the server certificate which messes things up? I.e. if I recreate the server certificate with 825 days validity and use the existing CA certificate to sign it then the clients should be able to use it without complaint?

The weird thing is that right now, with policy set to "None", I still get a TLS channel set up which is clearly encrypted (I captured the packets with Wireshark and they are shown as TLS including the initial handshake etc and the payload appears encrypted).

Regarding the domain name: Yeah, I guess I messed something up there. I am using a DDNS but probably used the wrong domain name when creating the server certificate. Thanks again for all your valuable input.

[brummbrum]

Update:
I replaced my previous server certificate with a new one that expires after 824 days and has the correct DDNS domain name.
-> With Custom Policy = ON it is now possible to use Validate Domain Name. But first I had to also allow untrusted certificates (despite following instructions from the booklet https://owntracks.org/booklet/features/tls/#ios).
-> I realized that nowadays installing a certificate and trusting it requires an additional step in iOS. After following the instructions from the booklet for installation of the certificate I had to go to Settings/General/About/Certificate Trust Settings and enable full trust for root certificates for my CA cert. You may want to update the booklet accordingly.

After that step it is finally possible to drop the entire Custom Policy. All working fine now - thanks again for your great work and support!

[jpmens]

For the record, and because a number of issues point to this one, TLS server certificates issued on or after September 1, 2020 00:00 GMT/UTC must not have a validity period greater than 398 days. This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS.

The article explicitly says:

This change will not affect certificates issued from user-added or administrator-added Root CAs.