4 ms·

A few of these things, while not necessarily wrong, should be put into context. E.g. "Hundreds of thousands of domains' certs expire after 2099". Yeah, but no

by hannob 7y ago

A few of these things, while not necessarily wrong, should be put into context. E.g. "Hundreds of thousands of domains' certs expire after 2099". Yeah, but no publicly trusted certs. They're capped at a bit more than 2 years and there's a discussion to cap them even more. The certs they're seeing are almost certainly mostly: "let's create a test selfsigned cert for this host. how long should it last? let's type in a large number so we aren't bothered by it any time soon."

tialaramex 7y ago
Yes, but... Historically there were some certs that kept getting grandfathered in after lifetimes were restricted because they'd been issued before there were any rules - maybe ten years to expire or even more? I think the last of those probably went away because of the Symantec distrust (not that they were issued by Symantec, but they were issued by a CA which was bought by a CA which in turn was bought by Symantec before it was distrusted) and also of course they'd have either MD5 or SHA-1 signatures, which are not accepted today anyway. There were still certs issued right up until the end of March 2018 with the old 39 month lifetime maximum. You can see them most easily in the annualised CT logs for 2021. A while back CT log operators realised that logs just get longer (of course) and so they would need to periodically make new ones and archive the old ones. Very quickly they struck upon the idea of annualising them, instead of running FooBar Log, run FooBar Log 2019, FooBar Log 2020 and FooBar Log 2021, and then require any submissions to use the log matching the year of expiry of the certificate they were logging. This way you can archive FooBar Log 2019 when people get back from holidays after celebrating New Year 2020, all the certs in that log are expired anyway now. I guess that today the last of those 39 month certs will actually expire before a brand new 825 day cert, but they are still out there, so don't write software that assumes leaf certs can't last more than 825 days just yet.
- quink 7y ago
  Minor point - SHA1 root CA certs are trusted by identity, so SHA1 is of no consequence.
- tikiman163 7y ago
  The old certificates aren't a huge concern moving forward because the new standards for trust libraries is requiring that all certificates not be trusted if the expiration is too far out. Chrome and most other browsers have already implemented these standards. The real concern is the percentage of people using browsers that are no longer supported and therefore do not implement on the new standards like Internet Explorer. Microst really needs to stop caving to pressure and get rid of these ancient applications like paint.exe and internet explorer. That or just make new applications and give them the same names.
zamadatix 7y ago
> Yeah, but no publicly trusted certs. > (Over 1.5M expire in the 2040s alone!) I doubt ~75% of the self signed certs expire in this dataset expire 21-30 years from now. Surely the author is correct that there are a good number of public certs with a very long expiration. Would need to download and filter the dataset to know for sure though.
- tialaramex 7y ago
  I doubt anybody has ever issued a "real" (Web PKI) leaf certificate (leaves are the edge of the tree, the certificates presented by TLS servers this work connected to) for 21 years let alone 30. Back in 2011 when the Baseline Requirements were first written, they set 60 months (5 years) as the upper limit, with the intent to further restrict to 39 months in a few years and that eventually happened in 2015 or so. Last year 39 months went down to 825 days and there's currently pressure to reduce it further in 2020. Note that it's not just self-signed certs you'd be considering, many of the certs in this dataset will be issued by a CA but not a public CA. Could be an internal CA (e.g. Windows Server provides software to run one, so does RHEL) or could even be one of the private-use-only CAs run by the same companies that operate public CAs. There were about half a million certs in that dataset issued by SomeOrganization with email address root@localhost.localdomain. Not technically self-signed, but obviously that's not a public CA.
  - Bombthecat 7y ago
    With raising automation of issuance for certificates (I might work soon on a project to add an api to issue certificatates) I don't see any reason to not go any lower. Like just a few days or weeks.
    - jlawer 7y ago
      That doesn't work if your running software supplied by a vendor that needs an SSL certificate. Often they have manual processes, that require shutting down the application and restarting, taking the service offline through the process. These applications are also frequently heavily firewalled to the internet so security risks are limited, but not with smaller operations, you might not have PKI infrastructure in place to manage your own root certs (especially in BYOD orgs). If a certificate rollover takes your application offline for an hour, your not going to want to do it every week.
judge2020 7y ago
> and there's a discussion to cap them even more. For reference: https://gist.github.com/ScottHelme/5531ed88b1ff0c1e8ce8af5654e462f9 https://gist.github.com/ScottHelme/5531ed88b1ff0c1e8ce8af565...

by hannob 7y ago

tialaramex 7y ago

Yes, but... Historically there were some certs that kept getting grandfathered in after lifetimes were restricted because they'd been issued before there were any rules - maybe ten years to expire or even more? I think the last of those probably went away because of the Symantec distrust (not that they were issued by Symantec, but they were issued by a CA which was bought by a CA which in turn was bought by Symantec before it was distrusted) and also of course they'd have either MD5 or SHA-1 signatures, which are not accepted today anyway. There were still certs issued right up until the end of March 2018 with the old 39 month lifetime maximum. You can see them most easily in the annualised CT logs for 2021. A while back CT log operators realised that logs just get longer (of course) and so they would need to periodically make new ones and archive the old ones. Very quickly they struck upon the idea of annualising them, instead of running FooBar Log, run FooBar Log 2019, FooBar Log 2020 and FooBar Log 2021, and then require any submissions to use the log matching the year of expiry of the certificate they were logging. This way you can archive FooBar Log 2019 when people get back from holidays after celebrating New Year 2020, all the certs in that log are expired anyway now. I guess that today the last of those 39 month certs will actually expire before a brand new 825 day cert, but they are still out there, so don't write software that assumes leaf certs can't last more than 825 days just yet.

quink 7y ago
Minor point - SHA1 root CA certs are trusted by identity, so SHA1 is of no consequence.
tikiman163 7y ago
The old certificates aren't a huge concern moving forward because the new standards for trust libraries is requiring that all certificates not be trusted if the expiration is too far out. Chrome and most other browsers have already implemented these standards. The real concern is the percentage of people using browsers that are no longer supported and therefore do not implement on the new standards like Internet Explorer. Microst really needs to stop caving to pressure and get rid of these ancient applications like paint.exe and internet explorer. That or just make new applications and give them the same names.

zamadatix 7y ago

> Yeah, but no publicly trusted certs. > (Over 1.5M expire in the 2040s alone!) I doubt ~75% of the self signed certs expire in this dataset expire 21-30 years from now. Surely the author is correct that there are a good number of public certs with a very long expiration. Would need to download and filter the dataset to know for sure though.

tialaramex 7y ago
I doubt anybody has ever issued a "real" (Web PKI) leaf certificate (leaves are the edge of the tree, the certificates presented by TLS servers this work connected to) for 21 years let alone 30. Back in 2011 when the Baseline Requirements were first written, they set 60 months (5 years) as the upper limit, with the intent to further restrict to 39 months in a few years and that eventually happened in 2015 or so. Last year 39 months went down to 825 days and there's currently pressure to reduce it further in 2020. Note that it's not just self-signed certs you'd be considering, many of the certs in this dataset will be issued by a CA but not a public CA. Could be an internal CA (e.g. Windows Server provides software to run one, so does RHEL) or could even be one of the private-use-only CAs run by the same companies that operate public CAs. There were about half a million certs in that dataset issued by SomeOrganization with email address root@localhost.localdomain. Not technically self-signed, but obviously that's not a public CA.
- Bombthecat 7y ago
  With raising automation of issuance for certificates (I might work soon on a project to add an api to issue certificatates) I don't see any reason to not go any lower. Like just a few days or weeks.
  - jlawer 7y ago
    That doesn't work if your running software supplied by a vendor that needs an SSL certificate. Often they have manual processes, that require shutting down the application and restarting, taking the service offline through the process. These applications are also frequently heavily firewalled to the internet so security risks are limited, but not with smaller operations, you might not have PKI infrastructure in place to manage your own root certs (especially in BYOD orgs). If a certificate rollover takes your application offline for an hour, your not going to want to do it every week.

judge2020 7y ago

> and there's a discussion to cap them even more. For reference: https://gist.github.com/ScottHelme/5531ed88b1ff0c1e8ce8af5654e462f9 https://gist.github.com/ScottHelme/5531ed88b1ff0c1e8ce8af565...