Follow-up from #1012's vhost-customization warning work.
Today the web server vhost's server_name, SSL certificate, and CA are all
derived from the same FOG-generated CA (createSSLCA(),
lib/common/functions.sh) that fog-client also uses to trust the server. The
two customizations admins actually make to the vhost in practice are:
- A custom
server_name (additional DNS names/aliases beyond the detected IPs)
- A custom CA/certificate for the public-facing web vhost (e.g. an internal
CA, or eventually Let's Encrypt)
Proposal: store these as their own settings, independent of the
fog-client-trust CA and the Secure Boot signing key, so an admin can put a
real/Let's-Encrypt-issued certificate on the web vhost without touching (and
without breaking) the certificate fog-client uses to trust the server.
This is real scaffolding work (new settings, install-flow branching, likely a
renewal hook for Let's Encrypt) -- not a small fix, and deserves its own
design pass before implementation. Not blocking #1012.
Follow-up from #1012's vhost-customization warning work.
Today the web server vhost's
server_name, SSL certificate, and CA are allderived from the same FOG-generated CA (
createSSLCA(),lib/common/functions.sh) that fog-client also uses to trust the server. The
two customizations admins actually make to the vhost in practice are:
server_name(additional DNS names/aliases beyond the detected IPs)CA, or eventually Let's Encrypt)
Proposal: store these as their own settings, independent of the
fog-client-trust CA and the Secure Boot signing key, so an admin can put a
real/Let's-Encrypt-issued certificate on the web vhost without touching (and
without breaking) the certificate fog-client uses to trust the server.
This is real scaffolding work (new settings, install-flow branching, likely a
renewal hook for Let's Encrypt) -- not a small fix, and deserves its own
design pass before implementation. Not blocking #1012.