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

Lighttpd vhost problem #3707

Closed
PanosssD opened this issue Aug 7, 2020 · 7 comments · Fixed by #3734
Closed

Lighttpd vhost problem #3707

PanosssD opened this issue Aug 7, 2020 · 7 comments · Fixed by #3734
Milestone

Comments

@PanosssD
Copy link

PanosssD commented Aug 7, 2020

Hello.
Dietpi on PC.
I use it for wordpress web server with Lets Encrypt etc.
I just tried to add a vhost (i already have 3 vhosts working ok) but after setup (db,vhost on conf-enabled,ssl with certbot) when i visit the site it says that ssl is invalid because it reads ssl from letsencrypt.conf and not from e.g example.com.conf.
Anyone knows why is it happening.
And i want to test if issue happens because of mods in lighttpd.conf
Did anyone have the default lighttpd.conf file for dietpi

@MichaIng
Copy link
Owner

MichaIng commented Aug 8, 2020

Many thanks for your report.

Your run all vhosts on different ports? /etc/lighttpd/conf-enabled/letsencrypt.conf is the 443 vhost, hence will always be in charge when a request to port 443 is incoming, in no other case.

If you enabled it, there is /etc/lighttpd/conf-enabled/redirect.conf which redirects HTTP to HTTPS for all vhosts/ports but it should preserve the vhost/port. But I never tested it myself to be true, hence you might want to test if the issue appears as well if you explicitly connect via https://.

@PanosssD
Copy link
Author

PanosssD commented Aug 8, 2020

All vhosts conf files start with $HTTP["host"] == "example.com" {
they are on the same (443) port but it goes by hostmane e.g you look for

  • (public IP) = you get nothing
  • example1.com = you get example1.com page
  • example2.com = you get example2.com page
  • etc

in each conf file there is

  • server.document-root = "/var/www/.../.../wordpress" # Document-root of the webserver
  • accesslog.filename = "/var/log/lighttpd/example1_access.log" # Web server Access log file
  • server.errorlog = "/var/log/lighttpd/example1_error.log" # Web server Error log file
  • ssl.pemfile = "/etc/letsencrypt/live/example1.com/combined.pem"
  • ssl.ca-file = "/etc/letsencrypt/live/example1.com/fullchain.pem"

example1,2,3 .conf files are placed inside conf-enabled directory

Is there any place to find default files that dietpi uses for:

  • /etc/lighttpd/conf-enabled/redirect.conf
  • /etc/lighttpd/conf-enabled/letsencrypt.conf
  • /etc/lighttpd/lighttpd.conf
    ???
    I want to test if the problem is happening e.g. from bad configuration that i 've made, limitation of lighttpd or dietpi
    And i want to remind you that i 've already setup 3 vhosts working properly. On 4th and 5th problem starts to appear.

@MichaIng
Copy link
Owner

MichaIng commented Aug 8, 2020

Okay so since all your vhosts listen on 443, letsencrypt.conf is used for all of them. I'm not 100% sure which directive overrides which one ($SERVER["socket"] vs $HTTP["host"]) or if its only a question of alphabetical order.

If you have HTTPS redirect active, easiest is probably to:

  • Comment those two lines in letsencrypt.conf:
    ssl.pemfile = "$fp_cert_dir/combined.pem"
    ssl.ca-file = "$fp_cert_dir/fullchain.pem"

    So it contains only the SSL config that shall be used across all vhosts.
  • Wrap your vhosts into $SERVER["socket"] == ":443", so they're HTTPS-only, while redirect.conf redirects all plain HTTP requests. Although you say "they are on the same (443) port", so this seems to be already the case?

@PanosssD
Copy link
Author

PanosssD commented Aug 8, 2020

I make some test before your answer.
I read the so obvious README file inside /etc/lighttpd/conf-available/
which says:

If you want to create your own files they names should be build as nn-name.conf where "nn" is two digit number (number is used to find order for loading files)

So i 've renamed all files for vhosts including redirect & letsencrypt.conf with "nn-" at start and thats it!!!
And to mention: the problem doesn`t exist when 3 vhost enabled but after 4th vhost it reads ssl (only for vhost 4, the others are working ok) from letsencrypt.conf causing invalid certificate error.
BTW thank you for your help!

@MichaIng MichaIng added this to the v6.32 milestone Aug 8, 2020
@MichaIng
Copy link
Owner

MichaIng commented Aug 8, 2020

Okay so this means the alphabetical order of your configs was like this?:

  1. example.conf
  2. letsencrypt.conf
  3. next.example1.conf
  4. next.example2.conf
  5. next.example3.conf

next.exampleN.conf vhosts were parsed after letsencrypt.conf, hence their ssl.pemfile + ssl.ca-file were effective.
example.conf vhost was parsed before letsencrypt.conf, hence its ssl.pemfile + ssl.ca-file was overwritten and ineffective?


Those file names were never touched since the initial dietpi-letsencrypt creation while meanwhile we follow the nn- priority-naming convention. It makes sense to give this global letsencrypt.conf a pretty low priority (i.e. 00-letsencrypt.conf if no module ships related directives with higher priority) so that any custom vhost/config overrides it.
redirect.conf on the other hand needs to have highest priority (i.e. 98-redirect.conf, to still allow admin overrides via 99-) to effectively redirect each and every non-HTTPS request.

@PanosssD
Copy link
Author

PanosssD commented Aug 8, 2020

Exactly!!! The names were:

  1. blog.example (not working)
  2. eshop.example (not working)
  3. letsencrypt
  4. mail.example (working)
  5. (naked domain starting with s) (working)
  6. etc (working)

You can use 50-redirect.conf if anyone wants an ascending order for vhosts there is some space before and after, and if someone don't bother 50 or 99 he goes either way after redirect.conf

@MichaIng MichaIng linked a pull request Aug 25, 2020 that will close this issue
2 tasks
@MichaIng
Copy link
Owner

Done: #3734
Renaming those on running systems, accidentally merged into dev directly 😄: 5e993ec

@MichaIng MichaIng added the Solution available 🥂 Definite solution has been done label Aug 25, 2020
@MichaIng MichaIng mentioned this issue Aug 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants