-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add support for wildcard certificates #19
Add support for wildcard certificates #19
Conversation
|
||
If your production Islandora site is using a wildcard certificate that is not provisioned by LetsEncrypt, your DNS entries for your subdomain `DOMAIN` may need to be at the same level as your wildcard's top level domain (TLD). | ||
|
||
For example if your wildcard cert is for `*.library.world.com` and your islandora site is at `islandora.library.world.com`, to have your `activemq`, `blazegraph`, `fcrepo`, and `solr` subdomains use the same TLS certificate, they will need to be children of `library.world.com`. To accomplish this, you can change the subdomain delimiter in your `.env` to use a dash (-) instead of a period (.). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused reading this. If I used a dash, would I not get activemq-library.world.com
? I think I must be misreading this, and I'm hoping we can clarify the wording.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I used a dash, would I not get activemq-library.world.com
DOMAIN
is set to the drupal site. In the example, islandora.library.world.com
.
With a dash (-
) the fcrepo/activemq/etc. domains would then be activemq-islandora.library.world.com
. These get set in the docker-compose.yml
activemq-islandora.library.world.com
is a child domain of library.world.com
so would be able to serve TLS connections from a wildcard cert with *.library.world.com
(as would islandora.library.world.com
)
When using a period, that results in activemq.islandora.library.world.com
which would need a wildcard cert for *.islandora.library.world.com
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to say, I'm not a fan of adding any additional complexity to this repository. It's meant to be as simple and with as little features as possible to limit the testing surface and therefore the maintenance burden.
It is to act as a starter template that can then be modified to each institution's needs, without the committers taking on those maintenance burdens.
That being said, in the use case you outline, you are not actually using a wildcard certificate for *.islandora.library.world.com
, instead you are using a wildcard certificate for *.library.world.com
. Which would mean the base DOMAIN
should be library.world.com
. This doesn't have anything to do with LetsEncrypt
as is claimed in the changes to README.template.md
.
If, for some reason, you are unable to generate a wildcard certificate at the appropriate level, you could achieve your desired result by changing DOMAIN
to be library.world.com
and modifying drupal
, matomo
, and cantaloupe
traefik labels to based on the subdomain islandora.library.world.com
, similarly to how solr
is set up if so desired.
Of course, such changes should not be made to this repository, but rather your institution's repository created from this template as the workaround is for your specific institution.
Makes sense re complexity. Though just for clarification:
It is isle-site-template/docker-compose.yml Lines 675 to 683 in afa3e82
|
For sites that might utilize a wildcard TLS certificate, having the fcrepo/activemq/etc. domains be children of the drupal domain will not allow the same wildcard certificate to be used. This PR makes those subdomains the same level as the drupal domain, while keeping the default the way it was before.
Would be ideal if
-
could simply replace.
as the subdomain delimiter, but opted to send this PR to support both in case.
is a hard requirement for some use cases.