6 ms·

This is a desired outcome. The WebPKI ecosystem would really like it if everyone stopped depending on them for internal things because it's actually a pretty di

This is a desired outcome. The WebPKI ecosystem would really like it if everyone stopped depending on them for internal things because it's actually a pretty different set of requirements. Long-lived certs with an internal CA makes a lot of sense and is often more secure than using a public CA.

ozim 2y ago
Problem is browsers will most likely follow the enforcement of short certificates so internal sites will be affected as well. Non browser things usually don’t care even if cert is expired or trusted. So I expect people still to use WebPKI for internal sites.
- ryao 2y ago
  Why would they? The old certificates will expire and the new ones will have short lifespans. Web browsers do not need to do anything. That said, it would be really nice if they supported DANE so that websites do not need CAs.
- nickf 2y ago
  'Most likely' - with the exception of Apple enforcing 825-day maximum for private/internal CAs, this change isn't going to affect those internal certificates.
- akerl_ 2y ago
  The browser policies are set by the same entities doing the CAB voting, and basically every prior change around WebPKI has only been enforced by browsers for CAs in the browser root trust stores. Which is exactly what's defined in this CAB vote as well. Why would browsers "most likely" enforce this change for internal CAs as well?
rlpb 2y ago
Browsers don't design for internal use though. They insist on HTTPS for various things that are intranet only, such as some browser APIs, PWAs, etc
- akerl_ 2y ago
  As is already described by the comment thread we're replying in, "internal use" and "HTTPS" are very compatible. Corporations can run an internal CA, sign whatever internal certs they want, and trust that CA on their devices.
  - rlpb 2y ago
    Indeed they are compatible. However HTTPS is often unnecessary, particularly in a smaller organisation, but browsers mandate significant unnecessary complexity there. In that sense, brwosers are not suited to this use in those scenarios.
    - therealpygon 2y ago
      And it is even more trivial in a small organization to install a Trusted Root for internally signed certificates on their handful of machines. Laziness isn’t a browser issue.
      - rlpb 2y ago
        How is that supposed to work for an IoT device that wants to work out of the box using one of these HTTPS-only browser APIs?
        metanonsense 2y ago
        I am not saying I‘d do this, but in theory you could deploy a single reverse proxy in front of your HTTP-only devices and restrict traffic accordingly.
    - tedivm 2y ago
      I really don't see many scenarios where HTTPS isn't needed for at least some internal services.
      - donnachangstein 2y ago
christina97 2y ago
What do you mean “WebPKI … would like”. The browser vendors want one thing (secure, ubiquitous, etc), the CAs want a very different thing (expensive, confusing, etc)…
tetha 2y ago
Our internally provided certs of various CAs have a TTL of 72 hours and should be renewed every 48 hours. It's been a huge pain as we have encountered a ton of bugs and missing features in libraries and applications to reload certs like this. And we have some really ugly workarounds in place, because some applications place a "reload a consul client" on the same level of "reload all config, including opening new sockets, adjusting socket parameters, doing TCP connection handover" - all to rebuild a stateless client throwing a few parameters at a standard http client. But oh well. But I refuse to back down. Reload your certs and your secrets. If we encounter a situation in which we have to mass-revoke and mass-reissue internal certs, it'll be easy for those who do. I don't have time for everyone else.
- donnachangstein 2y ago
  > Our internally provided certs of various CAs have a TTL of 72 hours and should be renewed every 48 hours. Do you promise to come back and tell us the story about when someone went on vacation and the certs issued on a Thursday didn't renew over the weekend and come Monday everything broke and no one could authenticate or get into the building?
  - tetha 2y ago
    I will. We've been betting Postgres connectivity for a few hundred applications on this over the past three years. If this fucks up, it'll be known without me.
    - donnachangstein 2y ago
      I'm curious what requirement drove you to such arbitrarily small TTL, other than "because we can" dick-measuring geekery. I applaud you for sticking to your guns though.
      - tetha 2y ago
        At the end of the day, we were worried about exactly these issues - if an application has to reload certs once every 2 years, it will always end up a mess. And the conventional wisdom for application management and deployments is - if it's painful, do it more. Like this, applications in the container infrastructure are forced to get certificate deployment and reloading right on day 1. And yes, some older application that were migrated to the infrastructure went ahead and loaded their credentials and certificates for other dependencies into their database or something like that and then ended up confused when this didn't work at all. Now it's fixed.
Spooky23 2y ago
Desired by who? There’s nothing stopping Apple and Google from issuing themselves certificates every 10 minutes. I get no value for doing this. Building out or expanding my own PKI for my company or setting up the infrastructure to integrate with Digicert or whomever gets me zero security and business value, just cost and toil. Revocation is most often an issue when CAs fuck up. So now we collectively need to pay to cover their rears.
- crote 2y ago
  CAs fucking up every once in a while is inevitable. It is impossible to write guaranteed bug-free software or train guaranteed flawless humans. The big question is what happens when (not "if") that happens. Companies have repeatedly shown that they are unable to rotate certs in time, to the point of even suing CAs to avoid revocation. They've been asked nicely to get their shit together, and it hasn't happened. Shortening cert lifetime to force automation is the inevitable next step.
  - Spooky23 2y ago
    Silly me, I’m just a customer, incapable of making my own risk assessments or prioritizing my business processes. You’re portraying people suing CAs to get injunctions to avoid outages as clueless or irresponsible. The fact is Digicert’s actions, dictated by this CA/Browser forum were draconian and over the top responses to a minor risk. This industry trade group is out of control. End of the day, we’re just pushing risk around. Running a quality internal PKI is difficult.

