Let's Encrypt

Discussion in 'Installation/Configuration' started by tom123, Oct 25, 2016.

  1. tom123

    tom123 Member

    Hi to all
    I was looking at Let's Encrypt support for ISP Config 3.1
    I've noticed this code in apache module:
    Code:
    $success = $this->_exec($letsencrypt . " certonly -n --text --agree-tos --expand --authenticator webroot --server https://acme-v01.api.letsencrypt.org/directory --rsa-key-size 4096 --email postmaster@$domain --domains $lddomain --webroot-path /usr/local/ispconfig/interface/acme");
    
    in a multiserver install, the interface is not present in the webserver, thus the webroot-path can't work.
    How do you manage let's encrypt in a muiltiserver install where the ispconfig interface is located on a different server?
    Shouldn't the webroot to be set as domain webroot ?
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    This code is absolutely ok, it works fine on multiserver setups when the ispconfig interface is not on the local server.
     
  3. tom123

    tom123 Member

    Can you explain how it works?
    If the webroot doesn't exist, certbot can't verify the certificate request.
     
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    The folder /usr/local/ispconfig/interface/acme is not a folder inside the webroot of the ispconfig interface, the webroot would be /usr/local/ispconfig/interface/web. The folder /usr/local/ispconfig/interface/acme exists on every ispconfig 3.1 server, no matter if it's a master or slave system and the ACME request get rewritten to that folder by an apache rewrite rule, see apache ispconfig.conf file and the vhost file of the website.
     
  5. tom123

    tom123 Member

    You are right, my mistake
    Some questions:
    1) why not using the site document root for the acme challenge?
    2) apache_ispconfig is only used when apache is installed. If nginx is the choosen webserver, there isn't any need for the /.well-known alias ?
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Because this has proven to be unreliable.

    This works as well for nginx of course.
     
  7. tom123

    tom123 Member

    Unreliable, why?
     
  8. till

    till Super Moderator Staff Member ISPConfig Developer

    Directory conflicts, users that alter directories as they have access to the web folder, non-existent directories when you create a new site and so on.
     
  9. tom123

    tom123 Member

    How do you manage more than 100 domains per certificate? In example, a Wordpress multisite install could have more than 100 domains set as aliases and this would issue a single certificate for the virtualhost. Let's Encrypt has an hard-limit set to 100. How do you handle this?

    Additionally, to enable SSL on each domain on the same server, should I set one IP Address for each domain?
     
  10. till

    till Super Moderator Staff Member ISPConfig Developer

    A vhost in apache and nginx can only have one ssl cert and if one ssl cert is limited to 100 domains by letsencrypt, thethe base website can havy only 100 lesetncrypts ecured domains, but you can add further domains as vhost alias domains which have their own vhost and therefore their own ssl cert, so the number of ssl domains that point to a website folder is nly limited by the hardware ressources of your system.

    Thats not nescessary anymore, all recent web browsers support SNI.
     
  11. tom123

    tom123 Member

    Ok.

    Ok.

    Another question, as I'm customizing a little bit: why are you putting the LE certificates in /etc/letsencrypt and then making a symlink to the user dir? Why not directly placing the certificates in the user dir? With the former case, would not be possible to share the /var/www directory on a shared storage creating a clustered installation, as each certificate is placed on each web server. In the latter case, you can share the whole /var/www directory and still have all certificates shared.
     
  12. till

    till Super Moderator Staff Member ISPConfig Developer

    That's the default directory from LE as far as I know. Mirror setups with LE are not easy anyway as LE runs just on one node when it creates or renews its cert and you have to ensure that the token that it creates is reachable from outside in realtime, so you have to either share /usr/local/ispconfig/interface/acme on all nodes as well e.g. with nfs or you change the rewrite rule that points to /usr/local/ispconfig/interface/acme on the slave nodes to rewrite to a URL on the master server instead of the local /usr/local/ispconfig/interface/acme directory
     
  13. tom123

    tom123 Member

    If you have a vhost with a password protection set to "/" (as many customers has here), the ".well-known" path would be password protected as the whole vhost and the certificate issue doesn't work.
     
  14. Jesse Norell

    Jesse Norell Active Member

    That probably depends on how/where you require a password. Eg. use a .htaccess file in the website root to configure password protection, and it won't affect the acme-challenge, as it's not under the document root. If you use Location to require a password, you might have to just do so conditionally (eg. LocationMatch !^/.well-known/acme-challenge or use conditional <If>'s).
     
  15. tom123

    tom123 Member

    in a shared hosting environment you dont always have control on what customers does, so you can't use the conditional
     
  16. Jesse Norell

    Jesse Norell Active Member

    You'll only have a problem with Location though, correct? There's already a Directory match that grants access via the path. So you put in a matching Location early in the config, before vhosts are read, and you can grant access ahead of customers doing otherwise, no?
     
  17. tom123

    tom123 Member

    Can you make an example? I've tried in many different ways with no success.
     
  18. Jesse Norell

    Jesse Norell Active Member

    This is untested, but should be just:
    Code:
    <Location /.well-known/acme-challenge/>
      Require all granted
    </Location>
    (apache 2.4, adjust accordingly). Put it early in the config, say /etc/apache2/conf-available/allow_letsencrypt.conf (and run 'a2enconf allow_letsencrypt').
     

Share This Page