17 ms·

Chromium and Mozilla to enforce 1 year validity for TLS certificates

203 points by vld 6y ago

tomklein 6y ago
Why exactly 398 days? Seems a little bit odd as it’s approx 13 months plus additional 2-3 days.
- mrgalaxy 6y ago
  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.
  - phantom784 6y ago
    366 (days in a leap year) + 31 (longest month) = 397. So it's exactly one more than that.
  - tialaramex 6y ago
    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.
- noir_lord 6y ago
  12 mths plus 30 days to pay maybe?
- floatingatoll 6y ago
  > 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. https://sslretail.com/news/ssl-validity-limiting-to-one-year-grab-yours-before-price-hike/ https://sslretail.com/news/ssl-validity-limiting-to-one-year...
  - jwilk 6y ago
    Why 13 months though?
    - est31 6y ago
      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.
    - floatingatoll 6y ago
      Because it's 1 year + 1 month + 1 day. 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".
- deleted 6y ago
  [deleted]
chucky_z 6y ago
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.
- zozbot234 6y ago
  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.
  - lawnchair_larry 6y ago
    TOFU doesn’t actually work. If you set up a TOFU cert environment, 100% of non-security people will click right through it, and 95% of security people will also click right through it. They’ll just assume that because it was untrusted the first time, that cert errors are normal and ignore it. Especially since they will have a “first use” for every new device and every new browser they visit with.
    - zozbot234 6y ago
      Funny how some people claim no one will ever click thru the TOFU warning screen because it's too scary and unfamiliar, whilst others say users will just click thru everything.
      - lawnchair_larry 6y ago
        There’s an important distinction. My claim is that once a user is trained how to ignore a cert error for a particular site and add an exception, they will no longer pay any mind to that site or environment giving cert errors. The general public, when surfing and hitting a cert error on a random site, will usually disengage.
floatingatoll 6y ago
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-certificates/ https://cabforum.org/2017/02/24/ballot-185-limiting-lifetime... https://archive.cabforum.org/pipermail/servercert-wg/2019-September/ https://archive.cabforum.org/pipermail/servercert-wg/2019-Se... https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107 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.
- altfredd 6y ago
  Sounds like CAs will be forced to keep shrinking cert length until everyone standardizes on 1 month. They no longer have any real power.
  - floatingatoll 6y ago
    A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.
markstos 6y ago
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 6y ago
  Can you describe the kind of person who hosts their own website but cannot easily set up Let's Encrypt automatic renewal?
  - raverbashing 6y ago
    Shared hosting Unless they set up LtE for their customers (And as much as I like LtE I think it's complicate to depend in one issuer only)
    - DiederikvandenB 6y ago
      Semaphor asks "can you describe the kind of person". Since when is "shared hosting" a person? People who know how to set up a website on a shared hosting platform probably also know how to renew a LE certificate, I think.
  - maxmalysh 6y ago
    http://www.paulgraham.com/ http://www.paulgraham.com/
    - brian-bk 6y ago
      There's no cert because there's no need for one in the first place. Mentioning that is pretty silly - it's obvious that there's nothing wrong with a static site with now cert, and no one is arguing against that.
reaperhulk 6y ago
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-certificate-lifetimes-v2/ 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.
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]
SquareWheel 6y ago
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.
- joobus 6y ago
  > it reduces their potential for abuse. 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.
  - ceejayoz 6y ago
    A world-class chef may have nicked their fingers more times than I have with a knife, but I suspect their food is still better than mine.
  - SquareWheel 6y ago
    You're right that more attempts means more chances at failure, but I don't think it's a 1-to-1 relationship. It's when I don't perform a task for a few years that I tend to make mistakes. Even if it's not an automated process (which I think this encourages), then it's easier to keep your skills sharpened by doing something more often. Would Mozilla have accidentally forgotten to renew their browser certificate recently if it were a more frequent task? It's hard to say, but I think it's likely there'd be a stronger procedure in place. There would need to be.
  - reidacdc 6y ago
    There's a countervailing effect where the more often you do something, the better you get at it. You're right that the absolute number of errors will certainly rise, but the fraction of attempts which have errors will likely fall. As legacy certs expire, the aggregate quality of certs will likely be higher. A secondary question is whether the gain in security is worth the required effort. Obviously Apple believes this, and LetsEncrypt is pretty easy, so even for hobbyists, it's probably at worst an annoyance.
BillinghamJ 6y ago
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 6y ago
  How would 1 hour be ideal? Have you considered the immense increase of logistic costs and power consumption this would incur?
