As I said in another thread, basically that will kill any possibility to do your own CA for your own subdomain. Only the big one embedded in browser will have the receive to have their own CA certificate with whatever period they want...

And in term of security, I think that it is a double edged sword:

- everyone will be so used to certificates changing all the time, and no certificate pinning anymore, so the day were China, a company or whoever serve you a fake certificate, you will be less able to notice it

- Instead of having closed systems, readonly, having to connect outside and update only once per year or more to update the certificates, you will have now all machines around the world that will have to allow quasi permanent connections to random certificate servers for the updating the system all the time. If ever Digicert or Letsencrypt server, or the "cert updating client" is rooted or has a security issue, most servers around the world could be compromised in a very very short time.

As a side note, I'm totally laughing at the following explanation in the article:

   47 days might seem like an arbitrary number, but it’s a simple cascade:
   - 47 days = 1 maximal month (31 days) + 1/2 30-day month (15 days) + 1 day wiggle room

> everyone will be so used to certificates changing all the time, and no certificate pinning anymore, so the day were China, a company or whoever serve you a fake certificate, you will be less able to notice it

I'm a computing professional in the tiny slice of internet users that actually understands what a cert is, and I never look at a cert by hand unless it's one of my own that I'm troubleshooting. I'm sure there are some out there who do (you?), but they're a minority within a minority—the rest of us just rely on the automated systems to do a better job at security than we ever could.

At a certain point it is correct for systems engineers to design around keeping the average-case user more secure even if it means removing a tiny slice of security from the already-very-secure power users.

>As I said in another thread, basically that will kill any possibility to do your own CA for your own subdomain.

like, private CA? All of these restrictions are only applied for certificates issued under the webtrust program. Your private CA can still issue 100 year certificates.

Certificate pinning to public roots or CAs is bad. Do not do it. You have no control over the CA or roots, and in many cases neither does the CA - they may have to change based on what trust-store operators say. Pinning to public CAs or roots or leaf certs, pseudo-pinning (not pinning to a key or cert specifically, but expecting some part of a certificate DN or extension to remain constant), and trust-store limiting are all bad, terrible, no-good practices that cause havoc whenever they are implemented.

> everyone will be so used to certificates changing all the time, and no certificate pinning anymore

Browser certificate pinning is deprecated since 2018. No current browsers support HPKP.

There are alternatives to pinning, DNS CAA records, monitoring CT logs.

> 47 [is?] arbitrary, but 1 month, + 1/2 month, + 1 day are not arbitrary values...

Not related to certificates specifically, and the specific number of days is in no way a security risk, but it reminded me of NUMS generators. If you find this annoyingly arbitrary, you may also enjoy: <https://github.com/veorq/numsgen>. It implements this concept:

> [let's say] one every billion values allows for a backdoor. Then, I may define my constant to be H(x) for some deterministic PRNG H and a seed value x. Then I proceed to enumerate "plausible" seed values x until I find one which implies a backdoorable constant. I can begin by trying out all Bible verses, excerpts of Shakespeare works, historical dates, names of people and places... because for all of them I can build a story which will make the seed value look innocuous

From http://crypto.stackexchange.com/questions/16364/why-do-nothi...

> As I said in another thread, basically that will kill any possibility to do your own CA for your own subdomain

Only if browsers enforce the TLS requirements for private CAs. Usually, browsers exempt user or domain controlled CAs from all kinds of requirements, like certificate transparancy log requirements. I doubt things will be different this time.

If they do decide to apply those limits, you can run an ACME server for your private CA and point certbot or whatever ACME client you prefer at it to renew your internal certificates. Caddy can do this for you with a couple of lines of config: https://caddyserver.com/docs/caddyfile/directives/acme_serve...

Funnily enough, Caddy defaults to issueing 12 hour certificates for its local CA deployment.

> no certificate pinning anymore

Why bother with public certificate authorities if you're hardcoding the certificate data in the client?

> Instead of having closed systems, readonly, having to connect outside and update only once per year or more to update the certificates, you will have now all machines around the world that will have to allow quasi permanent connections to random certificate servers for the updating the system all the time.

Those hosts needed a bastion host or proxy of sorts to connect to the outside yearly, so they can still do that today. But I don't see the advantage of using the public CA infrastructure in a closed system, might as well use the Microsoft domain controller settings you probably already use in your network to generate a corporate CA and issue your 10 year certificates if you're in control of the network.

If you're in a position to pin certs, aren't you in a position to ignore normal CAs and just keep doing that?

42