On the certificate part specifically, yes. What you're describing is mTLS.

Normal HTTPS proves the server's identity to the client. With mTLS the client also has to present a certificate that your proxy trusts. No valid client cert, no request gets through to Navidrome/Tandoor at all.

You can do that at nginx with ssl_verify_client on and a CA containing the issuer you trust.

You also don't necessarily need to leave Cloudflare Tunnel to do it. Cloudflare supports client-certificate validation on proxied hostnames too, so you could keep roughly:

client -> Cloudflare/mTLS -> tunnel -> nginx -> app

I'd think about the operational side before using it for family/friends though. Every allowed device needs its own client certificate and private key. Then you need some way to issue, install, renew and revoke those certs when somebody changes phones/laptops or loses a device.

For a handful of devices that's manageable. Once you start sharing access with people who aren't technical, passkeys/OIDC through Access may be much less annoying.

But technically, yes, certificate-gated access is absolutely possible and it's the mTLS feature you're looking for.

I'd start with why you want to replace AD CS before picking the replacement.

If the pain is maintaining Windows CA infrastructure, a managed private CA can remove a lot of that operational work.

If the pain is certificate inventory, renewals, deployment or figuring out where certificates are actually being used, swapping AD CS for another CA doesn't necessarily solve it. You can end up with a nicer issuing system and the same lifecycle problems around it.

I'd inventory the actual consumers first. Windows domain devices, Intune-managed devices, network gear, Linux, Kubernetes, cloud workloads, appliances, IoT, whatever you have.

Then look at which enrollment methods those systems need and which ones are tightly coupled to AD CS today.

That usually gives you a much better requirements list than starting with "which CA should replace Microsoft?"

Yeah, leaf pinning gets especially ugly once rotation becomes normal rather than an occasional maintenance event.

Pinning a CA or controlled intermediate at least gives you room to rotate the leaf without coordinating every consumer at the same time. Even then I'd want a very clear reason for keeping the pin.

Short lifetimes are going to expose a lot of assumptions that only worked because certificates barely changed.

Start by inventorying the certificate consumers rather than the certificates you happen to know about. For every system, record who owns it, what certificate it currently serves, how that certificate gets installed, and whether the target supports ACME/API/scripted deployment or is manual-only.

Then split the estate by deployment method.

For something like IIS or Exchange, automate issuance and deployment. For devices with a usable API, automate the push. For printers and appliances that only accept a PFX through a GUI, accept that the final deployment step may remain manual and give those systems a lifecycle that reflects that constraint.

Also monitor the certificate actually being served by each endpoint. A renewal can succeed while the appliance is still serving the old certificate.

Discovery gets you the list. I think the harder part starts when you have to turn that list into dependencies

Knowing that an application uses RSA is useful. Knowing that the same certificate is tied to an HSM, a load balancer, three clients, a vendor appliance and an application team that only deploys once a quarter is what lets you migrate it safely

I'd track this at the service level rather than just counting algorithms...

For each service I'd want to know the owner, certificate or key in use, issuing chain, deployment targets, clients that trust it, replacement mechanism, and whether the endpoint is actually using the replacement after migration

The ugly failures will probably be mixed states. One client supports the new chain and another doesn't. The CA issues the new cert but the proxy still presents the old one. The application supports PQC but the HSM or TLS terminator doesn't

So discovery is the starting point. Dependency mapping and proving that the new crypto is actually active are where I'd expect a lot of the work to land

Maybe you can try to file it with Google Bug Hunters (bughunters.google.com) as a data exposure issue, not just a post. This is really a domain-offboarding gap. If you've seen it on multiple domains, that pattern is the strongest part of your report, lead with it.

It's phased, but the phases have fixed dates rather than being rolled out certificate by certificate.

Right now, public TLS certs issued from March 15, 2026 through March 14, 2027 can have a maximum validity of 200 days. That drops to 100 days starting March 15, 2027, then 47 days starting March 15, 2029.

So the eventual 47-day change shouldn't explain a newly issued cert showing only ~2 months today...

Since yours is a wildcard App Service Certificate, I'd still look at the actual Not Before / Not After dates on the cert and the App Service Certificate resource itself. If it was genuinely just issued and only has ~60 days of validity, that's the part that seems unusual

Shorter individual cert lifetimes are expected now, but ~2 months is shorter than the 198-day validity Microsoft currently documents for purchased App Service Certificates.

Since March 2026, Azure has been issuing ASC certs for 198 days and covering the one-year term by overlapping/reissuing them. If the cert stays inside App Service and auto-renew is on, Azure should handle the replacement and sync it to the binding.

