Abstract
The pitch for private PKI gets more compelling every year. Public certificate lifetimes are down to 200 days, dropping to 47 by 2029. If you run your own private certificate authority, you make your own rules. Issue certificates for as long as you want, skip the renewal churn. Let’s Encrypt and DigiCert don’t get to tell you what to do.
Apple does though.
Apple’s certificate mandate
When Apple reduced public certificate lifetimes to 398 days in 2020, the announcement included a specific carve-out: “This change will not affect certificates issued from user-added or administrator-added Root CAs.” That exemption still holds. The CA/Browser Forum rules that set the current 200-day ceiling cover publicly trusted CAs. Your private CA is not in scope.
There’s a second Apple proclamation though, published for iOS 13 and macOS 10.15 in 2019, that says something different:
“All TLS server certificates issued after July 1, 2019 must have a validity period of 825 days or fewer.”
Not public CAs. Not browser-trusted CAs. All TLS server certificates. Even your private or self-signed ones.
Apple’s trustd daemon, the process that evaluates certificate trust on macOS and iOS, logs this when it rejects a cert: “Non-system-trusted leaf validity period longer than 825 days and issued on or after 1 July 2019.”
Michal Špaček confirmed the exact threshold empirically by issuing sixteen test certificates from a private CA and doing a binary search: 825 days works, 826 days does not. An Apple DTS engineer confirmed it in the developer forums in plain terms: “private roots do not have to be under 398 days, but they do have to be under 825 days.”
Your private CA is exempt from the 200-day public cert rule. It is not exempt from the 825 day rule.
The part that makes it maddening
Issue a 3-year certificate from your private CA and deploy it to an internal service, and here is what happens. Windows: works. Linux: works. Chrome on anything: works. Firefox: works. Then someone opens Safari on a Mac or an iPhone.
Safari’s error when a private CA certificate exceeds 825 days: “Safari cannot open the page because it could not establish a secure connection to the server.” That’s it. No details. No certificate viewer link. No “continue anyway” option. The same message you’d see for a completely untrusted CA or an expired cert. Nothing in the UI indicates the cert is being rejected because the validity period is too long.
There is nothing in that error that tells you where to look.
What 825 days actually means for your private PKI
825 days is just under 27 months. Compared to the 47-day ceiling public PKI is heading toward, that sounds generous, but there are some issues in practice.
If your private CA issued 5-year or 10-year certificates before you knew this limit existed, those certificates are already failing in Safari or will soon. A 3-year cert issued in early 2024 hits the wall in early 2026. The private PKI that was supposed to spare you from the renewal calendar still has a calendar. You just didn’t know about it, and it doesn’t send you reminders.
The broader point: owning the CA does not mean you’re off the renewal treadmill. It means you’re on a longer schedule with worse error messages when you fall behind. If your private PKI serves anything accessed from Macs or iPhones, 825 days is your actual ceiling, not whatever validity period you typed when you issued the cert.
Automation still matters here. Not because 27 months is a difficult interval to remember, but because the failure mode when you do forget is invisible to most of your team and completely opaque when you try to diagnose it.
CertKit manages certificate lifecycle, so a quiet Safari error on someone’s MacBook is not how you find out a certificate expired.
Comments