Comment on Letsencrypt is under US jurisdiction. Is there a free-er alternative?

• pdl@social.tchncs.de ⁨21⁩ ⁨hours⁩ ago

  @flandish Which backdoor? When I request a CA for a certificate, I send the public key to the CA. The CA does a validation and signs the certificate.
  The CA does not see any traffic from my server. A man-in-the-middle needs my private key, which is under my administration. If I loose my private key, it does not matter if the certificate is signed by a US based CA or an European CA.

  original

  • pdl@social.tchncs.de ⁨21⁩ ⁨hours⁩ ago

    @flandish If US authorities want to fake my server, they can use any CA, regardless which CA I originally used.
    Of course, US authorities can force Letsencrypt to revoke my certificates and block any renewing. This is very unlikely to happen. If it happens, I have to change my CA. There would be a downtime for my private services, but there is no data corruption or data loss on my servers.

    original

    • flandish@lemmy.world ⁨21⁩ ⁨hours⁩ ago

      [deleted]

      original

      • pdl@social.tchncs.de ⁨20⁩ ⁨hours⁩ ago

        @flandish This is no backdoor. This is an denial of service. It's a big difference. I have to estimate the risk and decide if I want to take it. ZeroSSL uses the infrastructure of Sectigo, an US company. Sectigo can pull the plug very easily. So it is no alternative. Maybe Actalis or Certum are good alternatives. But the government of Poland has not been unproblematic in the past.

        original
      • Pika@sh.itjust.works ⁨20⁩ ⁨hours⁩ ago

        Said backdoor isn’t possible with the current day key exchange process. Without the servers in use private key, the most law agencies can do without acquiring the private key is force the CA to revoke a cert, which will disallow properly configured clients from accessing and transferring data with the server.

        LE doesn’t have enough information to recreate the private key based off the public key, the only key distributed during the CSR process is the servers public key via a certificate signing request which is signed using your private key, which the CA then signs with it’s own intermediate key (which is signed by it’s root server certificate) and hands back to the private server.

        The CA doesn’t have the ability to create that private key, and as such doesn’t have a way to decrypt traffic that is using that key. There is no concern for a backdoor in that process.

        In order for the “backdoor” to exist, they would need to either copy the private key as part of the signing process (which it doesn’t), or somehow force the server admin to use a new private key (that the CA also holds) or somehow compromise the servers key generation process to allow for an escrow on the private key when it was generated which would allow the CA to be able to recreate the private key using the master & public key.

        Now don’t take me wrong, you can still have a MiTM impersonation attack or a full impersonation bypass by the CA issuing a new certificate and having the DNS registrar have the web address go to a new server that is using the new public key but, that’s not something the CA alone has the capability of doing, and any traffic that is issued to the original server still wouldn’t be compromised, its just clients visiting your site will end up at the other site and as such will end up using keys that the other side generated instead of your own keys and additionally said new keys would also be appearing in Certificate transparency logs, or modern day clients would refuse to use them.

        original