Unable to logon in Alfresco Community Server after upgrading iOS Alfresco App to version 2.0

[jeesee]

I'm having a problem after (automatic) upgrading the Alfresco App today.

Yesterday with the "old" Alfresco App (black icon) on my iPhone and iPad it all works fine.
Today I started the iPad app (it was automatically upgraded on both my iPhone and iPad to the 'white' icon) I receive a Session Error.

I tried to reconfigure the connection on the iPhone, but after delete de connection to my Alfresco server I can't configure a new one:

Save Account
Failure to authenticae. Check your
account settings with your system
administrator.

Is something changed in the new iOS app?

How can I configure it to connect with my Alfresco server?

Server settings:
Username: jeesee
Password: xxxxx  <- I'm sure it's right!
Hostname: My Alfresco Server .nl
Description
HTTPS: On

Sync files: Off
Port: 8443
Service Document: /alfresco/service/cmis
Client Certificate:


Please Help!

[marc_dubresson]

Hi Jeesee,

The team suggests that the sevice document should simply be: /alfresco

I also wanted to point out for the benefit of everyone that if you have an issue getting back on your cloud account after the update you can simple swipe the account name left to delete it and add it again.

Regards,

[jeesee]

Thank you Marc for your reply.
I changed the Service Document, but still the Failure to authenticate-error..
It also isn't on my cloud account, but on the connection to an Alfresco Community Edition 4.2f server, which worked perfectly before the app-update..

[mikeh]

I notice you're connecting directly to Tomcat (presumably?) on port 8443. Does that have a valid SSL certificate assigned to it? We no longer allow SSL connections with untrusted certificates due to customer concerns fed back to us from the previous app.

If that is the case, you'll either need to provision the correct SSL certificate, or use an HTTP connection.

Thanks,
Mike

[jeesee]

Thank you Mike, that can be the issue..
But how can I configure a correct SSL certificate to my Alfresco Tomcat installation? Can it be a self-signed certificate?

[mikeh]

No, sorry - it's self-signed certificates (and expired certificates) that we explicitly disallow. The "allow untrusted SSL" user preference was quite unpopular and so we didn't reimplement it in 2.0. Besides, if it's self-signed, there's very little benefit so you might as well be using HTTP anyway.

It's fairly easy to purchase and install a certificate for your Tomcat server (or Apache web server; I have a test Apache server that proxies to a development repo setup with SSL).

Thanks,
Mike

[shawnggraham]

Not trying to be a jerk or anything but…well i build a lot of corporate applications (web based, app based, custom servers) and i hear repeatedly that the company would prefer to use self signed certificates for this sort of thing. Third party verification is only a critical component for things like e-commerce(you still get the data encryption with a self signed cert).  When you have several web applications that maybe run outside your vpn, its nice to be able to use an easily regenerated ssl certificate Some times ssl is rotated frequently to take advantage of improvements in encryption tech.  Then there is the cost, and the added complication of when a ca root goes down or is just unreachable from the client trying to connect(yes it does happen). Frankly i was amazed this app cant just connect to a self signed cert(sure make it an option to ignore the warning, or better yet "opt in" to allow it with that not being the default).
Just saying about 90% of my customers will not work with any 3rd party verification(for there non e-commerce applications), and they have their reasons.

[mikeh]

Just add the root CA certificate (the one you used to generate the self-signed certs with) to your user's devices and they'll connect fine. This also works with the client certificate implementation that's in the app.

We can't selectively allow end users to switch off SSL validation for the reasons I've outlined elsewhere in this thread. I'm sorry that doesn't match your particular set of IT policies.

Thanks,
Mike

[mikeh]

Could I ask why you need a self-signed certificate to access your server? Perhaps that will help us understand the requirements.

Thanks,
Mike

[gerardh]

Some more quoted text:
<blockquote>

No, sorry - it's self-signed certificates (and expired certificates) that we explicitly disallow. The "allow untrusted SSL" user preference was quite unpopular and so we didn't reimplement it in 2.0. Besides, if it's self-signed, there's very little benefit so you might as well be using HTTP anyway.

It's fairly easy to purchase and install a certificate for your Tomcat server (or Apache web server; I have a test Apache server that proxies to a development repo setup with SSL).
</blockquote>

I have a dynamic ip-adres which is provided by my isp. So a signed ssl certificate would not work because of the ip changes. Besides not to offend you, but do you know the difference between HTTPS en HTTP? A self-signed certificate can be accepted so that i decide it's safe. Then i can use the https connection and all my communication will be encrypted. Using http i lose this ability and even the login / password data will be send unencrypted.

So yes i would like to use https but not pay $60 for a ssl certificate.

But what is the reason you would not implement a feature which you already had?