- patmorgan23 6y ago
  Ok I'm in favor of shorter cert times but one hour is ridiculous. If you need a key pair for that amount of time generate an ephemeral one! The cert can be valid for months and still be secure.
- tgsovlerkhgsel 6y ago
  OCSP stapling may be what you're looking for. The certificate stays the same, but an additional short-lived signature indicating that it wasn't revoked yet is attached. Aside from not spamming the CT log and possibly making it easier to offload the generation of the OCSP responses to a more efficient architecture than the one needed to issue certificates, I'm not sure how mandatory OCSP stapling is better than just reissuing the certificate every day/week.
csours 6y ago
> 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?
- znpy 6y ago
  hopefully not. there is a huuuuge number of services that are not http based that use tls and certificates.
- yjftsjthsd-h 6y ago
  > 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.
est31 6y ago
From the source code: https://chromium.googlesource.com/chromium/src/+/ae4d6809912f8171b23f6aa43c6a4e8e627de784/net/cert/cert_verify_proc.cc#957 https://chromium.googlesource.com/chromium/src/+/ae4d6809912... // 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 6y ago
  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_40_certificate_transparency_logging_is_now_mandatory https://www.feistyduck.com/bulletproof-tls-newsletter/issue_...
  - tialaramex 6y ago
    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).
Almad 6y ago
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 6y ago
  Websites marked "insecure" are still fully accessible.
  - cutler 6y ago
    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 6y ago
      This only happens if the site used to be HTTPS and no longer has a certificate or the site has long-lasting HSTS.
  - Almad 6y ago
    Not always. You may also end up with having incompatible set of ciphers (happened to me). "Get off my Internet lawn if you can't be up to date" is what we're saying and I just do wonder whether we haven't exchanged too much of accessibility for too little of security.
- comex 6y ago
  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.
joobus 6y ago
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 6y ago
  > 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 6y ago
    A couple of lines of code to enforce domain black lists if the relevant activits apply enough pressure.
    - mschuster91 6y ago
      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 6y ago
        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.
      - lawnchair_larry 6y ago
        Nobody is talking about Nazis. And all of those things are not easier, especially if the site is self-hosted. His point is that it’s one more gatekeeper and point of failure. It doesn’t matter that there are existing means to target websites. Adding another makes freedom even more fragile. It’s very naive to assume that censorship is only a problem for Nazis that the world shouldn’t listen to anyway.
maxmalysh 6y ago
I don't like seeing how the SSL hurdle affects small read-only websites.
- cutler 6y ago
  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 6y ago
    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 6y ago
      So the death of self-sufficient, independent Joe Blogger espcially if that "someone else" is his hosting provider who doesn't handle Letsencrypt.
      - deleted 6y ago
        [deleted]
  - yjftsjthsd-h 6y ago
    If Joe Blogger can setup LAMP, he can setup ACME. If Joe can't setup LAMP, Joe will use a web host that does all of it for him including HTTPS. If Joe picked a host that's incapable of securing sites, Joe needs to switch to any of the dozens (if not hundreds) of competitors that can get this right.
nieve 6y ago
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 6y ago
  What are some valid reasons not to use LetsEncrypt?
  - lixtra 6y ago
    If Letsencrypt was the only CA left I would call it a big failure. Without a choice there cannot be trust.
    - mschuster91 6y ago
      LE is open standard, any CA can decide to implement it.
      - sschueller 6y ago
        The only other CA I know that has this service available is https://www.buypass.com/ssl/products/acme https://www.buypass.com/ssl/products/acme
        patmorgan23 6y ago
        https://en.m.wikipedia.org/wiki/Automated_Certificate_Management_Environment#:~:text=The%20Automatic%20Certificate%20Management%20Environment,infrastructure%20at%20very%20low%20cost https://en.m.wikipedia.org/wiki/Automated_Certificate_Manage.... According to Wikipedia there's several large CA's that already support ACME
        yjftsjthsd-h 6y ago
        https://zerossl.com/features/acme/ https://zerossl.com/features/acme/ Free, even.
ethagnawl 6y ago
This summary should emphasize that it's a 398 day _maximum_.
cm2187 6y ago
Does it also apply to certs issued by a private/own CA or just public certificates?
- jlgaddis 6y ago
  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 6y ago
    But what about Chromium and Mozilla?
    - lvh 6y ago
      Generally speaking locally installed certs have been exempted from most of the requirements levied on public certificates.
    - tialaramex 6y ago
      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 6y ago
        > 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?
