This one is worth writing down because the failure is delayed and silent, which is the worst combination.
Vercel issues and renews certificates using an HTTP-01 challenge. The certificate authority requests a token at http://<domain>/.well-known/acme-challenge/<token> and Vercel has to be the thing that answers. That requires the domain to actually resolve to Vercel at the moment of renewal.
Put Cloudflare in front with the record proxied and Cloudflare answers instead. The challenge path never reaches Vercel. Renewal fails.
Here is why it is a trap rather than an error. Cloudflare terminates TLS at its own edge with its own certificate, so visitors see a valid padlock and a working site the entire time. The Vercel certificate is not being used for anything a visitor touches. Nothing in the browser complains. Nothing in the deploy output complains. Deploys keep succeeding.
The consequence lands whenever you next need the origin certificate to be valid: turning the proxy off, switching to a mode that validates the origin, or hitting the deployment URL directly. That can be 60 days after the change, and by then the change is not in your recent memory. You will look for a cause in the last week of work. It is not there.
If you want both, the record has to stay DNS-only, grey cloud, and you give up the proxy features on that hostname. Or you move certificate issuance somewhere that does not depend on the origin being reachable for HTTP-01, which for Vercel means you are fighting the platform.
Simplest correct answer for this site: one CDN, and it is Vercel’s.