Feature #9825
closed
Requirements for trusted certificates in iOS 13 and macOS 10.15
Added by Daniel Gutierrez about 5 years ago.
Updated almost 4 years ago.
Description
Because Apple has shortened the maximum validity period of TLS server certificates to 825 days on iOS 13 & macOS Catalina (10.15), the default the PFSense CA interface uses (3650 days) should be shortened to 825 days or provide a warning if the user selects the Server Certificate type and the days exceed 825 days.
It may also be desired to update the interface to reflect the new Subject Alternative Name requirements for TLS server certificates as well (because "DNS names in the CommonName of a certificate are no longer trusted").
Requirements for trusted certificates in iOS 13 and macOS 10.15
https://support.apple.com/en-us/HT210176
I became aware of this article because access to pfSense broke for me in iOS 13 & macOS Catalina, and the error messages Safari gives you are generic and misleading (such as "certificate name does not match input" when it does).
- Category set to Certificates
- Assignee set to Jim Pingle
- Target version set to 2.5.0
We have automatically filled in the SAN based on the CN for a while now. You can't make a new cert without a SAN, since those have been widely rejected for a couple years now. I'll look into the other changes.
Not a resolution, but a related note: I am adding code to renew certificates with an option to enforce these parameters upon renewal. See #9842 for details.
This still needs at least some guidance in the GUI to warn against using weak parameters. The default choice for key length and lifetime exceed those stated in the requirements, so that should be OK with just a note. Lifetime will need warning text as well, but may need a bump via JavaScript when selecting a server certificate, or at least a more visible warning.
- Status changed from New to Feedback
- % Done changed from 0 to 100
I just pushed changes that should fully address the remaining concerns here.
Once on a snapshot with these changes, if a user needs a new GUI cert that conforms to the lifetime limit, they can run pfSsh.php playback generateguicert from an SSH or console shell.
Tested on 2.5.0.a.20191109.1723
Change default GUI cert lifetime to 825 days - OK
Add notes on CA/Cert pages about using potentially insecure parameter chocies - OK
Add visible warnings on CA/Cert pages if paramers are insecure/not recommended. - OK
Resolved
- Status changed from Feedback to Resolved
- Target version changed from 2.5.0 to 2.4.5
- Status changed from Resolved to Feedback
The default GUI cert lifetime of 825 days needs checked on 2.4.5 snapshots. If it's OK, move target back to 2.5.0 since there are other changes there that were not backported.
Jim Pingle wrote:
The default GUI cert lifetime of 825 days needs checked on 2.4.5 snapshots. If it's OK, move target back to 2.5.0 since there are other changes there that were not backported.
tested on 2.4.5.a.20191205.1442_3
Change default GUI cert lifetime to 825 days - OK
Add notes on CA/Cert pages about using potentially insecure parameter
chocies - NO
Add visible warnings on CA/Cert pages if paramers are insecure/not
recommended. - NO
- Status changed from Feedback to Resolved
Viktor Gurov wrote:
Change default GUI cert lifetime to 825 days - OK
That's all that needed testing, so it's fine.
- Target version changed from 2.4.5 to 2.5.0
- Status changed from Resolved to In Progress
Made the change on both. Better to be safe.
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
tested on 2.5.0.a.20200221.1911:
default cert creation, openvpn wizard, new cert creation, renew/reissue cert - ok
tested on 2.4.5.r.20200221.2100:
default cert creation - ok
Hi, actually new rules come in game: from 1 September 2020, SSL/TLS certificates cannot be issued for longer than 13 months (397 days).
And I not see that SSL on 2.5 or 2.4 are created with 825 days now - it still 3650 (10 years). Created ticket https://redmine.pfsense.org/issues/11463
Also available in: Atom
PDF
Updated by 
Updated by Viktor Gurov 
Updated by