paledot 6y ago
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.
- dharmab 6y ago
  Buy a domain, create a subdomain for local use, and issue ACME certs with Let's Encrypt every 60 days. If your vendor device or software doesn't support automated certificate rotation, put nginx/haproxy/envoy in front of it.
  - xg15 6y ago
    Without buying a domain. (and continously spending money to keep it owned)
    - dharmab 6y ago
      Run your own CA internally and handle the CA distribution problem with MDM tools.
      - lawnchair_larry 6y ago
        That is also an insane and unrealistic suggestion.
      - xg15 6y ago
        I admit, that's a solution, even if a very unpleasant one: Installing a custom root CA is intentionally complicated, so this is hardly doable as an onboarding experience. The setup must be repreated for every single client device that should access the server. There remains the question how I would get the CA certificate onto client devices in the first place. Lastly, with asking consumers to install a CA certificate, I ask for a significantly more powerful permission than if I could just have them trust my certificate. This seems like a step backwards security-wise.
psim1 6y ago
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?
- mschuster91 6y ago
  It is, people got screwed with AddTrust in the last weeks en masse, and there is a boatload of root certs expiring in the next ten years.
- profmonocle 6y ago
  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.
greatgib 6y ago
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 6y ago
  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 6y ago
    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.
- hannob 6y ago
  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!
KingMachiavelli 6y ago
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.
niksmac 6y ago
Letsencrypt's default validity is for an year right? Is this not a game?
- aloknnikhil 6y ago
  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
- nickodell 6y ago
  It's 90 days, and they renew it when there are 30 days left.
sqldba 6y ago
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 6y ago
  >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.
  - BillinghamJ 6y ago
    Sadly CertSimple just disappeared all of a sudden. Not much real use for EV certs though - the only thing they can be a little helpful for is if you want to do cert-pinning at the CA-level
  - M2Ys4U 6y ago
    >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.
- tgsovlerkhgsel 6y ago
  For most people, they can be free, and replace themselves, thanks to Let's Encrypt and their automation tools.
aloknnikhil 6y ago
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.
loeg 6y ago
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 6y ago
  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.
- skrause 6y ago
  XCA is reasonably easy to use, it's open-source and cross-platform: https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/
nottorp 6y ago
Isn't this going from real security measures towards security theater?
- Snawoot 6y ago
  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 6y ago
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?

203 points by vld 6y ago

tomklein 6y ago

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

mrgalaxy 6y ago
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.
- phantom784 6y ago
  366 (days in a leap year) + 31 (longest month) = 397. So it's exactly one more than that.
- tialaramex 6y ago
  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.
noir_lord 6y ago
12 mths plus 30 days to pay maybe?
floatingatoll 6y ago
> 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. https://sslretail.com/news/ssl-validity-limiting-to-one-year-grab-yours-before-price-hike/ https://sslretail.com/news/ssl-validity-limiting-to-one-year...
- jwilk 6y ago
  Why 13 months though?
  - est31 6y ago
    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.
  - floatingatoll 6y ago
    Because it's 1 year + 1 month + 1 day. 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".
deleted 6y ago
[deleted]

chucky_z 6y ago

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.

zozbot234 6y ago
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.
- lawnchair_larry 6y ago
  TOFU doesn’t actually work. If you set up a TOFU cert environment, 100% of non-security people will click right through it, and 95% of security people will also click right through it. They’ll just assume that because it was untrusted the first time, that cert errors are normal and ignore it. Especially since they will have a “first use” for every new device and every new browser they visit with.
  - zozbot234 6y ago
    Funny how some people claim no one will ever click thru the TOFU warning screen because it's too scary and unfamiliar, whilst others say users will just click thru everything.
    - lawnchair_larry 6y ago
      There’s an important distinction. My claim is that once a user is trained how to ignore a cert error for a particular site and add an exception, they will no longer pay any mind to that site or environment giving cert errors. The general public, when surfing and hitting a cert error on a random site, will usually disengage.

floatingatoll 6y ago

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-certificates/ https://cabforum.org/2017/02/24/ballot-185-limiting-lifetime... https://archive.cabforum.org/pipermail/servercert-wg/2019-September/ https://archive.cabforum.org/pipermail/servercert-wg/2019-Se... https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107 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.