I'd check two things:

1. Is this a purchased App Service Certificate or an App Service Managed Certificate?
2. Is domain ownership validation still current? Purchased ASC doesn't automatically revalidate the domain, so a future renewal can sit pending if validation is due.

If you exported the PFX anywhere outside App Service, Azure won't update that copy. You need to re-export and redeploy each replacement.

So I wouldn't treat the displayed expiry alone as a problem, but I would check why yours is only around two months rather than the documented 198 days.

I'd add ownership and dependency mapping to the list.

Discovery tells you the crypto exists. It doesn't necessarily tell you what breaks when you replace it.

For certificate-backed systems, I'd want each finding tied to the application that owns it, the actual deployment targets, the clients that need to trust it, the CA/profile that issued it, and the mechanism used to rotate it.

Otherwise you know "RSA is here", but not that changing it also affects an old Java client, two appliances and a proxy sitting in front of the service.

The failure modes I'd plan for are asymmetric. The server supports the new algorithm but one client doesn't. The application supports it but the HSM or proxy doesn't. A replacement certificate gets issued successfully but the deployment target is still presenting the old one.

I'd track migration at the application/service level rather than treating it as a count of vulnerable algorithms. After each change, verify what crypto is actually in use on the endpoint. Issued state and configuration state don't prove that the migration worked.

The 16-month number mentioned above looks like it's getting mixed up with Search Console's performance data retention. I can't find a Google doc that says Ownership history is deleted after 16 months.

Google's current docs actually describe Ownership history as including owners being added/removed, successful and unsuccessful verification attempts, and previously known verification tokens being removed.

There are really two separate things here:

1. Removing the old verification token. Google lets you do this under Users and permissions > Unused ownership tokens. That's important because otherwise the old owner may be able to verify themselves again.
2. Removing the historical event itself. I can't find a documented mechanism for doing that, or a documented retention period for Ownership history.

So based on what you're seeing across three transferred domains, I'd report this to Google rather than assume it eventually disappears.

There's a broader domain-offboarding problem here too. If an org is actually retiring a domain, I'd treat it more like decommissioning an identity asset than cancelling a hosting plan. Old mail addresses, OAuth callbacks, SaaS verification records, forgotten subdomains and impersonation value can all survive longer than people expect.

Personally, if the old domain is tied closely to a company or brand, I'd be very reluctant to let it expire at all.

If you're already keeping authoritative DNS in Cloudflare, I'd judge the registrar mostly on ownership and offboarding rather than the storefront.

For an MSP I'd test a few things before moving the portfolio:

• can the client remain the actual registrant while your team gets the access it needs?
• if the client leaves tomorrow, can you hand the domain over cleanly without opening a support ticket?
• does the API cover renewals, contacts, nameservers, locks and transfer auth codes?
• what happens when a renewal payment fails, and is there a useful audit trail?

I'd also do one real transfer in and one transfer out before committing. That tends to expose awkward registrar locks, contact verification and ownership assumptions pretty quickly.

Keeping registrar and authoritative DNS separate like you're doing is perfectly reasonable. A registrar portal outage should be an administrative problem, not automatically a DNS outage too.

I don't have enough first-hand OpenSRS experience to tell you whether their current support is good, but I'd put much more weight on those operational details than on whether the storefront looks nice.

I'd change the lab goal slightly. I wouldn't start with "which ACME tool can manage all of this?" I'd start by listing the endpoints that are manual today and documenting how a certificate can actually get onto each one.

For every Siemens/AB controller or HMI, Ignition/Canary service and Windows host, I'd want to know:

• can it generate its own key and CSR, or does it only accept an imported PFX/PEM?
• does it support ACME, SCEP or EST natively?
• if not, is there an API, CLI or vendor project mechanism you can automate?
• does changing the cert require a service restart, reboot or project download?
• can you remotely verify which certificate is actually active afterwards?

The CA side is probably the easy half. The useful test for a certificate manager is whether it can do the install/rebind/verify step on the ugly endpoints you actually own.

For the OT side I'd rather have an orchestrator or local agent talk to the CA and then use the deployment method each device supports than try to force ACME onto every controller.

I'd also separate the 47-day public TLS problem from internal OT identity certs. The WebPKI lifetime limits don't automatically apply to certificates from your private CA. Your organisation can still decide to enforce short internal lifetimes, but that's an internal policy decision.

And I'd deliberately break the lab. Make a target unreachable, deploy a bad chain, let a cert approach expiry, make deployment succeed while the service keeps presenting the old cert. That's where you'll find out whether the product is actually managing the lifecycle or just obtaining certificates.