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

?

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

> 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.)

If users delegate their DNS to you, what's stopping you issuing a certificate to yourself for their site?

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.

Right, but if you want people to trust you, you need to be open about what people are trusting you with. Your original answer seemed obfuscatory.

Sorry, not trying to obfuscate anything, hopefully this clarifies: users trust us to hold their ACME account key and we only ask for DNS records prefixed with `_acme-challenge.` to be CNAME delegated.

With this we could issue or revoke a new certificate, but we couldn't impersonate them because we don't control the rest of their DNS.

> we couldn't impersonate them because we don't control the rest of their DNS.

If that were true, nobody would need signed certificates in the first place.

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)

> The ability to set up your own clone instance its completely meaningless

Isn't that the whole point?

Yes. But that point doesn't help the users since they don't have the data.

It helps in strawman cases when users have the data, and the platform doesn't have social features. For instance, oh, an online photo editor used by the user in isolation, on either local files or easily downloadable files. User doesn't like that instance, so they find the AGPLed source code and run their own, bringing all their files.

(Why, in that situation, would the user be entitled to the custom modifications in that instance they are abandoning? If you don't like that instance for whatever reason, but like the features, tough luck. Code your own.)

Why would the user be entitled to the commercial SAAS platform's custom modifications?

Because the platform provider didn't pay for the database's commercial license.

Yes, currently these are never deleted.

I will probably update it to delete accounts that have been inactive for a year or something.

A little more information:

So, it's called fakemail but there is a real SMTP server in there. Attachments should work fine. Getting the web app to create SMTP accounts was quite tricky, I'm sure there are better ways but I ended up implementing the unix crypt() algorithm in C#.

Server is holding up fine so far (there was a rate-limiting bug which brought the site down yesterday). Logs show 37K unique IPs have accessed it since yesterday, and it seems to be using about 1% of the CPU (it's on a free VM in the Oracle Cloud).

There is a whole API sitting behind the web page, including proper authentication, but the frontend is very much a MVP.

Very few actual emails have been sent to it, so I'd love it if people could actually send stuff. There are a bunch of websites that can be used to send test mails, e.g.

https://www.gmass.co/smtp-test

https://www.smtper.net/

https://smtpserver.com/smtptest

https://dnschecker.org/smtp-test-tool.php

Most people these days are using a service provider for SMTP in production, so it isn't really possible to keep your prod and test configs in sync.

I do agree about using testing everything real tools, which is why this (fakemail) uses OpenSMTPD as the mail server.

All the work is in configuring it (similar complexity to your postfix configuration by the looks of it), interfacing to it, and deploying it (currently using ansible but will probably dockerize it).

The fact that no emails can get through to a real recipient is a feature.

The idea is that, in a a test environment, we should not actually deliver the mails to the recipient, instead making them available on a web page (or through an API).

This is all open source by the way, and can be self-hosted. All the code is at https://github.com/aled/fakemail.

The 429 response is sent when rate-limiting (based on IP address).

Either something is wrong with my rate-limiting code or there are many people behind a single IP address.

Anyway the limits are increased now.

Possible your application isn't seeing real ips, maybe is seeing the IP of a load balancer or similar.

Do we know whether the machine on which this occurred had ECC memory?

It appears to be hosted on AWS, which claims to use ECC memory.

Not sure why you defend this practice. No other hosting provider requires copies of their user's passports.

I am also unable use Hetzner, due to their overreaching security process.