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.
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.
> 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.
Nit: It's CA/B Forum (Certificate Authority / Browser Forum, a standing meeting between the major browser vendors - which are also roughly the set of major OS vendors except Mozilla stands in for the Free Unixes - and the major publicly trusted Certificate Authorities). The original purpose of this meeting was to find common ground between these two groups and this has borne considerable fruit over the years in the from of the Baseline Requirements.
CCADB is a totally different service run by Mozilla and Microsoft (using Salesforce, I presume because they both agree this is terrible but neither can accuse the other of using their preferred pet technologies?) notionally open to other trust stores to track lots of tedious paperwork for the relationship with trusted CAs. Audit documents, huge lists of what was issued by who and to do what, when it expires, blah blah blah. Like a public records office it's simultaneously fascinating and a total snooze fest. Mozilla is using it in this case to conduct their routine survey of CAs to check they understand what they're obliged to do, they're not asleep at the wheel and so on.
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
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.
CA/B isn't a cartel, indeed it jumps through a bunch of hoops to ensure it isn't a cartel. Cartels are illegal in many countries (the one you're most likely thinking of right now, OPEC, doesn't need to care that cartels are illegal because its members are sovereign entities, and thus they decide what the law is)
Moreover, this didn't come from CA/B anyway, it was rejected there. CA/B agreed the previous 825 day limit, and the 39 month limit before that, but this new rule did not get support at CA/B so Apple imposed it unilaterally (and with some really poor communication but whatever).
Google and Mozilla have just decided that since they wanted this limit, and Apple has effectively imposed it anyway, they might as well go along for the ride.
>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
People can barely tell whether it's really microsoft calling them saying their computer is infected. What makes you think they'll be able to tell the difference between google.com and google-secure-login.com, or whether they should download the "codec pack" that their shady streaming site is offering?
Corporations think they have to protect people from themselves now because people are now required, even encouraged, to blindly run all remote code they're sent. It's because browsers have become the OS. And now it's standard to metaphorically open every email attachment you receive.
> 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.
That sounds like a disagreement; it benefits the user, so let the website opt out? Because websites are known to have users' well-being in mind?
“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.”
I would think the choice on how long to trust a certificate should be on the user, possibly using the hint that the creator of the certificate gave. You wouldn’t trust a certificate from evil-empire.com, no matter its expiration date, would you?
The discussion should be about whether the browser should make that decision on behalf of the user. I’m not sure I’m in favor of that. On the other hand, browsers already do a lot in that domain, for example by their choice of trusted root certificates (and changes to that list)
No, I don't. Browsers have always controlled the internet since the web became the dominant way the internet is used. And I'm really quite happy for them to do this because lord only knows helping my various relatives with their computers has proven to me that someone needs too.
Yeah those good old times when Comodo was hacked and issued certificates for gmail.com and nobody really cared. Or when some shady CAs sold intermediate certificates in devices so you could man in the middle all your network connections (and everyone else's, too).
So bad those times are over and we have this browser cartell enforcing some basic security standards for TLS. Screw them!
// 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.
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.
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.
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.
On the contrary… LE is unaffected by this, since from the beginning it has enforced a much shorter certificate expiry time: 90 days. Which effectively forces you to set up automated renewals. Doing that does not require the help of "large players"; you stick certbot or another tool in your crontab, or use something like Caddy or Apache mod_md to have your web server do it by itself.
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.
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
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.
TOFU is a viable alternative for "long-living" certs, too. The very fact that the cert has longer validity makes it somewhat easier to trust it directly in the client.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
>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.
[+] [-] paledot|5 years ago|reply
[+] [-] floatingatoll|5 years ago|reply
https://cabforum.org/2017/02/24/ballot-185-limiting-lifetime...
https://archive.cabforum.org/pipermail/servercert-wg/2019-Se...
https://ccadb-public.secure.force.com/mozillacommunications/...
> 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.
[+] [-] tialaramex|5 years ago|reply
CCADB is a totally different service run by Mozilla and Microsoft (using Salesforce, I presume because they both agree this is terrible but neither can accuse the other of using their preferred pet technologies?) notionally open to other trust stores to track lots of tedious paperwork for the relationship with trusted CAs. Audit documents, huge lists of what was issued by who and to do what, when it expires, blah blah blah. Like a public records office it's simultaneously fascinating and a total snooze fest. Mozilla is using it in this case to conduct their routine survey of CAs to check they understand what they're obliged to do, they're not asleep at the wheel and so on.
[+] [-] altfredd|5 years ago|reply
[+] [-] greatgib|5 years ago|reply
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|5 years ago|reply
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.
[+] [-] tialaramex|5 years ago|reply
Moreover, this didn't come from CA/B anyway, it was rejected there. CA/B agreed the previous 825 day limit, and the 39 month limit before that, but this new rule did not get support at CA/B so Apple imposed it unilaterally (and with some really poor communication but whatever).
Google and Mozilla have just decided that since they wanted this limit, and Apple has effectively imposed it anyway, they might as well go along for the ride.
[+] [-] gruez|5 years ago|reply
People can barely tell whether it's really microsoft calling them saying their computer is infected. What makes you think they'll be able to tell the difference between google.com and google-secure-login.com, or whether they should download the "codec pack" that their shady streaming site is offering?
[+] [-] superkuh|5 years ago|reply
[+] [-] yjftsjthsd-h|5 years ago|reply
That sounds like a disagreement; it benefits the user, so let the website opt out? Because websites are known to have users' well-being in mind?
[+] [-] Someone|5 years ago|reply
I would think the choice on how long to trust a certificate should be on the user, possibly using the hint that the creator of the certificate gave. You wouldn’t trust a certificate from evil-empire.com, no matter its expiration date, would you?
The discussion should be about whether the browser should make that decision on behalf of the user. I’m not sure I’m in favor of that. On the other hand, browsers already do a lot in that domain, for example by their choice of trusted root certificates (and changes to that list)
[+] [-] Apofis|5 years ago|reply
[+] [-] dageshi|5 years ago|reply
[+] [-] hannob|5 years ago|reply
So bad those times are over and we have this browser cartell enforcing some basic security standards for TLS. Screw them!
[+] [-] est31|5 years ago|reply
https://chromium.googlesource.com/chromium/src/+/ae4d6809912...
The source code also requires certificates issued before 1 July 2012 to expire on Jul 1st, 2019 at the latest.[+] [-] dane-pgp|5 years ago|reply
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_...
[+] [-] reaperhulk|5 years ago|reply
The CABF has talked about doing this before, most recently in SC22 (https://cabforum.org/2019/09/10/ballot-sc22-reduce-certifica...). In that case all browsers supported it, but it wasn't passed by the CA side.
[+] [-] markstos|5 years ago|reply
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.
[+] [-] Almad|5 years ago|reply
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|5 years ago|reply
[+] [-] comex|5 years ago|reply
[+] [-] SquareWheel|5 years ago|reply
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|5 years ago|reply
[+] [-] joobus|5 years ago|reply
It will also increase the number of errors. The more times a thing is done increases the total number of errors occurring doing that thing.
[+] [-] chucky_z|5 years ago|reply
[+] [-] GordonS|5 years ago|reply
Even if you use your own PKI, if your certs have a validity > 1 year, won't browsers still complain?
[+] [-] zozbot234|5 years ago|reply
[+] [-] maxmalysh|5 years ago|reply
[+] [-] cutler|5 years ago|reply
[+] [-] nieve|5 years ago|reply
[+] [-] KingMachiavelli|5 years ago|reply
[+] [-] psim1|5 years ago|reply
[+] [-] loeg|5 years ago|reply
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|5 years ago|reply
Pretty easy to use.
Letsencrypt with DNS validator also works great for servers that aren’t accessible externally.
[+] [-] skrause|5 years ago|reply
[+] [-] tomklein|5 years ago|reply
[+] [-] floatingatoll|5 years ago|reply
https://sslretail.com/news/ssl-validity-limiting-to-one-year...
[+] [-] mrgalaxy|5 years ago|reply
Totally speculating here that 30 days is probably the earliest one can renew a yearly cert.
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] noir_lord|5 years ago|reply
[+] [-] cm2187|5 years ago|reply
[+] [-] jlgaddis|5 years ago|reply
---
cf. 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.
[+] [-] aloknnikhil|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] csours|5 years ago|reply
Fortunately not enforced for currently issued certs.
Will this ever be part of the TLS spec?
[+] [-] yjftsjthsd-h|5 years ago|reply
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.
[+] [-] znpy|5 years ago|reply
[+] [-] sqldba|5 years ago|reply
[+] [-] gruez|5 years ago|reply
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.
[+] [-] tgsovlerkhgsel|5 years ago|reply