Questions about let's encrypt

Hello, everybody,

i want to use let’s encrypt on my local ucs environment. I have read through with the corresponding blog post. But there are still questions:

  • I have several ucs systems (Master, Backup, Member1 … n). On which one do I install the app best? On the Master?

  • Do I understand correctly that I have to have an external domain for letsencrypt that can be publicly resolved? Example: I create a subdomain on our webserver ( which I forward to the fixed ip of the company network and specify it to letsencrypt?

  • we move our office at the turn of the year and definitely get a new permanent ip for the company connection. Is the change of ip a problem for letsencrypt?

best regards

Translated with

Hello @pixel,

It depends I would say. For which service do you need the certificates? So install it on the server hosting the service.


Yes, you specify this subdomain in the letsencrypt app

No - yes - well: you will change the ip-address on your hosted domain / subdomain to the new one and renew the certs from the app. Edit: actually I don’t think you have to renew it straight away - but it won’t renew if you don’t make that change… So long answer short: you have to change the ip-address correspondingly on the hosted domain - that’s about it. (Then the automatic renewal process will work)


I wanted to use encryption on all server systems:

  • KVM Host (UCS Slave) for UMC
  • KVM Guest (UCS Master) for UMC
  • KVM Guest (UCS Member) for UMC and Kopano Groupware
  • KMV-Guest (UCS Member) for UMC to Odoo
  • KVM-Guest (UCS Member) for UMC to Pascom

So do I have to install LetsEncryp on all systems?

For the systems you want to reach from outside of the office - so I guess the member servers?! The UCS Master will always be the CA for the domain(-services). Letsencrypt will work out of the box with Apache, Postfix and Dovecot.
Will you use a reverse proxy like haproxy with sni - which I think is recommended?
Edit: if you have multiple services you want to reach - perhaps it makes sense to register a subdomain per service - like this the configuration of the reverse proxy is easier too.

I’ve been thinking about it. What should help :slight_smile:

The UMC of all UCS systems don’t need LetsEncrypt. I dial into all UCS networks via VPN anyway and here the self-signed certificate should suffice. The same applies to the ERP.

So that will last:

  • NextCloud on the UCS master
  • Kopano on a UCS member

I got it right: On the Master it is needed in any case.

However, this cannot be used for multiple connections: -> Assignment to the fixed VDSL-IP
-> To the UCS master on NextCloud
-> To the member on Kopano

so be used with a single subdomain?

No - not in any case and I think it is - from a security standpoint - not advised to make the master server so easy to reach from the internet. That beeing said: for nextcloud it can make sense (apache service). But I would recommend moving nextcloud to either a slave or member server.

Letsencrypt will write valid certificates on the server hosting the app. The Letsencrypt-app will then also write - for apache - a new virtual host conf with these valid certs, one per subdomain.

Again - it depends on your router/firewall. If you use opnsense/pfsense, then you can use haproxy as reverse proxy through these appliances. If you don’t use a dedicated firewall distro - still - perhaps it makes sense to install a small debian/linux system and use it for haproxy.

It is not so much a question of one or more subdomains, but it is a question of the same port because Kopano Webapp and Nextcloud will race over port 443. This problem remains the same with one or two or three subdomains (because they will have the same ip-address).
A reverse proxy can however inspect the requested service and forward to the right server at its backend. And to set this up, it is easier - I think - with a subdomain per service. So nextcloud…de kopano or mail…de.

I use IPFire as firewall/router. I don’t know if it can be configured as reverse proxy. I have to check that.

If I understand it correctly I need a reverse proxy because the access to two services (NextCloud and Kopano) both run on the same port (443) but on two different internal servers.

Yes. (so that simple port forwarding isn’t enough)

while a reverse proxy is of course the better choice (since you then don’t need to handle/remember ports) port forwarding can be enough. its then only that you have access to nextcloud on e.g. domain:1234 and the kopano webapp on domain:2345.

edit I found the other sentence i wanted to refer to as well:

Just because the default certs of UCS are “self signed” (signed against the ca of your usc system) does not mean they are less secure than the certificates obtained from lets encrypt. its just that since other systems likely do not have your ucs ca imported you will get a warning that the certificate is not automatically trusted (which gives you the possibility to manually check if you want to trust the connection).

Okay, I’m gonna have to watch this in peace. That seems to be a bit more complex after all.

Yeah, that’s what I meant. I know in this case that I connect to “my” ucs.

Now I at least have an overview of how I have to proceed. Many thanks for the clarification :slight_smile:

I’d like to come back to that. We are in the new office with new fixed ip and don’t want to install letsenrypt now. The first scenario is as follows:

  • On the external web server *
    -> forward to the fix ip (office)

  • On the local firewall *
    Setting up haproxy as reverse proxy (in progress)

  • Local network *
    UCS Member with Kopano
    UCS Member with NextCloud

I install the Letsenrypt app on both member servers?

The external dns server…?

Yes, you can.
But the choice will depend on the configuration of the reverse proxy.

You have - as far as I can see - two main options.

  1. the letsencrypt certs are implemented on the web- and mailserver. Then the app has to be installed on both ucs systems. (think of port 80 on the firewall for the renewal of the certs)
  2. the letsencrypt certs are implemented on the reverse proxy, then you will have to install the letsencrypt solution of the firewall an generate certs there.

Best, Bernd

But that would also mean that you need to enable/forward port 80 for the individual system so that the automatic renewal will succeed.

There is also an addon for dehydrated for ipfire. dehydrated has support for “hooks” to further distribute certificates after they have been generated. I am doing the same in my home network:

I have dehydrated and nginx running on my openwrt router. dehydrated generated certificates for systems both in my network and outside of it. i have a hooks file with cases for different system so that when the ssl certificate for my nas is renewed files are copied via scp to the nas and then nginx on the nas is restarted as well.

If you choose for haproxy or nginx is in the end a bit of personal preference, I would choose nginx, though.