How can I route incoming 443 SSl requests to 8443, or otherwise leave 443 to my other server. Have owncloud, openproject and openoffice need SSL but cant use 443 already inuse on domain


Have owncloud, openproject and openoffice need SSL but cant use 443 already in use on domain. I have purchased a domain name to point to the server, and need to finalize it and bind it to the univention apache server running the apps inthe domain. It is a Windows AD domain, and the UCs is a backup domain controller.

I am somewhat familiar with modifying apache conf files but am not sure which ones I should modify in order to keep owncloud, open office and open project all talking together. I need owncloud and openoffice (or collabora) talking to each other and available from the internet. I have a solid domain with one static IP, and a sonic wall. I have an SSL-enabled server already running on the network which I do not want to disturb.

I am able to forward through the sonicwall to the server, but it pulls away from the other server on port 443. I am debating changing the port in Apache to listen for 8443, but not sure if that will work with the other apps on the server (owncloud/openoffice/openproject). I am wondering if a reverse proxy is the way to do it.

I need to get an SSL certificate (have Lets Encrypt installed, unused so far) established with the new domain name pointing at the univention address which is stable and running on the network, just no SSL. this makes owncloud not work with OpenOffice or Collabora even on the network. It works from the Univention KDE desktop fine, allows creation of new documents and spreadsheets from within owncloud, but will not create or open from owncloud on network clients which fully see the rest of the UCS platform fine

I have UCS 4.3-2 errata229

Thank you



You must not mix Windows-based AD DCs and Linux/Samba-based AD DCs in the same domain. Not only isn’t it supported by Univention, it also simply won’t work properly. Most pressing concern is lack of sysvol synchronization between WIndows-based AD DCs and Samba-based AD DCs: meaning your GPOs, for example, will only ever reside on your Windows AD DC and never get synced to your Samba AD DC. Your Samba AD DC is therefore not a full AD DC.

The situation would be different in a pure Univention environment as Univention has implemented a sysvol synchronization mechanism between all UCS-based Samba AD DCs, meaning that an environment consisting of multiple UCS Samba AD DCs is completely fine. Just don’t mix Windows-based and Samba-based ones.



Ah yes, I suppose it is in its own domain now just attached to my main domain - I am pretty noob with linux, but I did choose the ‘join windows domain’ option and it uses ad-connector (is active), and I never installed domain-takeover, but it seems to identify itself as a domain controller in some places. I was wondering this myself, but it sees the active directory fine and everything is running solid for weeks now with owncloud, collobara and open project so far. Trying to get it to listen to port 8443 instead of 443 to use ssl without blowing the whole stack ugh


This might be a challenge as even if you manage to change the listen port there are lots of scripts, internal as well a scripts that will handle the integrations, that simply assume https on 443.
I’d rather look into changing the portforwarding on the Sonicwall to map outside 8443 to 443 on the UCS.


This. Just using a different port on the firewall “should” safe you the headaches of changing ports inside of Univention.


This will get you the furthest in user acceptance. Users don’t want to remember to add a :8443 behind every address they type. they just want to type the address. You should then probably use a dedicated subdomain for everything running on Univention.


ahh good point … so this would basically use my WAN ip with the :8443 translated to the LAN ip :443 to univision - nice. Now if I have the FQDN purchased and pointing at the WAN:8443, then this will still just use the domain name purchased by customer? So > WANip:8443 > SonicWall > LANip:443 >UCS and all works swell with no days in purgatoryportfix? OR is this where I use Squid to create a reverse-proxy? Sorry for my ignorance, I havent set a reverse-proxy up before…I did install Squid in UCS, as well as Lets Encrypt, which will be the final step I am thinking, to get the SSL set for this connection.


So by default, do the ucs ip address and its dependent ip addresses (owncloud-collabora, etc) constitute a sub-domain to the main domain, or do you mean I need to define something in the sonicwall or in the main domain AD? Thanks!


good point! This is what i was afraid of


No that was not really what I was referring to. I was talking about domains in a Web context, not ad context. I give you a concrete example:

In my home network I have a few devices that provide webinterfaces. There is for example my nas, but also a raspberry pi. I have a router running openwrt and on that router I have nginx running. All traffic on port 80 and 443 from the outside world terminates on that nginx instance. If there is a request for the request get proxied to my nas, if there is a request for it get proxied to the pi. That functionality is referred to as a reverse proxy.

