Alfresco Repository tenant won't use https

[cseickel]

This one is driving me crazy and I can't imagine I am the only one to run across this problem, but I can't find any other posts about it.

I have configured an Alfresco Repository under the tenants section of the activiti app using the https protocol. When I use this tenant from an Attach File field on a form, it can browse the list of sites just fine, but it always fails on getting the actual content from the site. The problem is that it always uses http instead of https for this action, even though I specified the urls as https. When port 80 is not open for this server I see in the logs that it is timing out because it is explicitly using http with port 80:

Caused by: org.apache.chemistry.opencmis.commons.exceptions.CmisConnectionException: Cannot access "http://alfresco-dev.xxx.cloud:80/alfresco/api/-default-/public/cmis/versions/1.0/atom/path?path=%2FS...": Connection timed out (Connection timed out)

NOTE: I replaced the domain name in this log with xxx.

When I open port 80, it get's redirected to port 443 by my load balancer and I see this error in the logs:

org.apache.chemistry.opencmis.commons.exceptions.CmisConnectionException: Redirects are not supported (HTTP status code 301): Moved Permanently

If I use an address that is accessable via http it works fine, but that won't work in production. Does anyone know what I am missing? How can I force this service to use https for opencmis actions?

Thank you for any insight you can offer.

-Chris

[cseickel]

I didn't find a solution to this, but I did find a workaround that is good enough. I can connect on the backend over http using the internal DNS namespace because they are deployed to the same internal network.

The issue I had initially is that it was initially showing the end user links with those internal addresses that won't work for them. This can be fixed by setting the Repository URL to the internal address and the Share URL to the external one. So far that is working fine.

[EddieMay]

Hi @cseickel 

Great that you found a workaround & thanks for updating your thread - really helpful to other users.

Cheers,