ozim 2y ago

Problem is browsers will most likely follow the enforcement of short certificates so internal sites will be affected as well. Non browser things usually don’t care even if cert is expired or trusted. So I expect people still to use WebPKI for internal sites.

ryao 2y ago
Why would they? The old certificates will expire and the new ones will have short lifespans. Web browsers do not need to do anything. That said, it would be really nice if they supported DANE so that websites do not need CAs.
nickf 2y ago
'Most likely' - with the exception of Apple enforcing 825-day maximum for private/internal CAs, this change isn't going to affect those internal certificates.
akerl_ 2y ago
The browser policies are set by the same entities doing the CAB voting, and basically every prior change around WebPKI has only been enforced by browsers for CAs in the browser root trust stores. Which is exactly what's defined in this CAB vote as well. Why would browsers "most likely" enforce this change for internal CAs as well?

rlpb 2y ago

Browsers don't design for internal use though. They insist on HTTPS for various things that are intranet only, such as some browser APIs, PWAs, etc

akerl_ 2y ago
As is already described by the comment thread we're replying in, "internal use" and "HTTPS" are very compatible. Corporations can run an internal CA, sign whatever internal certs they want, and trust that CA on their devices.
- rlpb 2y ago
  Indeed they are compatible. However HTTPS is often unnecessary, particularly in a smaller organisation, but browsers mandate significant unnecessary complexity there. In that sense, brwosers are not suited to this use in those scenarios.
  - therealpygon 2y ago
    And it is even more trivial in a small organization to install a Trusted Root for internally signed certificates on their handful of machines. Laziness isn’t a browser issue.
    - rlpb 2y ago
      How is that supposed to work for an IoT device that wants to work out of the box using one of these HTTPS-only browser APIs?
      - metanonsense 2y ago
        I am not saying I‘d do this, but in theory you could deploy a single reverse proxy in front of your HTTP-only devices and restrict traffic accordingly.
  - tedivm 2y ago
    I really don't see many scenarios where HTTPS isn't needed for at least some internal services.
    - donnachangstein 2y ago

christina97 2y ago

What do you mean “WebPKI … would like”. The browser vendors want one thing (secure, ubiquitous, etc), the CAs want a very different thing (expensive, confusing, etc)…

tetha 2y ago

Our internally provided certs of various CAs have a TTL of 72 hours and should be renewed every 48 hours. It's been a huge pain as we have encountered a ton of bugs and missing features in libraries and applications to reload certs like this. And we have some really ugly workarounds in place, because some applications place a "reload a consul client" on the same level of "reload all config, including opening new sockets, adjusting socket parameters, doing TCP connection handover" - all to rebuild a stateless client throwing a few parameters at a standard http client. But oh well. But I refuse to back down. Reload your certs and your secrets. If we encounter a situation in which we have to mass-revoke and mass-reissue internal certs, it'll be easy for those who do. I don't have time for everyone else.

donnachangstein 2y ago
> Our internally provided certs of various CAs have a TTL of 72 hours and should be renewed every 48 hours. Do you promise to come back and tell us the story about when someone went on vacation and the certs issued on a Thursday didn't renew over the weekend and come Monday everything broke and no one could authenticate or get into the building?
- tetha 2y ago
  I will. We've been betting Postgres connectivity for a few hundred applications on this over the past three years. If this fucks up, it'll be known without me.
  - donnachangstein 2y ago
    I'm curious what requirement drove you to such arbitrarily small TTL, other than "because we can" dick-measuring geekery. I applaud you for sticking to your guns though.
    - tetha 2y ago
      At the end of the day, we were worried about exactly these issues - if an application has to reload certs once every 2 years, it will always end up a mess. And the conventional wisdom for application management and deployments is - if it's painful, do it more. Like this, applications in the container infrastructure are forced to get certificate deployment and reloading right on day 1. And yes, some older application that were migrated to the infrastructure went ahead and loaded their credentials and certificates for other dependencies into their database or something like that and then ended up confused when this didn't work at all. Now it's fixed.

Spooky23 2y ago

Desired by who? There’s nothing stopping Apple and Google from issuing themselves certificates every 10 minutes. I get no value for doing this. Building out or expanding my own PKI for my company or setting up the infrastructure to integrate with Digicert or whomever gets me zero security and business value, just cost and toil. Revocation is most often an issue when CAs fuck up. So now we collectively need to pay to cover their rears.

crote 2y ago
CAs fucking up every once in a while is inevitable. It is impossible to write guaranteed bug-free software or train guaranteed flawless humans. The big question is what happens when (not "if") that happens. Companies have repeatedly shown that they are unable to rotate certs in time, to the point of even suing CAs to avoid revocation. They've been asked nicely to get their shit together, and it hasn't happened. Shortening cert lifetime to force automation is the inevitable next step.
- Spooky23 2y ago
  Silly me, I’m just a customer, incapable of making my own risk assessments or prioritizing my business processes. You’re portraying people suing CAs to get injunctions to avoid outages as clueless or irresponsible. The fact is Digicert’s actions, dictated by this CA/Browser forum were draconian and over the top responses to a minor risk. This industry trade group is out of control. End of the day, we’re just pushing risk around. Running a quality internal PKI is difficult.