altfredd 6y ago
Sounds like CAs will be forced to keep shrinking cert length until everyone standardizes on 1 month. They no longer have any real power.
- floatingatoll 6y ago
  A less labor-intensive approach would be require CAs to revalidate the 'proof of ownership' basis of issued certificates monthly, and publish a revocation via CRL if the validation times out or fails for 1 month + 1 day. This would further encourage automation of the ecosystem without requiring redeployment in the cases where automated verification passes each month.

markstos 6y ago

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 6y ago
Can you describe the kind of person who hosts their own website but cannot easily set up Let's Encrypt automatic renewal?
- raverbashing 6y ago
  Shared hosting Unless they set up LtE for their customers (And as much as I like LtE I think it's complicate to depend in one issuer only)
  - DiederikvandenB 6y ago
    Semaphor asks "can you describe the kind of person". Since when is "shared hosting" a person? People who know how to set up a website on a shared hosting platform probably also know how to renew a LE certificate, I think.
- maxmalysh 6y ago
  http://www.paulgraham.com/ http://www.paulgraham.com/
  - brian-bk 6y ago
    There's no cert because there's no need for one in the first place. Mentioning that is pretty silly - it's obvious that there's nothing wrong with a static site with now cert, and no one is arguing against that.

reaperhulk 6y ago

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-certificate-lifetimes-v2/ 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.

deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

SquareWheel 6y ago

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.

joobus 6y ago
> it reduces their potential for abuse. 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.
- ceejayoz 6y ago
  A world-class chef may have nicked their fingers more times than I have with a knife, but I suspect their food is still better than mine.
- SquareWheel 6y ago
  You're right that more attempts means more chances at failure, but I don't think it's a 1-to-1 relationship. It's when I don't perform a task for a few years that I tend to make mistakes. Even if it's not an automated process (which I think this encourages), then it's easier to keep your skills sharpened by doing something more often. Would Mozilla have accidentally forgotten to renew their browser certificate recently if it were a more frequent task? It's hard to say, but I think it's likely there'd be a stronger procedure in place. There would need to be.
- reidacdc 6y ago
  There's a countervailing effect where the more often you do something, the better you get at it. You're right that the absolute number of errors will certainly rise, but the fraction of attempts which have errors will likely fall. As legacy certs expire, the aggregate quality of certs will likely be higher. A secondary question is whether the gain in security is worth the required effort. Obviously Apple believes this, and LetsEncrypt is pretty easy, so even for hobbyists, it's probably at worst an annoyance.

BillinghamJ 6y ago

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 6y ago
How would 1 hour be ideal? Have you considered the immense increase of logistic costs and power consumption this would incur?
patmorgan23 6y ago
Ok I'm in favor of shorter cert times but one hour is ridiculous. If you need a key pair for that amount of time generate an ephemeral one! The cert can be valid for months and still be secure.
tgsovlerkhgsel 6y ago
OCSP stapling may be what you're looking for. The certificate stays the same, but an additional short-lived signature indicating that it wasn't revoked yet is attached. Aside from not spamming the CT log and possibly making it easier to offload the generation of the OCSP responses to a more efficient architecture than the one needed to issue certificates, I'm not sure how mandatory OCSP stapling is better than just reissuing the certificate every day/week.

csours 6y ago

> 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?

znpy 6y ago
hopefully not. there is a huuuuge number of services that are not http based that use tls and certificates.
yjftsjthsd-h 6y ago
> 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.

est31 6y ago

From the source code: https://chromium.googlesource.com/chromium/src/+/ae4d6809912f8171b23f6aa43c6a4e8e627de784/net/cert/cert_verify_proc.cc#957 https://chromium.googlesource.com/chromium/src/+/ae4d6809912... // 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 6y ago
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_40_certificate_transparency_logging_is_now_mandatory https://www.feistyduck.com/bulletproof-tls-newsletter/issue_...
- tialaramex 6y ago
  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).

Almad 6y ago

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 6y ago
Websites marked "insecure" are still fully accessible.
- cutler 6y ago
  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 6y ago
    This only happens if the site used to be HTTPS and no longer has a certificate or the site has long-lasting HSTS.
- Almad 6y ago
  Not always. You may also end up with having incompatible set of ciphers (happened to me). "Get off my Internet lawn if you can't be up to date" is what we're saying and I just do wonder whether we haven't exchanged too much of accessibility for too little of security.
comex 6y ago
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.

