[cprecioso]

That was an interesting read, thanks! Two questions:

- What is the problem with stale certificates if a domain changes hands? It seems to me that whether they renew the certificate or not, the security situation for the user is still the same, no?

- Is CertKit a similar solution to Anchor Relay? (https://anchor.dev/relay)

[toddgardner]

> What is the problem with stale certificates if a domain changes hands?

The previous owners have valid certificates for up to 398 days. If they are a malicious party cable of doing a man-in-the-middle attack, they can present a valid certificate and fully impersonate the owner. For example, when Stripe started, they purchased the domain from another party, who had a valid stripe.com payment certificate for nearly a year. (https://www.certkit.io/blog/bygonessl-and-the-certificate-th...)

> Is CertKit a similar solution to Anchor Relay?

I hadn't heard about anchor relay before, thanks for the link!

CertKit is similar, but broader. Anchor says it sits between your ACME clients and the CA and simplifies the validation steps, which is super useful. But you still have to run ACME clients and have a bunch of automation logic running on your end.

CertKit IS the ACME client. You CNAME the challenge record to us and we do all the communication with the CAs and store/renew/revoke your certificates centrally. Your systems can pull (or be pushed) the certs they need via our API, then we monitor the HTTPS endpoints to make sure the correct cert is running. Its a fully-audited centralized certificate management.

[ItsHarper]

The problem is that the old owner still has a valid certificate for some period of time.

[account42]

Except this is going the wrong way. We should be discouraging frequent domain ownership changes not making them easier. New owners getting visibility into traffic meant for the old owners is as much if not a bigger problem.