Ps: instead of trying to achieve this with squid on the Univention host, I’d rather recommend to either solve this on your firewall (if possible) or on the system that currently receives your http traffic. Good tools for reverse proxies are nginx, or if you want something dead simple (which also takes care of automatic https) caddy.


Can you elaborate on why instead of trying this with squid on the Univention host, I should try it on the http host? It looks like I cant do it on their shared platform, but would need a dedicated server … at that point it might be better to purchase another ip address instead? I was hoping Squid could do it from the server itself, and then I could also use Lets Encrypt for the SSL … if not, do you know of any free reverse-proxy options per chance. edit. It looks like the SonicWall does do web proxies - looking into it now


I see - so something like, and then use a wildcard certificate to allow for both? I have the domain site ( hosted on an internal Windows Server 2008R2 IIS 7, and it has a single paid SSL certificate installed…it runs a version of owncloud 8 linked to an externally-hosted website. This domain name is different than the internal domain name which the ucs server ends in (
I have this UCS server with open project, owncloud, etc, running great (finally) on the network behind the same sonicwall firewall as this other site . There is an external .com which I need to point to the final production version, so the I now can only access from behind the firewall would then map to just like the internal address of my Windows server does? Would the ucs apache server then register the SSL for all the base services, owncloud, collabora, etc?


this is of course also possible with Apache, see

In fact this is how most of not all dockerised Univention apps are available from the host itself.

I (personally) just would not do it with Squid.

I must say you have lost me.

Lets dumb this all down. Since you want to use letsencrypt for ssl its the easiest if you configure your firewall to have port 80 and 443 coming out on your univention system (instead of your old windows server). we’ll then use the apache on the univention host to proxy all requests to your old domain to the windows system. for this you basically only have to put create the file /etc/apache2/sites-available/old-server.conf with below content (and activate it with a2ensite old-server afterwards):

<VirtualHost *:80>

        ErrorLog ${APACHE_LOG_DIR}/proxy-error.log
        CustomLog ${APACHE_LOG_DIR}/proxy-access.log combined

        # Enforce HTTPS:
        RewriteEngine On
        RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
        RewriteCond %{HTTPS} !=on
        RewriteRule ^/?(.*)$1 [R,L]

<VirtualHost *:443>
        SSLEngine on

        SSLCertificateFile /etc/univention/letsencrypt/signed_chain.crt
        SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
        SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem
        SSLCertificateChainFile /etc/univention/letsencrypt/intermediate.pem

        ErrorLog ${APACHE_LOG_DIR}/proxy-error.log
        CustomLog ${APACHE_LOG_DIR}/proxy-access.log combined

        ProxyPass / http://ip-of-windows/
        ProxyPassReverse / http://ip-of-windows/

        ProxyPreserveHost On
        ProxyRequests Off

In the above snipped you have to replace values of the SSL config settings with references to your bought certificate (or use it as it is and configure the lets encrypt app to issue the certificate with windows hostname as a san entry.


thanks again for this, working on it this week.


Ok - well I have this all setup and it does come into the Univention server just fine but does not forward to the new subdomain. It just ends on the univention too, even with this file in place … should I include the www in the domain name of the server being directed to?

I was able to activate it with a2ensite, and it says it is active (old-server.conf), but still no redirect, both URLs terminate on same server - must have missed something but cant find it

thanks for your help


Hi @mediadev,

can you post the vhost that you are now using exactly (ideally without changing the domainname) and the domain it should act on? There is probably a mismatch there.


ok - so I had left the name of the file as old-server.conf, not being familiar with the naming convention of apache2. I changed the name of the file to the actual name of the subdomain, and it appears to be trying to route it but it lands on with error. I had ran Lets’ Encrypt from the univention portal, and it seemed to have gotten the SSL cert, but this was when that config file was named wrong. Do I need to run the Let’s Encrypt again? Neither Univention or Windows is showing SSL secured, but I have also not figured out how to import from the Univention server to the Windows 2008 R2 IIS 7 instance which is hosting the subdomain (has owncloud 8 running)

I entered it pretty much exactly as specified above, changed to relevant domain … I have a couple things left to do and then will update!


The filename does not matter.

No, if the lets encrypt app ran successful with the desired name in the domains list its not necessary to run it again. (it will not make a difference and it will actually only detect that the desired certificate already exists and is still valid for a long enough peroid).

I don’t understand. What are you trying to import? Why? The Univention host will do ssl for the windows server.

We will see once you deliver some testable evidence.