There’s no place
like HTTPS

There’s no place like HTTPS: Why redirects need secure connections

On a recent trip to Las Vegas, I encountered a decidedly un-Vegas theme: The Wizard of Oz. The Sphere Las Vegas was celebrating its first anniversary, turning a walk down the Yellow Brick Road into a fully immersive experience. The mesmerizing stroll brought to mind a much less glamorous journey that happens constantly online: the path from one URL to another.

An HTTPS redirect may last only a fraction of a second, but the browser still has to reach the source hostname before it can move on to the destination. If that first stop doesn’t support HTTPS, visitors can encounter a security warning before they ever reach the site you intended them to see.

That means redirect domains need HTTPS, too. And with browsers strengthening HTTPS protections while TLS certificate lifecycles get shorter, securing and managing those redirects is becoming more important. 

Why every redirect domain needs HTTPS

A redirect sends a browser from one URL to another. But before the browser can receive that instruction, it first needs to connect to the source hostname. That makes the source domain part of the connection path.

If the source doesn’t support HTTPS with a valid TLS certificate, the connection can fail or trigger a warning before the secure destination ever comes into play. A secure destination can’t fix an insecure first step. That makes redirect-only domains part of your HTTPS footprint, even when visitors spend only a fraction of a second on them. Two industry changes are making those easily overlooked domains more important.

Why HTTP-only redirects are becoming harder to ignore 

Chrome is moving closer to an HTTPS-by-default web.

Google has announced that, with Chrome 154 in October 2026, it plans to enable “Always Use Secure Connections” for public sites by default. Chrome will attempt connections over HTTPS and warn users before they continue to a public site that doesn’t support it.

Google specifically identifies HTTP URLs that immediately redirect to HTTPS destinations as a source of insecure navigation that can otherwise be practically invisible to users.

At the same time, publicly trusted TLS certificates are getting shorter. 

Under CA/Browser Forum requirements, the maximum validity period for publicly trusted TLS certificates dropped to 200 days on March 15, 2026. It will fall to 100 days in March 2027 and 47 days in March 2029. Domain and IP address validation reuse periods are shrinking as well.

Together, these changes broaden the certificate management challenge. HTTPS coverage can’t stop at your primary websites and applications. It needs to include every public hostname a browser may touch along the way. That includes redirects.

Which redirect domains are most likely to be missed?

You probably already protect the websites and applications your team considers production infrastructure. The harder part is the long tail of domains surrounding them. 

Common examples include:

• Parked domains
• Campaign URLs
• Subbrands 
• Acquired properties
• Legacy hostnames
• Migration domains

Many of these assets do little more than forward traffic, which makes them easy to dismiss during certificate inventory and renewal planning. But browsers experience the connection in sequence. They first reach the source hostname, establish a connection, and then receive instructions to go somewhere else. If HTTPS fails at the source, the redirect may never get the chance to do its job. 

Shorter TLS certificates make manual redirect management harder

Redirect-only domains can create a disproportionate amount of certificate work.

Even if a hostname has one purpose—sending visitors somewhere else—it may still need a TLS certificate that has to be issued, deployed, monitored, and renewed. Now, multiply that work across parked domains, campaigns, acquired properties, alternate domain names, and migration infrastructure.

Shorter certificate lifecycles make the problem more pronounced because those operations have to happen more frequently. What was once an occasional maintenance task becomes an ongoing certificate lifecycle management process. 

Redirect domains can also be particularly easy to miss. They may not have an application team monitoring them. Nobody may think of them as “websites.” Some might receive relatively little traffic. But one missed certificate renewal can still interrupt a visitor before the redirect completes. The challenge isn’t simply enabling HTTPS once. It’s maintaining HTTPS reliably across the entire redirect portfolio.

Automating HTTPS forwarding

Automation can remove much of that operational burden.

DigiCert UltraDNS Secure Web Forwarding can securely redirect traffic over HTTPS while automating certificate management for the forwarding endpoint. 

You define where traffic comes from and where it should go. With automated certificate management enabled, UltraDNS and DigiCert handle certificate issuance, deployment, renewal, and the DNS records needed for domain control validation.

Web Forwarding also supports capabilities such as:

• Multiple redirect types: Configure redirects including 301, 302, 303, and 307 based on the behavior you need.
• Path and query-string preservation: Carry incoming paths and parameters through to the destination when configured with relative forwarding. 
• Portal and API management: Create and manage forwarding records through UltraDNS management interfaces and APIs.
• Wildcard matching: Configure forwarding rules that cover related URLs and paths without creating an individual rule for every request.

For domains whose primary purpose is simply to send visitors somewhere else, automating the certificate lifecycle can remove much of the operational work associated with secure HTTPS forwarding.

How to audit your HTTPS redirects 

A domain portfolio review shouldn’t stop at active production websites.

Include active, parked, legacy, campaign, acquired, and migration-related domains, then look specifically for hostnames that redirect traffic.

For each redirect domain:

1. Test HTTPS at the source. Confirm that the source hostname can establish a secure connection before the redirect takes place. 
2. Check the TLS certificate. Make sure the forwarding endpoint presents a valid, publicly trusted certificate where required.
3. Review the renewal process. Determine whether certificate renewal is automated and repeatable rather than dependent on someone remembering a manual task.
4. Test the complete redirect. Confirm that visitors reach the intended destination and that paths and query strings behave as expected.
5. Keep redirects in your certificate inventory. A hostname doesn’t stop being part of your certificate estate simply because it forwards traffic. 

Redirects may be brief, but they’re still part of the connection path.

As browsers strengthen HTTPS protections and TLS certificate lifecycles shrink, treating forwarding domains as first-class members of your HTTPS estate can help prevent avoidable warnings, reduce manual certificate work, and give visitors a more consistent experience.

After all, even the shortest trip down the Yellow Brick Road should start with a secure connection.