How can I route incoming 443 SSl requests to 8443

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 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

Hey,

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.

m.

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.

but

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.

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!

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 nas.my-domain.com the request get proxied to my nas, if there is a request for pi.my-domain.com 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 https://www.youtube.com/watch?v=N8unGhLNdKM - looking into it now

I see - so something like cloud.mydomain.com, and then use a wildcard certificate to allow for both? I have the domain site (www.mydomain.com) 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 (ucs.myinternaldomain.com).
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 ucs.myinternaldomain.com I now can only access from behind the firewall would then map to www.cloud.myexternaldomain.com 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 https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension

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>
        ServerName      cloud.myexternaldomain.com

        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 ^/?(.*) https://cloud.myexternaldomain.com/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
        SSLEngine on
        ServerName cloud.myexternaldomain.com

        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
</VirtualHost>

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.

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.

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.

When visiting this domain I get a valid letsencrypt certificate (valid for bdcloud.belldesigncloud.com and belldesigncloud.com). It shows a 404 error that does not look like its coming from Univention. So I would say the reverse proxy seems to work.

unless your univention is belldesigncloud.com then the hostname for the univention system seems to be missing in the certificate. I would still say that you don’t need to export the ssl certificate and install it on the windows system since Univention can now handle all ssl stuff for you. if you still want to you find all the filenames of the ssl certificate in the apache vhost you just installed. (but remember that if you decide to go for this route, you need to repeat this every 2-3 months since letsencrypt certificates are only valid for three months).

the apache vhost for the proxy is only for bdcloud.belldesigncloud.com not **www.**bdcloud.belldesigncloud.com. In fact if I visit this domain from here I get the univention page.

no, this is for the single sign on login page of univention.

this is since the command will only show the certificates created from the univention internal ca, not the certificates from lets encrypt.

On it! Thank you much, was just looking for this. edit. Well tried that still no luck.

This is afaik already set by the lets encrypt app.

Hello again - well I kept playing with it,using your script, and it seems very close. I am able to get to the front door of owncloud now, but still with errors and no SSl on either site. I just cant figure out what is going on. https://www.bdcloud.belldesigncloud.com/

It seems to be proxying from the Univention at belldesigncloud.com but just wont secure either one.

Hi @mediadev,

as by your (by now deleted) previous post the help such a community forum can provide does not really seem to get you any further. If you have a support package from Univention I would recommend to get into contact with them. If you don’t then getting into contact with a (local) Univention partner (you can find one at https://www.univention.com/partners/find-partners/) could be potentially cheaper and this partner could provide you with a ready to run solution.

You are using this tone and then are really wondering why just a single user is willing to help you? Anyways my suggestion to get some professional help for your setup was serious, I have no clue why its nor working how its suppoesed to (btw. i really doubt that when you do not get it running with lets encrypt, then some paid for certificate will make a difference).

I’m out.
/unsubscribe

tl;dr
Thanks again for the script, it was a great help. Looks like I was using an A record when I needed a CNAME - sorry for the earlier interaction was a misunderstanding on my part.

edited to clear my earlier posts up:
the script did in fact take care of the problem of directing SSL traffic as a reverse-proxy
(using Lets Encrypt SAN with 4 entries does lock both domains now)
to a windows server 2008R2 instance hosting an owncloud version once I added the proper CNAME record in my DNS records to match the subdomain, and sanitized IIS7.5 of all bindings to 443 and flushed the old SSL paid cert thoroughly. The main domain did not bind to port 443 so wouldnt lock, and just needed another xyz.conf file added to the sites-enabled folder to match to the univention portal, and then worked a charm!

"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>
        ServerName      cloud.myexternaldomain.com

        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 ^/?(.*) https://cloud.myexternaldomain.com/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
        SSLEngine on
        ServerName cloud.myexternaldomain.com

        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
</VirtualHost>
``"
---
So this by itself did not work, and I was stuck for about a week 
before this sent me in the right direction -
it eventually needed a copy of this default-ssl.conf added to sites-available
 and then enabled, that matched the
 host domain univention doing the proxying
  request to windows, but it had to be with 
name-based virtualhost 
(ip-based virtual hosts failed consistently) that matched my config:

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerName sub.somedomain.tld

        SSLEngine on
        SSLProxyEngine on
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerName off
        SSLProxyCheckPeerExpire off
        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://192.168.100.100/
        ProxyPassReverse / http://192.168.100.100/
        ProxyPreserveHost On
        ProxyRequests Off

</VirtualHost>
</IfModule>

After enabling the site with a2ensite sub and restarting Apache I have the following result:

    all sites that are served by somedomain.tld are still accessible as before
    on https/sub.somedomain.tld I see the page that is served by the internal host at 192.168.100.100

For me there was no need to add a VirtualHost for Port 80 as I have apache2/force_https=yes which also matches.
Note that I have not checked a real application, my internal host only serves a static page.

hth,
Dirk Ahrnke
Mastodon