This may end up crossing into the feature request section.
Pi-Hole instance running on the following
Hardware GMKtec NucBoxG3_Plus
Windows 11 Pro Version 24H2 Build 26100.3775
Hyper-V Manager 10.0.26100.1882
Ubuntu 24.04.2 LTS
Docker - No
Apple Client
iPad Pro (3rd generation) iPadOS version 18.3.2
Expected Behaviour:
Assuming that the certificate for the Certificate Authority (pi.hole), is correctly stored in the Trusted Root Certification location for each client machine that will access the Pi-Hole administartion website, the following should occur:
Note: Periods in example domain names changed to underscore to prevent links.
Windows 11 - Chrome: Navigate to https://secondary_backup_pihole_home_arpa yields a secure connection
Windows 10 - Chrome: Navigate to https://secondary_backup_pihole_home_arpa yields a secure connection
iPadOS 18.3.2 - Chrome: Navigate to https://secondary_backup_pihole_home_arpa yields a secure connection
iPadOS 18.3.2 - Safari: Navigate to https://secondary_backup_pihole_home_arpa yields a secure connection
Pi-Hole currently creates a server side certificate with a validity period of 30 years. Apple currently won't trust it. Microsoft currently doesn't complain about a long validity period. I have no idea if the validity period should be changed in Pi-Hole.
I'm going to either create a new server side certificate with a shorter validity period or access the Pi-Hole website via port 80.
The bottom line is that I don't have to use TLS, but someone else may require it.
From today until March 15, 2026, the maximum lifetime for a TLS certificate is 398 days.
As of March 15, 2026, the maximum lifetime for a TLS certificate will be 200 days.
As of March 15, 2027, the maximum lifetime for a TLS certificate will be 100 days.
As of March 15, 2029, the maximum lifetime for a TLS certificate will be 47 days.
It remains to be seen how quick client software - web browsers, in particular - would implement respective changes, and how they would deal with a valid certificate that only exceeds the validity threshold.
Apple OSs current refusal to acknowledge otherwise valid certificates if their validity is above 825 days already has prompted a discussion, but that didn't trigger any changes, as OP reported that SSL/TLS access started working for them (see HTTPS nutzen - Bitte um Hilfe - #13 by DL6ER).
In that topic, @DL6ER's main concern when reducing certificate validity was about automatically renewing Pi-hole's self-signed certificate, as Pi-hole would need a method to tell certificates it created itself from third-party certificates. Maybe remembering the exact timestamp of creation could help with that?
Both Apple screenshots you posted had a clickable link like If you understand the risks involved, you can visit this website. A self-signed certificate is always a security issue. I am not sure why your Windows machines seem to have accepted the certificate, yet, I don't think the validity of 30 years has anything to do with the lower error screenshots hint at a not trustworthy certificate - not about its validity. I can see this only in the third.
We will think about a solution, probably we have to write an extension ourselves to the Civetweb webserver allowing it to reload certificates without full restarts.
I very much appreciate Bucking_Horn and DL6ER taking the time to respond to my post.
If it makes any difference, I have attached another screen shot of a browser running on my iPad that includes the ERR_CERT_VALIDITY_TOO_LONG message, this time Microsoft Edge.
I have two other browsers on the iPad, FireFox and DuckDuckGo, that failed in a manner similar to Apple Safari. No explanation of error.
I originally came across this issue while installing a self-hosted version of Bitwarden. I created a Certificate Authority with a 20 year validity period and a 10 year server side certificate. Connections to the Bitwarden server worked from all my Windows machines. The Bitwarden app on my iPad and iPhone would not connect until I recreated the server side certificate with a 365 day validity period. I only had the earlier Apple announcement at the time, hence I went with 365 days.
As for Windows accepting the longer validity periods, it could be that Windows doesn't apply the shorter periods to self-signed certificates. This is from the first Apple announcement:
"This change will affect only TLS server certificates issued from the Root CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS"
and at the bottom of the announcement
"This change will not affect certificates issued from user-added or administrator-added Root CAs".
These notes were not in the second announcement. Windows appears to follow these exceptions. Apple does not.
It took quite some time but here is the proposed automatic renewal of the self-generated certificates in case of certificated with short-term validity:
The proposed validity range is reduced from 30 to 2 years in here, but this is not set in stone. I'd like to foster a discussion here for what you think is needed.
Note: Short lifetimes may cause some inconvenience to users. Whenever the certificate is automatically regenerated, users will again have to confirm that they want the browser to trust the new certificate:
Even worse: When users decided to add the CA to their browser's trust store, they will need to replace the certificate here as well or they may end up with quite non-obvious cryptic error messages depending on the particular browsers.
