3 ms·

I see way too many comments here that are basically saying "Why aren't these thousands of contracted orgs able to drop everything at the drop of a hat to update

I see way too many comments here that are basically saying "Why aren't these thousands of contracted orgs able to drop everything at the drop of a hat to update their DNS." Here is my understanding of the issue: 1. Alegeus creates white-labeled sites for their customers, but those sites are hosted on customer domains (usually for ease of sharing login cookies across subdomains on the customer), e.g. alegeus.customerdomain.com. 2. So the issue isn't necessarily that Alegeus can't update their systems, it's that their many customers can't update their DNS records fast enough to point to the new certs. IMO, if you built a system (and I'm talking about DigiCert here) that expects thousands of customers can update everything at the drop of a hat to update their code, you built a bad system. I don't think it's too different from CrowdStrike, except it's as if CrowdStrike gave 24 hours notice instead, saying "Hey, all of our customers, just a heads up we're going to break all your machines in 24 hours, you really should have planned better if you can't handle that." Alegeus is the one suing here because they've got tons of customers, but make no mistake this would cause outtages for tons of other companies that use DigiCert.

Hizonner 2y ago
Um, what are you talking about? Unless you use DANE (which nobody does, and the browsers don't check it even if they did), you do not have to change any DNS records, or touch the DNS at all, to update a certificate. There is no DNS involvement. Period. DANE should be the norm, but it's not.
- hn_throwaway_99 2y ago
  Perhaps I am misunderstanding what needs to happen, but since Alegeus itself doesn't control the domains on which its sites are hosted, all of its clients would basically need to rerun this procedure, https://docs.digicert.com/en/certcentral/manage-certificates/supported-dcv-methods-for-validating-the-domains-on-ov-ev-tls-ssl-certificate-orders/use-the-dns-txt-validation-method-to-verify-domain-control.html https://docs.digicert.com/en/certcentral/manage-certificates...
  - Hizonner 2y ago
    OK, true, that's one of the (inadequate) methods that the CA/BF permits for verification at issuance, and I had forgotten about that. You can also verify over HTTP or email (egad...). You would think that if Alegeus controlled the HTTP servers and not the DNS servers, Alegeus would opt for HTTP verification, but I concede that they may have built everything around DNS verification.
    - temac 2y ago
      > that's one of the (inadequate) methods that the CA/BF permits for verification at issuance Why inadequate (in the absolute)? This can be automated and let's encrypt allows verification through DNS, moreover this allows verification for wildcard certificates. Now in this particular case maybe they should have gone through HTTP, and even automated with ACME. But there is nothing inadequate in the absolute in DNS verification. Besides allowing wildcard it also allows verification when you don't control the web server(s), when you don't even have a webserver at all, when the standard ports are occupied for something else, etc.
      - Hizonner 2y ago
        > Why inadequate (in the absolute)? The point of X.509 certificates is that you can't rely on information you get either from the DNS or from the HTTP server. If you could, you wouldn't need the whole mess in the first place. Sure, the verification helps, because you have to successfully fool both the client and the CA. But if you can fool one, there's a strong chance that you can fool the other. In the end, the CA is still relying on exactly the same information that the client isn't supposed to have to rely on. The original idea behind X.509 was that verification would be "out of band", but that turned out to be expensive and non-scalable, so the X.509 world, including the CA/BF, resorted to this very weak kind of verification. They try to backstop it with stuff like certificate transparency, but it's just adding epicycles that aren't particularly reassuring. If everybody used DNSSEC, then DNS-based verification would be OK. But at that point you ought to just distribute key hashes through the DNS and dispense with X.509 entirely. That's actually what should have happened, and probably what would have happened if X.509 hadn't still been such a cash cow at the times when the various standards solidified beyond all chance of improvement. Because of that "cash cow" status, there was a lot of obvious sabotage aimed at entrenching X.509 and fighting any attempt to improve the situation. And now we're stuck with it.
- deleted 2y ago
  [deleted]
mynameisvlad 2y ago
> IMO, if you built a system (and I'm talking about DigiCert here) that expects thousands of customers can update everything at the drop of a hat to update their code, you built a bad system. Per the article, this is required to be a CA. It's not a DigiCert thing, it's a baseline requirement. If you can't revoke your certificates quickly, you risk being delisted by Google/Mozilla/Microsoft et al. Entrust was just recently dropped in part because of this very thing.
- x0x0 2y ago
  Sure, but it's still DigiCert's fault doubly: 1 - they made the screwup; 2 - DigiCert appear not to have put language into their MSAs and so forth that this was a thing that could happen and customers had better be prepared to do it. Why shouldn't Alegeus sue DigiCert to force DigiCert to conform to the terms of the agreement that DigiCert agreed to with Alegeus?
Palomides 2y ago
would you say the same thing if these certs were being actively misused? how long should they get to run amok? if you don't have a fast process for replacing this stuff, you're going to have a bad day eventually
plorkyeran 2y ago
If you build a system which relies on WebPKI certificates and you don’t have the ability to quickly replace those certificates, your system is insecure and will break. This is fairly central to how the entire concept of a publicly trusted CA works.
bastawhiz 2y ago
> it's that their many customers can't update their DNS records fast enough to point to the new certs. This is almost certainly wrong. With the exception of DNSSEC, there's no interaction between DNS and certificates. There's no DNS record that points at a certificate. The HTTP server that terminates the connection is the server that has the certificate. TXT records can validate a domain, but you can also validate a domain by hosting a file on that domain to show that you control it. I find it more likely that Alegeus is giving customers appliances or VMs that they run themselves, and those are each configured with a baked-in certificate. Which is bad anyway because it means the customer needs to be involved in the certificate update process.

Hizonner 2y ago

Um, what are you talking about? Unless you use DANE (which nobody does, and the browsers don't check it even if they did), you do not have to change any DNS records, or touch the DNS at all, to update a certificate. There is no DNS involvement. Period. DANE should be the norm, but it's not.

hn_throwaway_99 2y ago
Perhaps I am misunderstanding what needs to happen, but since Alegeus itself doesn't control the domains on which its sites are hosted, all of its clients would basically need to rerun this procedure, https://docs.digicert.com/en/certcentral/manage-certificates/supported-dcv-methods-for-validating-the-domains-on-ov-ev-tls-ssl-certificate-orders/use-the-dns-txt-validation-method-to-verify-domain-control.html https://docs.digicert.com/en/certcentral/manage-certificates...
- Hizonner 2y ago
  OK, true, that's one of the (inadequate) methods that the CA/BF permits for verification at issuance, and I had forgotten about that. You can also verify over HTTP or email (egad...). You would think that if Alegeus controlled the HTTP servers and not the DNS servers, Alegeus would opt for HTTP verification, but I concede that they may have built everything around DNS verification.
  - temac 2y ago
    > that's one of the (inadequate) methods that the CA/BF permits for verification at issuance Why inadequate (in the absolute)? This can be automated and let's encrypt allows verification through DNS, moreover this allows verification for wildcard certificates. Now in this particular case maybe they should have gone through HTTP, and even automated with ACME. But there is nothing inadequate in the absolute in DNS verification. Besides allowing wildcard it also allows verification when you don't control the web server(s), when you don't even have a webserver at all, when the standard ports are occupied for something else, etc.
    - Hizonner 2y ago
      > Why inadequate (in the absolute)? The point of X.509 certificates is that you can't rely on information you get either from the DNS or from the HTTP server. If you could, you wouldn't need the whole mess in the first place. Sure, the verification helps, because you have to successfully fool both the client and the CA. But if you can fool one, there's a strong chance that you can fool the other. In the end, the CA is still relying on exactly the same information that the client isn't supposed to have to rely on. The original idea behind X.509 was that verification would be "out of band", but that turned out to be expensive and non-scalable, so the X.509 world, including the CA/BF, resorted to this very weak kind of verification. They try to backstop it with stuff like certificate transparency, but it's just adding epicycles that aren't particularly reassuring. If everybody used DNSSEC, then DNS-based verification would be OK. But at that point you ought to just distribute key hashes through the DNS and dispense with X.509 entirely. That's actually what should have happened, and probably what would have happened if X.509 hadn't still been such a cash cow at the times when the various standards solidified beyond all chance of improvement. Because of that "cash cow" status, there was a lot of obvious sabotage aimed at entrenching X.509 and fighting any attempt to improve the situation. And now we're stuck with it.
deleted 2y ago
[deleted]

mynameisvlad 2y ago

> IMO, if you built a system (and I'm talking about DigiCert here) that expects thousands of customers can update everything at the drop of a hat to update their code, you built a bad system. Per the article, this is required to be a CA. It's not a DigiCert thing, it's a baseline requirement. If you can't revoke your certificates quickly, you risk being delisted by Google/Mozilla/Microsoft et al. Entrust was just recently dropped in part because of this very thing.

x0x0 2y ago
Sure, but it's still DigiCert's fault doubly: 1 - they made the screwup; 2 - DigiCert appear not to have put language into their MSAs and so forth that this was a thing that could happen and customers had better be prepared to do it. Why shouldn't Alegeus sue DigiCert to force DigiCert to conform to the terms of the agreement that DigiCert agreed to with Alegeus?

Palomides 2y ago

would you say the same thing if these certs were being actively misused? how long should they get to run amok? if you don't have a fast process for replacing this stuff, you're going to have a bad day eventually

plorkyeran 2y ago

If you build a system which relies on WebPKI certificates and you don’t have the ability to quickly replace those certificates, your system is insecure and will break. This is fairly central to how the entire concept of a publicly trusted CA works.

bastawhiz 2y ago

> it's that their many customers can't update their DNS records fast enough to point to the new certs. This is almost certainly wrong. With the exception of DNSSEC, there's no interaction between DNS and certificates. There's no DNS record that points at a certificate. The HTTP server that terminates the connection is the server that has the certificate. TXT records can validate a domain, but you can also validate a domain by hosting a file on that domain to show that you control it. I find it more likely that Alegeus is giving customers appliances or VMs that they run themselves, and those are each configured with a baked-in certificate. Which is bad anyway because it means the customer needs to be involved in the certificate update process.