
Chromium and Mozilla to enforce 1 year validity for TLS certificates - vld
https://chromium.googlesource.com/chromium/src/+/ae4d6809912f8171b23f6aa43c6a4e8e627de784
======
paledot
With the tightening of certificate trust, demise of self-signed certificates,
etc., is there any remaining way to establish a consumer-oriented HTTPS server
on a local network? Thinking of things like routers, printers, and self-hosted
IoT devices here. Some of the label printers we support at work have simply
atrocious workarounds to get them to work, and I'm wondering if it's the
manufacturer's fault or if that use case has been completely abandoned in the
push for tighter security on the Internet.

~~~
elcritch
It’s a glaring security hole, IMHO. I create such devices and the only way I
know is self-signed certs, but the browsers complain a lot about that. Ideally
there’d be a way to sign .local domains with browsers handling it while
letting people know to verify the identity of their local devices/services and
that the identity isn’t verified by https like most sites.

The issue lies between the browsers and https system. SSH can do encryption
without requiring identity verification. It handles it by asking "Do you want
to trust this new server?". Then if it changes informs you of that. Browsers
could easily implement that for .local with self-signed certs.

Of course browser developers assume everyone has internet all the time and you
only access servers with signed domains. I’ve wondered what it’d take to get
an ITEF/W3C RFQ published for .local self-signed behavior.

(Edit: RFQ, not my autocomplete’s RTF)

~~~
akira2501
> Ideally there’d be a way to sign .local domains with browsers handling it
> while letting people know to verify the identity of their local
> devices/services and that the identity isn’t verified by https like most
> sites.

For these types of sites we run a local CA, and sign regular certificates for
these domains and then distribute the CA certificate to our windows clients
through a GPO. When put into the correct store, all our "locally-signed"
certificates show as valid.

In other instances, where I haven't been able to do that, like for disparate
VPN clients and such I will generally assign a RFC1918 address to it. Like
service.vpn.ourdomain.com resolves to 10.92.83.200. As long as I can respond
to a DNS challenge, I can still get a letsencrypt certificate for that domain.

~~~
johntash
> In other instances, where I haven't been able to do that, like for disparate
> VPN clients and such I will generally assign a RFC1918 address to it. Like
> service.vpn.ourdomain.com resolves to 10.92.83.200. As long as I can respond
> to a DNS challenge, I can still get a letsencrypt certificate for that
> domain.

This is basically what I've been doing lately as well. I'll create a wildcard
letsencrypt cert for _.vpn.ourdomain.com and then point the subdomains to
internal IPs. You can even set up a split-dns where it responds to the
challenge txt records for letsencrypt, but only the internal side responds to
requests under_.vpn.ourdomain.com.

------
floatingatoll
This CCADB vote provides the context missing from this link to a Chromium
patch. After the CA issuers rejected 2017 and 2019 proposals (Ballot 185,
Ballot SC22) to reduce certificate issuance times to ~1 year, Apple announced
enforcement of the rejected 398-days limit across all platforms on 01 Sep
2020, the CAs reversed their position while complaining that they were being
forced to, and Chromium is now implementing the policy as well.

[https://cabforum.org/2017/02/24/ballot-185-limiting-
lifetime...](https://cabforum.org/2017/02/24/ballot-185-limiting-lifetime-
certificates/)

[https://archive.cabforum.org/pipermail/servercert-
wg/2019-Se...](https://archive.cabforum.org/pipermail/servercert-
wg/2019-September/)

[https://ccadb-
public.secure.force.com/mozillacommunications/...](https://ccadb-
public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107)

> _SUB ITEM 3.1: Limit TLS Certificates to 398-day validity Last year there
> was a CA /Browser Forum ballot to set a 398-day maximum validity for TLS
> certificates. Mozilla voted in favor, but the ballot failed due to a lack of
> support from CAs. Since then, Apple announced they plan to require that TLS
> certificates issued on or after September 1, 2020 must not have a validity
> period greater than 398 days, treating certificates longer than that as a
> Root Policy violation as well as technically enforcing that they are not
> accepted. We would like to take your CA’s current situation into account
> regarding the earliest date when your CA will be able to implement changes
> to limit new TLS certificates to a maximum 398-day validity period._

~~~
altfredd
Sounds like CAs will be forced to keep shrinking cert length until everyone
standardizes on 1 month. They no longer have any real power.

