4 ms·
Apple recently (last fall) introduced a change that rejects all certificates that are valid for more than two years, whether they're public or private. I would
by castillar76 7y ago
Apple recently (last fall) introduced a change that rejects all certificates that are valid for more than two years, whether they're public or private. I would double-check whether the self-signed certificates are valid for longer (many default self-sign processes make ten-year certs, for instance). Failing that, you may have to create a proper private PKI and get users to install the CA, or else use something like Let's Encrypt for certs.
- j1elo 7y agoThanks! you gave me one thing to check. The certs are indeed made for 10 years validity, the idea being that they should just make the demo work for a long time, even if it is with a certificate warning. I don't think it's worth the effort of setting up all the automatic renewal process with Let's Encrypt for what amounts to a quick static code example... so in principle I wanted to avoid having to set that up. The contents of this article means that soon this 2-year maximum will become a 13-month maximum, right? Is there any way to create these specific-purpose certs with some kind of "private use" or "development use" flag that allows not having to re-create them so soon? 13 months looks too short of a time period, I'm afraid nobody will remember to refresh the fake certs and the demos will break... for really no good reason (related to the code itself)
- castillar76 7y agoNo, Apple was clear that this change (the 13-month limit) only affects public certificates, so internal private PKIs and self-signed certificates retain the two-year limit from before. I think that that two-year limit extends to every certificate used for TLS in the system, so there's no way to get around it by manually trusting the certificate or CA chain (there's no 'development use' flag on certs), but that bears testing.