Comment by aeaa3
Does this means that you have the ability to
a) impersonate the identities of your users and b) decrypt the SSL traffic of your users
?
Does this means that you have the ability to
a) impersonate the identities of your users and b) decrypt the SSL traffic of your users
?
> We hold an ACME account key on your behalf with the CA, but we cannot use it impersonate your domain or decrypt traffic.
That makes no sense whatsoever. If you have an ACME account key for my domain, of course you can use it to impersonate my domain. You just need to create another certificate. (Which I could detect, but if I know how to do that, I'm probably not going to need your service anyway.)
We theoretically could, but those certificates would show up in CT logs. (For quick & easy monitoring, you can get an RSS feed for your domain on https://crt.sh/, but it's not the most reliable service.) It would be a reputation killer if we did that, just like it would be for your DNS provider or ISP.
Certificate transparency logs are likely the only realistic way, but you could make the same argument against your DNS provider. Trust has to start somewhere.
Whether or not something like this makes sense to you is probably a question of your personal threat model.
Seeing how people are worried about third parties issuing certificates, I encourage using a tool to monitor CT Logs. It really makes the fog of war disappear around your certificates.
https://crt.sh for point in time checks, https://sslboard.com for comprehensive oversight (disclosure: I'm the founder)
It does not.
Anchor never see sees your private keys for certificates.
We hold an ACME account key on your behalf with the CA, but we cannot use it impersonate your domain or decrypt traffic.
We have a more technical overview of how this works in our docs: https://anchor.dev/docs/public-certs/acme-relay