browser oddity when using Let's Encrypt with 2 FQDNs

When using a letsencrypt cert with two or more FQDNs, the browser seems to show the first specified FQDN.

This does not occur with a letsencrypt cert with a single FQDN.

In chrome, the issue presents as:

enter the second FQDN into the "URL bar"
browser gets the page and displays it
browser "URL bar" reverts to the first FQDN (visually)
if you click the "URL bar", (ie refresh) it shows the second FQDN, and again reverts the display to the first FQDN

In firefox, the issue presents differently:

enter the second FQDN into the "URL bar"
browser gets the page and displays it
browser tab title is displayed as the first FQDN
the "URL bar" retains the second FQDN

Expected Behavior

i would expect that the browser would continue to work with the specified FQDN. the only linkage between the first and second FQDN is the lets encrypt cert. when only one FQDN is in the cert, this behaviour is not exhibited

Current Behavior

with an incognito browser tab in chrome: go to: https://www2.lab.reptiles.ca note that the A HREF inherits the appropriate Host: go to: https://www.lab.reptiles.ca note that the A HREF inherits the appropriate Host: note that the URL bar is now showing lab.reptiles.ca hit shift-refresh note that the A HREF still shows the previous Host: note that the URL bar is still showing lab.reptiles.ca

perform the same with firefox, but observe the tab title

Possible Solution

i'm unsure of the interaction between hitch and varnish, but, it appears that something is being passed from hitch to varnish relative to the data in the cert.

Steps to Reproduce (for bugs)

set up varnish to forward to an internal web server for a variety of FQDNs

backend www_lab_reptiles_ca {
    .host = "10.10.101.10";
    .port = "8080";
}

sub vcl_recv {
if ( req.http.host == "www2.lab.reptiles.ca") {
        set req.http.X-Host = req.http.host;
        set req.backend_hint = www_lab_reptiles_ca;
        return (pass);
}
}

sub vcl_recv {
if ( req.http.host == "www3.lab.reptiles.ca") {
        set req.http.X-Host = req.http.host;
        set req.backend_hint = www_lab_reptiles_ca;
        return (pass);
}
}

sub vcl_recv {
if ( req.http.host == "www4.lab.reptiles.ca") {
        set req.http.X-Host = req.http.host;
        set req.backend_hint = www_lab_reptiles_ca;
        return (pass);
}
}

sub vcl_recv {
if ( req.http.host == "www.lab.reptiles.ca") {
        set req.http.X-Host = req.http.host;
        set req.backend_hint = www_lab_reptiles_ca;
        return (pass);
}
}

sub vcl_recv {
if ( req.http.host == "lab.reptiles.ca") {
        set req.http.X-Host = req.http.host;
        set req.backend_hint = www_lab_reptiles_ca;
        return (pass);
}
}

configure hitch to use a pool of pem files:

# Listening address
frontend = "[*]:443";

# Upstream server address
backend = "[localhost]:8443"

# load all /usr/local/etc/hitch/certs/*.pem files
pem-dir = "/usr/local/etc/hitch/certs/"
pem-dir-glob = "*.pem"

# the protocols we care about
alpn-protos = "h2, http/1.1"

# numbers of processes to start, usually one per CPU
workers = 4

# run as the the hitch:hitch unprivileged user
user = "hitch"
group = "hitch"

ocsp-dir = "/var/cache/hitch"

# use PROXY protocol v2
write-proxy-v2 = on

modify the hitch-hook to put the bundle.pem into the appropriate dir

#!/bin/bash
# Full path to pre-generated Diffie Hellman Parameters file
dhparams=/usr/local/etc/hitch/dhparams.pem

if [[ "${RENEWED_LINEAGE}" == "" ]]; then
    echo "Error: missing RENEWED_LINEAGE env variable." >&2
    exit 1
fi

FQDN=$(basename ${RENEWED_LINEAGE})
HITCHCERTS=/usr/local/etc/hitch/certs

umask 077
cat ${RENEWED_LINEAGE}/privkey.pem \
${RENEWED_LINEAGE}/fullchain.pem \
${dhparams} > ${HITCHCERTS}/${FQDN}-bundle.pem

set up apache separate virtual hosts for all the above FQDNs, each with unique/identifiable content.

generate certs:

# this one exhibits the behaviour
$ certbot certonly --standalone --preferred-challenges http --http-01-port 8080 -d lab.reptiles.ca -d www.lab.reptiles.ca --deploy-hook="/usr/local/etc/hitch/hitch-deploy-hook --post-hook="service hitch reload"

# this one works as expected
$ certbot certonly --standalone --preferred-challenges http --http-01-port 8080 -d www2.lab.reptiles.ca --deploy-hook="/usr/local/etc/hitch/hitch-deploy-hook" --post-hook="service hitch reload"

# this one will over-write the first one, but, will cause the behavior to become "normal" for the 3rd FQDN, but still exhibits the original behaviour for the second FQDN
$ certbot certonly --standalone --preferred-challenges http --http-01-port 8080 -d lab.reptiles.ca -d www.lab.reptiles.ca -d www4.lab.reptiles.ca --deploy-hook="/usr/local/etc/hitch/hitch-deploy-hook" --post-hook="service hitch reload"

Context

as best i can tell, this only effects the display (URL bar in chrome, and tab title in firefox)

this could be misleading/confusing for the end-user.

seems to be an unintended side-effect.

Your Environment

Version used: 1.7.3
Operating System and version: FreeBSD 13.1
Source of binary packages used (if any) FreeBSD packages

the varnish config is vanilla punting incoming PROXY traffic from hitch, and passing it through to an apache server.

the apache server is a vanilla config, listening for virtual hosts on 8080. the apache config is not attempting to update/control the title of the page.

varnish / hitch