Users browsing through the Umbrella Secure Web Gateway (SWG) proxy with HTTPS Inspection may receive more frequent 516 Upstream Certificate CN Mismatch error pages beginning in the second half of October of 2023.
The 516 error page occurs when a website's certificate does not match the domain name used by the client to access the site.
The increase in error pages is due to a change in the Chrome browser's handling of requests for URLs which use the HTTP (unencrypted) scheme. Chrome now attempts to load the resource with the HTTPS (encrypted) scheme first. When configured for HTTPS Inspection, SWG will inspect a website's certificate and return a web page displaying an error code such as 516 if the certificate is not acceptable.
To work around this issue, customers can configure their Web policies to bypass HTTPS Inspection for requests which otherwise result in 516 errors.
516 error background
In brief, the Umbrella Secure Web Gateway will return a 516 error page when the domain name used to access a website via HTTPS does not appear in the server's digital certificate. For additional information describing the reason for Secure Web Gateway returning a 516 error page, review the Umbrella Knowledge Base article "516 Upstream Certificate CN Mismatch" error.
For example, consider a site which serves content from HTTP URLs in the form: http://www.example.com/path_to_content. If a user requests the equivalent HTTPS URLs, but the site does not have a certificate whose SANs match “www.example.com” (perhaps the SAN only matches “example.com”) then the user will receive a 516 error if the request is handled by Umbrella’s Secure Web Gateway with a Web policy that uses SWG’s HTTPS Inspection feature.
Chrome behavior change
In the second half of October, 2023 Google completed the roll-out of a new feature for the Chrome browser. After that date, a request for an HTTP URL is automatically made using the HTTPS version of that URL. For example, when a user makes a request for http://www.example.com, Chrome will first try to fulfil the request using https://www.example.com.
If Chrome receives an HTTPS-related error when requesting the HTTPS URL, Chrome will then attempt to load the same content over HTTP. If the request for the HTTP URL is successful, Chrome will display an interstitial page with text indicating that the site is not secure and a link which gives the user the option to proceed, per the image below.
This is the fallback behavior in Chrome's new functionality.
However, when browsing via SWG with HTTPS Inspection, if the HTTPS request produces an HTTPS-related error such as ERR_CERT_COMMON_NAME_INVALID from the site, SWG will intercept the error and return an SWG error page to Chrome such as the 516 error page. This SWG content is not considered an HTTPS-related error by Chrome, so will not produce the fallback behavior, and the SWG error page will be displayed, rather than the page in the image above.
More information on the new Chrome behavior can be found from the Chromium blog:
and the feature's GitHub repository:
Determining the source of the error
Now that Chrome automatically promotes HTTP URLs to HTTPS URLs, websites which generate 516 errors are seen more frequently by users.
To confirm that a website is causing an HTTPS-related error such as the 516 response, browse the site with Chrome from a desktop system not using Umbrella. Be sure to manually enter the HTTPS version of the URL explicitly into Chrome's Omnibox (i.e. the address bar) rather than clicking on an HTTP hyperlink. If a hyperlink produced a 516 error with SWG, then manually requesting the HTTPS URL in Chrome without SWG should produce the error message ERR_CERT_COMMON_NAME_INVALID. This error message confirms that the issue is an incorrect certificate for the domain name used to access the website.
Alternatively, use an online tool such as as the Qualys SSL Server Test site to diagnose the problem with the website.
Umbrella administrators can workaround the issue with one of the following:
- create a Destination List specifically for these sites and add the list to a Web policy without HTTPS Inspection
- create a Selective Decryption List of sites which produce 516 error pages and add the Selective Decryption List to all relevant Web policies
Note that factors such as HTTP redirects or email security systems which substitute their service's HTTPS URLs for the original HTTP URLs may obscure the needed domain name. Identifying the correct domain name for a Destination List or Selective Decryption List may require investigation, including use of specific tools (curl, Chrome Developer Tools, an email security vendor's log, etc).
516 errors and email systems
An increase in 516 error frequency may result from email systems that display emails in HTML format and permit hyperlinks in the emails. When composing an email, if the sender types or pastes a domain name into the email body, many email systems will automatically promote a plain text domain name to a hyperlink. Typically, when the link is created, the scheme will be HTTP rather than HTTPS.
For example, typing the string example.com in an email may result in an email containing the HTML code <a href="http://www.example.com"> which will be displayed as the hyperlink www.example.com.
If a recipient of such an email clicks on that HTTP hyperlink, the request will initially use HTTPS if the click opens Chrome, or if Chrome is already being used to view the email (note that other browsers also may promote HTTP to HTTPS). Additionally, a hyperlink in an email that intentionally uses the HTTP scheme will be handled similarly.
Some common cloud services send emails from their 3rd-party transactional email service providers with HTTP hyperlinks rather than HTTPS hyperlinks. The HTTPS site that Chrome automatically attempts to load may respond with a certificate error to the domain name in the email link. For example:
When these emails have large recipient lists, many users whose clicks (i.e. requests) are sent via SWG may report errors such as the 516 error. Please contact your email service provider or the organization which sent the email to have the certificate error addressed.