Skip to content

feat(ssl): support multiple certificates per site #569

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

Open
wants to merge 2 commits into
base: 2.x
Choose a base branch
from

Conversation

J4Wx
Copy link
Contributor

@J4Wx J4Wx commented Mar 25, 2025

The rationale behind my desire for this change is explained here:
#557

So, what does this change do?

  • You can now have multiple SSL certificates activated per site.
  • Each certificate can be assigned to a set of domains (the main domain and each of the aliases are options).
  • Custom certificates can be edited so that you manage the domains assigned to use it.
  • Activating a new certificate for a domain/alias (or editing a custom domain to add a domain/alias) will remove that domain/alias from the assignment for other certificates.
  • The server {} block template has been moved from the usual vHost template so that it can be included programmatically with different variables. Each certificate will include it's own block, with the correct values set. A default non SSL block will be included too, supporting all domains.

What are the downsides?

  • Ultimately it can result in a really long vHosts file. I considered the alternative of using something like map $ssl_host_name $sslKey{{$site_id}} to dynamically load the SSL config, but that would require making each SSL cert readable by the configured user for that site (since dynamic loading would happen after nginx de-escalates it's permissions from root). This issue can be mitigated in future with the change from feat(redirects): add redirects to sites #552 - more sections of the config can be dynamically loaded and thus minimise change still.

Migration?

  • It doesn't change the location of certs or private keys, so existing vHosts files will continue to work as normal.
  • It leverages the already used domains field on the SSL table. So if an existing vHost is regenerated then it'll continue to work as normal.

@saeedvaziry
Copy link
Member

There has to be at least one domain provided when generating SSL. otherwise it will fail:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Plugins selected: Authenticator nginx, Installer nginx

Account registered.

Missing command line flag or config entry for this setting:
Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.
test.vitodeploy.com?

(You can set this with the --domains flag)

Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

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

Successfully merging this pull request may close these issues.

2 participants