Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

browser oddity when using Let's Encrypt with 2 FQDNs #376

Open
reptilian-research opened this issue Mar 12, 2023 · 1 comment
Open

browser oddity when using Let's Encrypt with 2 FQDNs #376

reptilian-research opened this issue Mar 12, 2023 · 1 comment
Assignees

Comments

@reptilian-research
Copy link

reptilian-research commented Mar 12, 2023

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.

@daghf daghf self-assigned this Mar 14, 2023
@daghf
Copy link
Member

daghf commented Jun 7, 2023

Hi

I have not been able to reproduce this, and frankly it sounds like a browser issue.

In Chrome there is a "Always show full URLs" setting that may play into this. Could you try enabling that and report back?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants