> The choice of 397 days represents the maximum legitimate interpretation of a "thirteen-month" period; it's calculated from 366 days (considering leap years) along with a 31-day month, the longest in the calendar used by certificates. And the “Must Not Exceed 398 days” also accommodate the different time zones and any other unexpected error.
1 year (366 days): See the ballots and accompanying discussion linked in other comments about the proposal to reduce validity to 1 year.
1 month (31 days): Grace period for human beings, to permit weekends, vacations, and continuity handoffs.
1 day (timezones): Grace period for browsers and shared libraries, to survive the timezone math issues with "It's one day greater than today somewhere in the world". This ends up baked into the process as follows: Certificates will be issued for "397 days or less", browsers and libraries will validate as "398 days or less".
With 13 months, you can renew your certificate once per year and still have one month of buffer time. But in 2 or 3 years the maximum length might be tightened even further. At least there has been such a trend of length decreases in the past.
I am just guessing but I think it's because of renewals. I know in the past when I've purchased a certificate before the expiration date, the CA gives me that extra time on the new cert so the expiration date stays the same the following year.
Totally speculating here that 30 days is probably the earliest one can renew a yearly cert.
You can of course renew earlier, but limits like these prevent the CA from giving you "extra" time beyond the limit so it'd be silly to renew an annual certificate six months before it expires, as you'd only add about 7 months to the lifespan for the full price.
Without this extra margin there'd be an incentive to cut it as fine as possible on renewal (or even not renew until the expiry causes problems) which is bad for security, bad for business continuity and bad for the CA businesses.
The practice of adding unused time to new certificates goes back a long way and probably is a business practice copied from other things you need to renew in this way. After the CA/B Forum came into existence they standardised a limit of 39 months (3 years + 3 months) to support this existing business practice while forbidding new very long lived certificates, this didn't take effect immediately, instead it was allowed to phase in by 2015.
That limit is a bit vague, which wasn't good. Machines don't really do vague, you can see what Chromium does about that in the linked source code - they pick 1188 days as "39 months" on the argument that while 39 months might sometimes be shorter than 1188 days it can't be longer.
In 2018 the CA/B forum agreed a new limit, 825 days, the specification in days is to avoid vagueness, 825 is two years plus three months plus a very generous allowance for various holidays and other accidents and I think that getting votes for 825 days was judged better than losing votes for some slightly shorted lifespan like 798 days.
Proposals to further reduce this year or next year fell through and apparently Apple decided that rather than negotiate they'd take the nuclear option, which is always something they could do. With Apple eating the PR cost there's no reason why Chromium shouldn't enforce the same limit.