~~~
brnt
Will browsers start allowing self signed certificates though?

~~~
cpach
As long as you first create a root certificate then you can create how many
certificates you want.

~~~
dingaling
Assuming non-chained root CAs remain trusted.

I can forsee the browsers eventually treating self-created CAs like they
currently treat self-signed certs. if they're not traceable to a trusted root
CA then there's no accountability, from a browser perspective, in the event of
abuse or breach.

~~~
chongli
Then people will create their own root CA and use it to sign the existing root
CAs. Whatever it takes. Corporate users need internal certificates.

------
greatgib
Remember the good old time when it was not an almighty cartel of browsers that
controlled your internet?

This is so an arbitrary decision and so much a pain in the ass. Again, a
limited number of people used their corporate interests to decide for the
whole world with almost no discussion.

The worst is that the "security" argument for this change is quite weak. Yes,
we can think that shorter certificates are a little bit better to trust for
the user, but that should be the choice of the website that you visit.

Now, you as an user are so stupid, that browsers will decide for you what
website is deemed safe for you to visit, the same as with appstores. Compared
to the good old time, like traditional pc software installation, where it was
you, the user that was free to decide the websites that you wanted to trust:
google.com vs myshaddyfraudyweb.com

~~~
CydeWeys
I'm surprised to see this as the highest comment on this post.

This is a clear security win, and thus good for users. And no, I _don 't_
trust websites to have my best interests in mind, not remotely. Hell, if
browsers hadn't started warning about insecure connections then I suspect that
even to this day most websites would still be insecure. We used to leave it up
to the choice of each website, and that was a clear failure, and now they're
being forced to provide better security, which is a clear win.

~~~
GordonS
I agree with you about publicly available websites, but I'm not convinced this
policy makes sense for IoT devices, especially for ones that aren't connected
to the internet.

------
est31
From the source code:

[https://chromium.googlesource.com/chromium/src/+/ae4d6809912...](https://chromium.googlesource.com/chromium/src/+/ae4d6809912f8171b23f6aa43c6a4e8e627de784/net/cert/cert_verify_proc.cc#957)

    
    
      // For certificates issued on-or-after the BR effective date of 1 July 2012:
      // 60 months.
    
      // For certificates issued on-or-after 1 April 2015: 39 months.
    
      // For certificates issued on-or-after 1 March 2018: 825 days.
    
      // For certificates issued on-or-after 1 September 2020: 398 days.
    

The source code also requires certificates issued before 1 July 2012 to expire
on Jul 1st, 2019 at the latest.

~~~
dane-pgp
On 30 April 2018 it became a requirement (in Chrome) for all certificates
issued after that date to be recorded in a public Certificate Transparency
log[0]. A certificate issued on 28 February 2018 could therefore be issued
without being logged, while having a validity period of 39 months. Such a
certificate would be valid until 28 May 2021.

Does that mean that next May, for the first time ever, the domains of all
HTTPS sites on the web will be recorded in a public log? I think the only
caveat to that is wildcard certificates.

[0] [https://www.feistyduck.com/bulletproof-tls-
newsletter/issue_...](https://www.feistyduck.com/bulletproof-tls-
newsletter/issue_40_certificate_transparency_logging_is_now_mandatory)

~~~
tialaramex
In practice it's probably already true or very close to true that names from
certificates in the Web PKI that are intended to be publicly accessible are
all logged. As you observe if the name listed is a wildcard this doesn't tell
you which (if any) of the names implied by that wildcard actually exist, and
indeed no names for which certificates were issued need necessarily exist, the
rule is only that if they _did_ exist they'd belong to the subscriber.

Although the Chrome mandate only technically kicked in on 30 April in practice
most CAs were considerably ahead of that date, in addition some of the logs
are open to third parties uploading old certificates, Google even operates
logs that deliberately accept certain untrustworthy certificates, just because
it's interesting to collect them.

If you're excited to know what names exist, the Passive DNS suppliers can give
you that information for a price today, their records will tell you about
names that aren't associated with any type of certificate, and lots of other
potentially valuable Business Intelligence. They aren't cheap though, whereas
harvesting all of CT is fairly cheap, you can spin up a few k8s workers that
collect it all and store it wherever (this is one of the tasks I did in my
last job).

------
reaperhulk
This is Google and Mozilla aligning with Apple's earlier announcement
([https://support.apple.com/en-us/HT211025](https://support.apple.com/en-
us/HT211025)).

The CABF has talked about doing this before, most recently in SC22
([https://cabforum.org/2019/09/10/ballot-sc22-reduce-
certifica...](https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-
lifetimes-v2/)). In that case all browsers supported it, but it wasn't passed
by the CA side.

------
markstos
This may be good for security, but it is extra burden for small web developers
and individuals. Big players will have cert renewals automated.

It's possible and free for small players to use letsencrypt, that still takes
some time to set up, manage and maintain over time.

Without automation, you've got an annual chore to do or your site goes
offline.

I think some hosts are already starting to offer free and easy SSL certs to
their small customers, but I do expect automated SSL management to be
generally available for the masses before this takes effect.

~~~
wolf550e
Can you describe the kind of person who hosts their own website but cannot
easily set up Let's Encrypt automatic renewal?

~~~
rkagerer
The whole "Let's Encrypt should solve all your problems" attitude is arrogant
and short-sighted.

1) In my experience the user experience even for technical admins is still
flakey on at least some popular platforms. In other words, it's not as
incredible as you think.