joobus 6y ago

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 6y ago
> 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 6y ago
  A couple of lines of code to enforce domain black lists if the relevant activits apply enough pressure.
  - mschuster91 6y ago
    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 6y ago
      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.
    - lawnchair_larry 6y ago
      Nobody is talking about Nazis. And all of those things are not easier, especially if the site is self-hosted. His point is that it’s one more gatekeeper and point of failure. It doesn’t matter that there are existing means to target websites. Adding another makes freedom even more fragile. It’s very naive to assume that censorship is only a problem for Nazis that the world shouldn’t listen to anyway.

maxmalysh 6y ago

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

cutler 6y ago
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 6y ago
  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 6y ago
    So the death of self-sufficient, independent Joe Blogger espcially if that "someone else" is his hosting provider who doesn't handle Letsencrypt.
    - deleted 6y ago
      [deleted]
- yjftsjthsd-h 6y ago
  If Joe Blogger can setup LAMP, he can setup ACME. If Joe can't setup LAMP, Joe will use a web host that does all of it for him including HTTPS. If Joe picked a host that's incapable of securing sites, Joe needs to switch to any of the dozens (if not hundreds) of competitors that can get this right.

nieve 6y ago

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 6y ago
What are some valid reasons not to use LetsEncrypt?
- lixtra 6y ago
  If Letsencrypt was the only CA left I would call it a big failure. Without a choice there cannot be trust.
  - mschuster91 6y ago
    LE is open standard, any CA can decide to implement it.
    - sschueller 6y ago
      The only other CA I know that has this service available is https://www.buypass.com/ssl/products/acme https://www.buypass.com/ssl/products/acme
      - patmorgan23 6y ago
        https://en.m.wikipedia.org/wiki/Automated_Certificate_Management_Environment#:~:text=The%20Automatic%20Certificate%20Management%20Environment,infrastructure%20at%20very%20low%20cost https://en.m.wikipedia.org/wiki/Automated_Certificate_Manage.... According to Wikipedia there's several large CA's that already support ACME
      - yjftsjthsd-h 6y ago
        https://zerossl.com/features/acme/ https://zerossl.com/features/acme/ Free, even.

ethagnawl 6y ago

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

cm2187 6y ago

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

jlgaddis 6y ago
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 6y ago
  But what about Chromium and Mozilla?
  - lvh 6y ago
    Generally speaking locally installed certs have been exempted from most of the requirements levied on public certificates.
  - tialaramex 6y ago
    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 6y ago
      > 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?

paledot 6y ago

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.

dharmab 6y ago
Buy a domain, create a subdomain for local use, and issue ACME certs with Let's Encrypt every 60 days. If your vendor device or software doesn't support automated certificate rotation, put nginx/haproxy/envoy in front of it.
- xg15 6y ago
  Without buying a domain. (and continously spending money to keep it owned)
  - dharmab 6y ago
    Run your own CA internally and handle the CA distribution problem with MDM tools.
    - lawnchair_larry 6y ago
      That is also an insane and unrealistic suggestion.
    - xg15 6y ago
      I admit, that's a solution, even if a very unpleasant one: Installing a custom root CA is intentionally complicated, so this is hardly doable as an onboarding experience. The setup must be repreated for every single client device that should access the server. There remains the question how I would get the CA certificate onto client devices in the first place. Lastly, with asking consumers to install a CA certificate, I ask for a significantly more powerful permission than if I could just have them trust my certificate. This seems like a step backwards security-wise.

psim1 6y ago

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?

mschuster91 6y ago
It is, people got screwed with AddTrust in the last weeks en masse, and there is a boatload of root certs expiring in the next ten years.
profmonocle 6y ago
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.

greatgib 6y ago

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 6y ago
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 6y ago
  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.
hannob 6y ago
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!

KingMachiavelli 6y ago

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.

niksmac 6y ago

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

aloknnikhil 6y ago
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
nickodell 6y ago
It's 90 days, and they renew it when there are 30 days left.

sqldba 6y ago

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 6y ago
>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.
- BillinghamJ 6y ago
  Sadly CertSimple just disappeared all of a sudden. Not much real use for EV certs though - the only thing they can be a little helpful for is if you want to do cert-pinning at the CA-level
- M2Ys4U 6y ago
  >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.
tgsovlerkhgsel 6y ago
For most people, they can be free, and replace themselves, thanks to Let's Encrypt and their automation tools.

aloknnikhil 6y ago

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.

loeg 6y ago

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 6y ago
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.
skrause 6y ago
XCA is reasonably easy to use, it's open-source and cross-platform: https://hohnstaedt.de/xca/ https://hohnstaedt.de/xca/

nottorp 6y ago

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

Snawoot 6y ago
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 6y ago

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?