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.
Let's suppose that I'm a competitor of Google and Amazon, and I want to have my Public root CA for mydomain.com to offer my clients subdomains like s3.customer1.mydomain.com, s3.customer2.mydomain.com,...
If you want to be a public root CA, so that every browser in the world needs to trust your keys, you can do all the lifting that the browsers are asking from public CAs.
Why do you want this when there are wildcard certificates? That's how the hyperscalers do it as well. Amazon doesn't have a separate certificate for each s3 bucket, it's all under a wildcard certificate.
Amazon did this the absolute worst way - all customers share the same flat namespace for S3 buckets which limits the names available and also makes the bucket names discoverable. Did it a bit more sanely and securely at Cloudflare where it was namespaced to the customer account, but that required registering a wildcard certificate per customer if I recall correctly.
The only consideration I can think is public wildcard certificates don't allow wildcard nesting so e.g. a cert for *.example.com doesn't offer a way for the operator of example.com to host a.b.example.com. I'm not sure how big of a problem that's really supposed to be though.
No. Chrome flat out rejects certificates that expire more than 13 months away, last time I tried.
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.
Ok, but what's the alternative?
Support for cert and CA pinning is in a state that is much better than I thought it will be, at least for mobile apps. I'm impressed by Apple's ATS.
Yet, for instance, you can't pin a CA for any domain, you always have to provide it up front to audit, otherwise your app may not get accepted.
Doesn't this mean that it's not (realistically) possible to create cert pinning for small solutions? Like homelabs or app vendors that are used by onprem clients?
We'll keep abusing PKI for those use cases.
> 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.
Cert pinning is a very common practice for mobile apps. I'm not a fan of it, but it's how things are today. Seems likely that that will have to change with shorter cert lifetimes.
> 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