Overview
Google Chrome is changing how it handles websites that use HTTP instead of HTTPS.
Beginning with Chrome 154, Chrome can display an Ask-before-HTTP warning when you open a public HTTP address and Chrome cannot establish a secure HTTPS connection to that address first.
This can affect domains that are used only to redirect visitors to another website. The destination website may already use HTTPS, but the original forwarding address must also be able to accept an HTTPS connection.
If your domain uses UltraDNS Web Forwarding, you can use HTTPS Web Forwarding with a valid TLS/SSL certificate to provide the secure connection before the redirect occurs.
When to Use This Article
Use this article if:
- A domain or hostname in UltraDNS is configured to forward visitors to another website.
- Chrome displays a warning before opening the forwarding address over HTTP.
- The final website already uses HTTPS, but the original forwarding hostname does not.
- You want your UltraDNS Web Forward to accept HTTPS connections.
What Is Happening?
A web redirect happens after your browser connects to the original hostname.
For example, assume you have:
http://example.com
forwarding visitors to:
https://www.example-new-site.com
Even though the destination uses HTTPS, Chrome must first connect to example.com. If that original hostname cannot establish an HTTPS connection, Chrome may display the Ask-before-HTTP warning before continuing over HTTP.
This means that securing only the destination website does not secure the original forwarding connection.
How to Resolve the Warning
The forwarding hostname needs to support HTTPS and present a valid TLS/SSL certificate before it sends the visitor to the destination website.
UltraDNS HTTPS Web Forwarding provides this capability when Certificate Management is enabled for your account.
There are two certificate options available.
Option 1: Use an UltraDNS Managed Certificate
If Automated Certificate Management is enabled for your account, you can select Use an UltraDNS managed certificate when configuring the HTTPS Web Forward.
UltraDNS and DigiCert then manage the certificate used by the forwarding hostname. This includes certificate issuance, deployment, and renewal, as well as the required CAA and DNS-based Domain Control Validation records.
If Automated Certificate Management is not enabled for your account, contact UltraDNS Support for assistance with enabling the feature.
Option 2: Upload Your Own Certificate
You can also upload your own valid TLS/SSL certificate through Certificate Management and apply that certificate to the HTTPS Web Forward.
If you provide your own certificate, you are responsible for maintaining the certificate and replacing or renewing it when necessary.
Configure HTTPS Web Forwarding
The HTTPS Forward option is available when Certificate Management is enabled for your account.
When creating the Web Forward:
- Open the Web Forwarding configuration for the domain you want to redirect.
- Enable HTTPS Forward.
- Select the certificate that will protect the forwarding hostname.
- Enter the address you want visitors to be redirected from in the Requests To field.
- Enter the destination in the Redirects To field.
- Select the required redirect Type.
- Click Save.
If Automated Certificate Management is enabled, you can select Use an UltraDNS managed certificate instead of selecting a certificate that you uploaded manually.
What to Expect After Configuration
When HTTPS Web Forwarding is correctly configured, the browser can make a secure HTTPS connection to the original forwarding hostname before UltraDNS sends the redirect.
For example:
https://example.com
can establish the secure connection first and then redirect the visitor to:
https://www.example-new-site.com
This removes the HTTP-only forwarding step that causes the Ask-before-HTTP condition described in this article.
Test the Forward in Chrome
Chrome provides a setting that you can use to test how the forwarding hostname behaves when secure connections are required.
- Open Chrome.
- Open Settings.
- Select Privacy and security.
- Select Security.
- Enable Always use secure connections.
- Select Warns you for insecure public sites.
- Open the forwarding hostname and verify that the HTTPS connection and redirect complete as expected.
You can also enter chrome://settings/security directly in the Chrome address bar to open the Security settings.
Certificate Errors Are a Different Issue
The Chrome Ask-before-HTTP warning should not be confused with a TLS/SSL certificate error.
If you open an HTTPS address and the certificate is expired, does not match the hostname, or is otherwise invalid, Chrome can display a certificate or connection error.
That type of error should be investigated as a certificate configuration issue rather than an Ask-before-HTTP issue.
Frequently Asked Questions
My destination website already uses HTTPS. Why can I still receive the warning?
The browser first connects to the original forwarding hostname. If that hostname only supports HTTP, the issue can occur before the browser reaches the HTTPS destination.
Can I fix this by changing a DNS record?
A DNS change by itself does not provide an HTTPS connection or a TLS/SSL certificate.
The hostname receiving the browser connection must support HTTPS and present a valid certificate. UltraDNS HTTPS Web Forwarding provides an HTTPS-capable forwarding endpoint when it is configured with an applicable certificate.
Can I use my own TLS/SSL certificate?
Yes. You can upload a valid certificate through UltraDNS Certificate Management and apply it to an HTTPS Web Forward.
Can UltraDNS manage the certificate for me?
Yes, when Automated Certificate Management is enabled for your account. UltraDNS and DigiCert manage certificate issuance, deployment, and renewal for the HTTPS Web Forward.
Is an expired-certificate warning the same as Ask-before-HTTP?
No. An expired, mismatched, or otherwise invalid certificate causes a certificate or connection error. The Ask-before-HTTP warning applies when Chrome cannot establish the secure HTTPS connection and would otherwise continue using HTTP.
URL Paths and Query Parameters
If your Web Forward must also preserve a URL path or query parameters, review the Relative Forward configuration for the record.
Path and query-string handling is configured separately from HTTPS forwarding. Enabling HTTPS does not automatically determine which parts of the incoming URL are added to the destination URL.