2) It's not available to a host that doesn't connect to the internet but does
occasionally get connected to by a local browser (eg. IoT firewalled inside my
LAN is one obvious such case; I'm sure there are others).

And most importantly:

3) You'd have to be insane or naive to accept an architecture that leaves you
dependant on a single vendor (especially if you need that vendor more than
they need you!).

~~~
yjftsjthsd-h
How fortunate, then, that LE isn't the only vendor. Not even the only ACME
vendor, nor the only free vendor
([https://zerossl.com/features/acme/](https://zerossl.com/features/acme/)).

------
Almad
Internet starts to have 1y memory retention.

Unless refreshed by active learning, aka someone doing the refresh job.

Or unless delegating the work to large players—either the memory or the
hosting.

EDIT: This feels wrong, even when done for right reasons. And I wonder whether
this would fly without LE and whether this means we are officially making LE
THE critical part of Internet infrastructure.

~~~
kspacewalk2
Websites marked "insecure" are still fully accessible.

~~~
cutler
Not always. Sometimes the browser presents a full-page response to the effect
that the site is dangerous at which point, even if it's a harmless site, the
non-savvy user will leave. Blanket HTTPS/SSL + Letsencrypt is a disaster.

~~~
judge2020
This only happens if the site used to be HTTPS and no longer has a certificate
or the site has long-lasting HSTS.

------
SquareWheel
To clarify, this is the limit for how long they can be to be considered valid.

Certificates are encouraged to be of shorter lengths as it reduces their
potential for abuse. If compromised, a certificate with a long lifespan could
be used for years without anyone noticing. A system which doesn't check for
revocation is especially vulnerable (though of course, browsers do).

Let's Encrypt certificates are only valid three months, which works well
because it's largely automated. It would be good to extend that philosophy
elsewhere: automation, and with shorter cycles.

Note the actual limit is 398 days, which gives a small buffer over 1 year.

~~~
slim
which makes websites ephemeral and at the mercy of a few authorities. my
torrent website could disappear within a few months behind a scary "this site
is dangerous" notice

~~~
lvh
What does that have to do with certificate lifespan? Authorities go after your
domain, not (typically) the CA. Longer certs don't help.

------
chucky_z
I’m so torn here. Personally I like this a lot and think it will really help
enforce good practices and allow easier things like root/int key rotation.
Professionally it sucks, as there are a ton of valid use cases for real certs
in areas that require manual work and tracking them all is a hard problem. If
internal PKIs were easier to make work across all OS and Browser combos I’d
just use those instead.

~~~
GordonS
> If internal PKIs were easier to make work across all OS and Browser combos
> I’d just use those instead

Even if you use your own PKI, if your certs have a validity > 1 year, won't
browsers still complain?

~~~
chucky_z
The fact that, as a user, I can't tell a browser "hey, this internal PKI that
you already don't trust, just go ahead and trust it no matter what because I
tell you to," feels bad.

------
maxmalysh
I don't like seeing how the SSL hurdle affects small read-only websites.

~~~
cutler
Agreed. Talk about sledgehammer to crack a nut. Typical sysadmin solution to a
problem assuming every Joe Blogger is going to setup his own VPS and fsck with
certbot.

~~~
detaro
Joe Blogger is not expected to setup a VPS, Joe Blogger is using shared
hosting or a blog-as-a-service, and thus leaves worrying about how to
implement HTTPS to someone else.

~~~
cutler
So the death of self-sufficient, independent Joe Blogger espcially if that
"someone else" is his hosting provider who doesn't handle Letsencrypt.

------
nieve
It's a positive for security, but unless you're going through Let's Encrypt it
adds another entity that you have to disclose PII to simply to host your own
blog or side project.

~~~
kspacewalk2
What are some valid reasons _not_ to use LetsEncrypt?

~~~
hedora
It’s extremely insecure if you’re worried about things beyond passive mass
surveillance.

If someone can intercept traffic to your server IP, they can get a Let’s
Encrypt certificate. If they can’t reliably man in the middle that IP, then
HTTP is reasonably secure already.

Such “certificates without certification” This is one reason browsers have
added new UI elements for certified domains.

~~~
niij
MITM'ing the connection between LE and a server is generally much more
difficult and targeted than between any client and the server. Two different
scenarios there.

------
KingMachiavelli
Good. I know too many places (large, established places) that could be using
ACME but currently just put up with manually replacing 2 year certificates
which means every 2 years the live certs are expired for at least half a day.

------
psim1
Help me understand why > 1 year server certs are problematic but issuers have
20 year roots. Isn’t the issuer’s cert a bigger concern?

~~~
profmonocle
Root certificates have their private keys in hardware security modules, which
are kept in safes in secure facilities, only brought online when needed to
sign intermediate certificates. Plus, it takes quite a while for new ones to
be widely trusted - Let's Encrypt's root cert was issued in 2015 and _still_
isn't trusted by a large percentage of older Android phones.

Intermediate certificates have shorter lifetimes. Even though they're kept
online, they're also stored in HSMs. Even if the CA were compromised, the
chance of the private key _itself_ leaking is very small.

End user certificates, on the other hand, are usually handled much more
cavalierly. Sure, you could store the key in an HSM, but most servers just
keep them in memory (and in the file system). A server certificate's key is
far, far more likely to be compromised than a CA key.

------
loeg
This is a tangent, and I apologize. Is there any good infrastructure for
creating self-signed TLS CA/host certificates these days for people who don't
sysadmin full time (grok OpenSSL)?

I would like to create a self-signed CA with a name-constraint for certain
internal (sub)domains, and have my browser trust the CA. And have it sign end-
host certificates. And have httpd use those certificates (or certificate
chains) such that the end result is a trusted HTTPS connection I don't have to
click-through Advanced every time.

Is there a collection of PKI software that makes this remotely easy to do?
OpenSSL objectively does not.

I have a good understanding of public and secret key cryptography as well as
hash functions and other primitives, but I don't understand any of how PKI
works — it's just crazy complicated for what it seems to do.

~~~
mrunkel
[https://github.com/redredgroovy/easy-
ca](https://github.com/redredgroovy/easy-ca)

Pretty easy to use.

Letsencrypt with DNS validator also works great for servers that aren’t
accessible externally.

------
tomklein
Why exactly 398 days? Seems a little bit odd as it’s approx 13 months plus
additional 2-3 days.

~~~
mrgalaxy
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.

~~~
tialaramex
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.

------
cm2187
Does it also apply to certs issued by a private/own CA or just public
certificates?

~~~
jlgaddis
_EDIT:_ Sorry, replied to the wrong comment!

\---

cf. [https://support.apple.com/en-us/HT211025](https://support.apple.com/en-
us/HT211025):

> _This change will affect only TLS server certificates issued from the Root
> CAs preinstalled with iOS, iPadOS, macOS, watchOS, and tvOS._

> _This change will not affect certificates issued from user-added or
> administrator-added Root CAs._

~~~
cm2187
But what about Chromium and Mozilla?

~~~
tialaramex
if (verify_result->is_issued_by_known_root && HasTooLongValidity(*cert)) {
verify_result->cert_status |= CERT_STATUS_VALIDITY_TOO_LONG;

Chromium's code (linked as the story) only applies these rules to certificates
from the Web PKI, not to a private CA.

Mozilla has no checks, I presume the story title names them because they've
agreed on this policy but they don't actually enforce policy in the browser
code itself.

Or at least they didn't when I asked them months ago about this topic.

~~~
GordonS
> verify_result->is_issued_by_known_root

Let's take Windows as an example, as it has a root certificate store. Now, if
I operate a private CA, I install my private root certificate to the root
certificate store - does that make it a "known_root" for Chromium, or does
this check only cover a specific set of known-to-Chromium CAs?

------
aloknnikhil
I can understand this can cause pain for existing deployments, but I don't see
any reason not to use something like Let's Encrypt to issue 90-day
certificates for new services/deployments. With certbot, renewals are
automatic and with something like Caddy, the certificates can be managed
across load balancers. I'm only talking about the web service here and not IoT
or any use case that makes this sort of frequent renewals difficult.

------
csours
> Enforce publicly trusted TLS server certificates have a lifetime of 398 days
> or less, if they are issued on or after 2020-09-01.

Fortunately not enforced for currently issued certs.

Will this ever be part of the TLS spec?

~~~
yjftsjthsd-h
> Will this ever be part of the TLS spec?

I'm pretty sure TLS itself doesn't specify anything about certificate
lifetimes. I could be wrong; I have actually read it, but as sibling comment
notes, TLS is used in a lot more places than browsers, including mutual TLS
between random services that don't use an external CA at all.

------
sqldba
It’s disgusting. It’s not up to them to decide how long a certificate should
be valid. Especially when they’re so expensive to buy and complicated to
replace.

~~~
gruez
>Especially when they’re so expensive to buy and complicated to replace.

Letsencrypt is free and easy to replace (it's automatic, and takes maybe 5
minutes to set up on a new server). EV certificates might be harder, but I've
heard good things about certsimple.

~~~
M2Ys4U
>EV certificates might be harder

EV certs are completely worthless (as in they provide no extra value above
that provided by regular DV certs) so nobody should care if they're harder to
obtain.

------
nottorp
Isn't this going from real security measures towards security theater?

~~~
Snawoot
It really is. Why do we should trust short-lived certs which might have been
issued under shady circumstances like BGP hijack hour ago? How shorter
validity terms protect against attack which takes days at most? Why they are
so sure rotated key will not be stolen as well if it was before? How they
ensure specific public/private pair were not already used before? Do they
actually check it?

This is a security theater and I think it's intended to make TLS maintenance
unbearable for non-IT businesses and to push them to cloud hosting providers
like Google Cloud and Cloudflare.

Also latest drafts of TLS ESNI/ECH feature were written by Cloudflare for
Cloudflare's needs.

------
jlushbough
how does this affect a private enterprise CA. assume that all clients trust
the internal CA infrastructure. will Chrome complain about internal
certificates longer than 398 days after the change?

------
BillinghamJ
I'd quite like to see this eventually getting to more like 1 month, maybe 7
days - forcing continuous automated issuance.

Ideally, something more like 1 hour - like a JWT - would be nice, but not
particularly practical as you need to allow some margin for incorrect local
clocks time

~~~
daneel_w
How would 1 hour be ideal? Have you considered the immense increase of
logistic costs and power consumption this would incur?

------
ethagnawl
This summary should emphasize that it's a 398 day _maximum_.

------
niksmac
Letsencrypt's default validity is for an year right? Is this not a game?

~~~
aloknnikhil
Let's Encrypt doesn't offer anything longer than 90 days.

[https://letsencrypt.org/2015/11/09/why-90-days.html](https://letsencrypt.org/2015/11/09/why-90-days.html)

------
joobus
I can see this policy being used for censorship in this age of cancel culture.
Don't virtue signal hard enough for the latest outrage mob? No cert for you.

~~~
vageli
> I can see this policy being used for censorship in this age of cancel
> culture. Don't virtue signal hard enough for the latest outrage mob? No cert
> for you.

How does that work with a largely automated process like Let's Encrypt?

~~~
cm2187
A couple of lines of code to enforce domain black lists if the relevant
activits apply enough pressure.

~~~
mschuster91
Why should anyone do this? It's way easier and more effective to put pressure
on hosters, anti-DDOS services and the payment providers to get Nazis booted
off the net, see e.g. Stormfront.

~~~
cm2187
It is easier to apply pressure when a single provider has a quasi monopoly,
which let's encrypt is quickly building up. And I am not suggesting these
attacks are mutually exclusive.

