My registrar's domain forwarding works for plain HTTP but not HTTPS — why, and what should I use instead?

The mechanism explains it completely: to redirect an HTTPS request, something must first terminate a valid TLS connection for the old domain, and that requires a certificate for the old domain.

A plain HTTP redirect needs no certificate — a small server answers on port 80 and returns a redirect. That is cheap, so registrars offer it freely.

HTTPS is different. The browser insists on a valid certificate for the name it asked for before it will look at any response, including a redirect. So the forwarding service must obtain and renew a certificate for every customer domain it forwards. Some registrars do not do this at all, and some do it only on paid tiers.

When the certificate is missing, the browser sees a mismatch and stops. It never gets far enough to be redirected, which is exactly the symptom you describe.

The options, roughly cheapest first:

Put the domain behind a service that terminates TLS for you. Several content delivery and DNS providers offer free tiers that issue a certificate for your domain automatically and let you configure a redirect rule. You change the nameservers, add a rule, and it works for both protocols. This is what most people end up doing and it costs nothing.

Use a dedicated redirect service. Small paid services exist that do only this — point the domain at them and configure the target. Worth it if you have a handful of domains and do not want to manage anything.

Host a tiny redirect yourself. Any small server or serverless function with an automatic certificate can answer for the old domain and issue a permanent redirect. More control, more to maintain.

What I would avoid is buying full hosting purely to serve a redirect, which is the option the registrar will suggest.

Whatever route you take, get the details right, because a redirect done badly loses most of the benefit of doing it at all.

• Use a permanent redirect rather than a temporary one, so search engines transfer the ranking signals to the new address.
• Redirect path-for-path, not everything to the home page. A visitor following an old link to a specific article should land on that article, not on the front page. Wholesale redirection to the root is treated as a soft error by search engines and it is a bad experience.
• Cover both the bare domain and the www form, over both protocols. That is four combinations and people routinely configure two.
• Keep it running for years. Old links live a long time. Retiring the redirect after six months throws away the traffic you were trying to preserve.

One practical note for the conversation with the other developer, since you mentioned needing to explain this.

The framing that lands is: "the old domain needs a certificate before anything can redirect, and the registrar's free forwarding does not provide one." That is a concrete technical requirement rather than a complaint about a feature, and it makes the fix obvious to anyone who has set up a site.

It also stops the conversation drifting into whose fault it is, which with an inherited setup and two parties is where these usually go.