You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
In firefox, the issue presents differently:
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
configure hitch to use a pool of pem files:
modify the hitch-hook to put the bundle.pem into the appropriate dir
set up apache separate virtual hosts for all the above FQDNs, each with unique/identifiable content.
generate certs:
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
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.
The text was updated successfully, but these errors were encountered: