Topic: Thoughts on letsencrypt.com?

[guest22]

If using the webapps-common contrib to create a subdomain (e.g. chat.myserver.local), the Letsencrypt script will fail for the chat.myserver.local domain. This is because the ProxyPassTarget property will forward to another http server instead of the SME Server apache.


Any thoughts on how to prevent the (cron job or manually) fail?

[CharlieBrady]

Update the contrib so that the letsencrypt URL goes to the right place.

[ReetP]

Think there are a few things to be looked at.... sub domains themselves work with the letsencrypt contrib. But I tried to keep it simple... complexity can accelerate away.

The issue is the way rocketchat works.

Couple of thoughts...

For letsencrypt the sub domain has to have a http reachable .wellknown directory

Rocket works on 3000. We are using the proxy mod to enable https redirection/access to http :3000

My suggestion would be when creating the rocket account we set the default ibay as Primary.

Then use a redirect rule that ONLY redirects httpS calls to port 3000

Standards http calls to 80 go as normal to Primary (and possibly limit it to calls to .wellknkown with everything else going to http:3000)

That may be a far simpler solution.

In any event I have no idea what nodejs/rocket considers its 'base' directory so it's tricky to know where to add a .wellknown directory.

I think this is a configuration that needs to be solved in rocket rather than letsencrypt.

Rgds
JC

[guest22]

I think this is a configuration that needs to be solved in rocket rather than letsencrypt.

Maybe, but looking at a 'lower level' (before the https request that hits rocket) it passes Apache. So if webapps-common can take into account how to cope with httpS requests to letxencrypt it would be solved I guess.. It already does to for normal http requests and takes letsencrypt into account.


All maybe here..


Maybe Daniel can share his thoughts?

[ReetP]

Yes, either in web apps or via the redirect required for rocket.

I believe JPP was going to try and rewrite stuff to allow for letsencrypt out of the box. The whole thing is in a state of flux right now.

I still think for now an apache template for rocket would be easiest.... each contrib sorting out its own vagaries or special requirements. It can then be backed out if other things come to fruition. Unfortunately I am (freezing myself) in the UK next week so won't have any time to play but should be ok thereafter

Rgds
John

[DanB35]

If using the webapps-common contrib to create a subdomain (e.g. chat.myserver.local), the Letsencrypt script will fail for the chat.myserver.local domain. This is because the ProxyPassTarget property will forward to another http server instead of the SME Server apache.

This is not correct, at least for me when using John's RPM for letsencrypt.sh.  I don't think I can explain why, but I was able to obtain a LE cert for chat.mydomain without a problem.

[ReetP]

Think it is a case of YMMV

What HSF has had an issue with is running a subdomain with rocket chat and mod proxy to redirect calls to the subdomain. I noticed this myself.

I believe the solution is to make a better http template for rocket as above.

[Daniel B.]

If using the webapps-common contrib to create a subdomain (e.g. chat.myserver.local), the Letsencrypt script will fail for the chat.myserver.local domain. This is because the ProxyPassTarget property will forward to another http server instead of the SME Server apache.

The WebAppVirtualHost templates provided in webapps-common has a prop to control what to do with this. When you create a virtualhost with a ProxyPassTarget, you can set the ProxyPassACMEChallenges prop. Valid values are:

• disabled: (default): do not proxypass ACME challenges requests to the target. The requests are handled by apache directly
• only: only forward ACME challenges to the target. Everything else is served by apache directly
• enabled: forward everything to the target, including ACME challenges

So, your issue is not that ACME challenge requests (/.well-known/acme-challenge/) are forwarded to the target (they are not). It's because there's no alias to handle it in the virtualhost. This should be added in the Letsencrypt contrib. It's just a matter of adding somthing like

Code: [Select]

Alias /.well-known/acme-challenge/ /path/to/the/acme/challenge/dir


[DanB35]

What HSF has had an issue with is running a subdomain with rocket chat and mod proxy to redirect calls to the subdomain. I noticed this myself.

I understand that.  I'm running the same combination, and obtaining the LE cert works for me.  Obviously there's something different between our setups (and in light of Daniel's post, maybe that's that I'm running a newer version of webapps-common than you two), but it's not universally the case that following the Rocket.chat instructions will cause LE cert issuance to fail.

[ReetP]

Think I have twigged something. In the letsencypt contrib I think I have missed a trailing slash in the file /etc/e-smith/templates/etc/httpd/conf/httpd.conf/VirtualHosts/40ACME

It is currently like this:

Code: [Select]

# Alias for letsencrypt
Alias /.well-known/acme-challenge /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
 I think it should be like this:

Code: [Select]

# Alias for letsencrypt
Alias /.well-known/acme-challenge/ /home/e-smith/files/ibays/Primary/html/.well-known/acme-challenge
That matches the proxypass ignore line

Code: [Select]

ProxyPass /.well-known/acme-challenge/ !

and I can then get to this URL without Rocket interfering :

http://chat.reetspetit.info/.well-known/acme-challenge/

Can someone test/advise if this is right please ?

B. Rgds
John

[ReetP]

For those who are interested....

I have updated the basic letsencrypt rpm with v2 of the script. Unfortunately due to an act of complete stupidity on my part I misnumbered the contrib originally so have had to bastardise it a bit.

New version is letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch.rpm

v8 : https://www.reetspetit.com/smeserver/5/noarch/letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch.rpm
v9 : https://www.reetspetit.com/smeserver/6/noarch/letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch.rpm

You can try yum --enablerepo=reetp clean metadata and then install. If not you might need to wget and yum localinstall to force it to update

I will patch the missing trailing slash in 40ACME for the smeserver-letsencrypt contrib shortly - still thinking how to do an 'all' for all domains/hosts.

[DanB35]

I have updated the basic letsencrypt rpm with v2 of the script.

Strange, looks like it isn't seeing the config file any more:

Code: [Select]

[root@e-smith ~]# letsencrypt.sh -c
#
# !! WARNING !! No main config file found, using default config!
#
ERROR: WELLKNOWN directory doesn't exist, please create /usr/local/bin/.acme-challenges and set appropriate permissions.
[root@e-smith ~]# cd /etc/letsencrypt.sh/
[root@e-smith letsencrypt.sh]# ls
certs  config.sh  domains.txt  private_key.pem
[root@e-smith letsencrypt.sh]# rpm -qa | grep letsencrypt
letsencrypt.sh-0.0.9.160523.gitd5b2858-1.noarch
smeserver-letsencrypt-0.2-2.noarch
[root@e-smith letsencrypt.sh]#
Edit: Almost looks like it's looking for config, not config.sh:

Code: [Select]

# Setup default config values, search for and load configuration files
load_config() {
  # Check for config in various locations
  if [[ -z "${CONFIG:-}" ]]; then
    for check_config in "/etc/letsencrypt.sh" "/usr/local/etc/letsencrypt.sh" "${PWD}" "${SCRIPTDIR}"; do
      if [[ -e "${check_config}/config" ]]; then
        BASEDIR="${check_config}"
        CONFIG="${check_config}/config"
        break
      fi
    done
  fi

Edit 2:  And indeed, that's what's happened:  https://github.com/lukas2511/letsencrypt.sh/commit/d5b285868e35992027599d25411d80dfd0bf1048

[guest22]

Edit 2:  And indeed, that's what's happened:  https://github.com/lukas2511/letsencrypt.sh/commit/d5b285868e35992027599d25411d80dfd0bf1048

Good catch!


edit: wiki page adapted.

[ReetP]

Ahhhh good one Dan. I'll update my contrib too.

Buggers...... why can't they just leave alone ?

[DanB35]

For the time being, I just made a symlink (ln -s config.sh config), which seems to be working.