AppSuite:OX Mail v2 0 / open-xchange-mobile-api-facade

Apps & App Center
#1

Hi there,
apparently the setup for the new OX mailapp doesn’t work as expected.
Following this documentation here
http://oxpedia.org/wiki/index.php?title=AppSuite:OX_Mail_v2_0
does not seem to help, as the only package containing “facade” i can find on an univention / OX setup is

open-xchange-pns-mobile-api-facade/unbekannt,now 7.10.1-8 all [installiert]
The Mobile API Facade bundle for Push Notification Service

Can anyone help me with an installation walkthrough?
thanks
Sascha

#2

Hello,

I am facing this very same problem to be able to use OX APPS. open-xchange-mobile-api-facade according to the is the package to be installed.

Is it ? Or will be supported by UCS?

rgds,

Rolando Riley

#3

UCS not provide package open-xchange-mobile-api-facade to the App OX Mail.
When will we know if they will integrate it into the packages?

Regards.

#4

Hi,

right now we are discussing with OX about the integration of OX Mail into the Univention App Center. So for the moment I can only ask you to stay tuned…

Best regards

Sönke

1 Like
#5

Hi,
any news on this?
thanks
Sascha

#6

We have also cusomers, which are interessted in this.

#7

Good morning,
Is there already any progress in this direction?

We’re all eagerly waiting!
thanks a lot
Sascha

#8

Hi Sascha,

progress? yes
ready? unfortunately no.
The implementation is currently in QA and we hope that the last blocker will be removed in the near future.

Greetings,

Sönke

#9

The OX Update 7.10.2-ucs3 has been released. The corresponding Bug regarding the support of the OX Mail App has been closed.

Cheers
Stephan

#10

:+1::+1::+1:

thanks a lot
Sascha

#11

Hi,
sorry for reopening.
After installing the package now we experience a strange apache problem, we can’t seem to fix:

When we set up the OX Mail App (on Android), we get an error message in the app saying that the server is not responding:

The server does not appear to be responding.

The Apache log of the server show this when trying to login:

[Thu Feb 06 10:11:16.689001 2020] [ssl:error] [pid 30444] AH02032: Hostname ucs-master1.ucs.foo.bar provided via SNI and hostname ox.foo.bar provided via HTTP have no compatible SSL setup

Note: we have set up a virtual-ssl.conf with numerous subdomains on this host.
The ox.foo.bar part looks like this:

##########
# Open Xchange
##########

<VirtualHost *:443>
  ServerName ox.foo.bar
  ServerAlias mail.foo.bar
  DocumentRoot /var/www
  RedirectMatch ^/$ /appsuite/
  Include /etc/apache2/sites-available/ox.conf

  SSLEngine on
  SSLProxyEngine on


SSLCertificateFile /etc/univention/ssl/foo.bar/foo.bar.crt
SSLCertificateKeyFile /etc/univention/ssl/foo.bar/foo.bar.key
SSLCertificateChainFile /etc/univention/ssl/foo.bar/foo.bar.intermediate.crt


</VirtualHost>

We don’t seem to find a solution for this issue, and hope you would have an idea.
thanks
Sascha

#12

no idea anybody?
thanks
Sascha

#13

Hey tafkaz,

can you please check, if your /etc/apache2/sites-available/default-ssl.conf has the correct certificate paths referenced?

The default is:

SSLCertificateFile /etc/univention/ssl/{FQDN}/cert.pem
SSLCertificateKeyFile /etc/univention/ssl/{FQDN}/private.key
SSLCertificateChainFile /path/to/chain/file.pem

You can update these by altering the following UCR-variables:

apache2/ssl/key: <empty>
 The absolute path to the private RSA/DSA key of the SSL certificate file for mod_ssl. The key needs to be PEM-encoded. If the variable is unset, the certificate from the UCS CA is used (/etc/univention/ssl/FQDN/private.key).

apache2/ssl/certificate: <empty>
 The absolute path to the SSL certificate file for mod_ssl. The certificate needs to be PEM-encoded. If the variable is unset, the certificate from the UCS CA is used (/etc/univention/ssl/FQDN/cert.pem).

apache2/ssl/certificatechain: <empty>
 The path to a file containing CA certificates. They are sent to the client browser of a user, so that a certificate for authentication the user can be selected, which is issued by one of the CAs.

hth

#14

Hi @mschwarz
well yes, those keys seem correct, same as for ox.foo.bar in my virtual-ssl.conf.

<VirtualHost :443>
IncludeOptional /etc/apache2/ucs-sites.conf.d/.conf
SSLEngine on
SSLProxyEngine on
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
SSLCertificateFile /etc/univention/ssl/foo.bar/foo.bar.crt
SSLCertificateKeyFile /etc/univention/ssl/foo.bar/foo.bar.key
SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem
SSLCertificateChainFile /etc/univention/ssl/foo.bar/foo.bar.intermediate.crt

However, the wildcard certificate (*.foo.bar) configured here doesn’t seem to work for the master url, which is not ucs.foo.bar, but ucs-master1.ucs.foo.bar.
Maybe this is the problem.

So either i could change the default fqdn to ucs.foo.bar, or i would setup a seperate let’sencrypt certificate for that fqdn.
Don’t really know, what would you think?
thanks
Sascha

#15

ok…let’sencrypt for ucs-master1.ucs.foo.bar does not help:

[Mon May 11 19:31:05.240772 2020] [ssl:error] [pid 18965] AH02032: Hostname ucs-master1.ucs.foo.bar provided via SNI and hostname ox.foo.bar provided via HTTP have no compatible SSL setup

#16

Hi, we are having the same problem, could you solve it?

#17

Hi @Andreas_T,

no never ever tried again to be honest.
Our customers seem to have not asked for OX Mail ever since i guess.
But i guess, if you do have the same problem now, that the issue has not yet been resolved…
An issue from may 2020…
Maybe anyone from univention or ox can check this again?

cheers
Sascha

Mastodon