AEM 6.2 Desktop App SSL issue | Community
Skip to main content
Level 2
May 10, 2017

AEM 6.2 Desktop App SSL issue

  • May 10, 2017
  • 1 reply
  • 9459 views

Hello,

AEM version is 6.2 GA. Hotfix cq-6.2.0-hotfix-11099-1.4.zip installed.

Desktop App version 1.4.0.3

SSL configured on Apache that acts as reverse proxy for AEM Author instance. Certificate is not self-signed:

openssl verify -CAfile /etc/httpd/certs/issuingca.cer /etc/httpd/certs/mgmt-lms-aem.lab.[COMPANY].com.crt

/etc/httpd/certs/mgmt-lms-aem.lab.[COMPANY].com.crt: OK

The issue happens with AEM Desktop app after login screen loads and user performs authentication action (put login/password and press login button):

2017-05-10T17:27:38.059Z - error: invalid share configuration: {"host":"mgmt-lms-aem.lab.[COMPANY].com","port":443,"path":"/content/dam"} Error: self signed certificate in certificate chain

    at Error (native)

    at TLSSocket.<anonymous> (_tls_wrap.js:1060:38)

    at emitNone (events.js:86:13)

    at TLSSocket.emit (events.js:185:7)

    at TLSSocket._finishInit (_tls_wrap.js:584:8)

    at TLSWrap.ssl.onhandshakedone (_tls_wrap.js:416:38)

Exactly the same error happens when connecting directly to SSL-enabled AEM Author instance (port 5502 - enabled SSL).

All is good when connecting without SSL being enabled on port 4502.

All above were done with SAML disabled. When SAML is enabled it is even worse - there are no logs at all, just blank white screen in Desktop App interface.

Could you please help with resolution of this issue?

Alex

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

1 reply

Adobe Employee
May 11, 2017

Hi Alex,

Thank you for reaching out. As the error message states, the desktop app's backend is indicating that there is an issue in the SSL chain. Web browsers will often ignore these kinds of errors, but the desktop app uses more strict enforcement of SSL. I would highly recommend re-verifying the chain; there are websites available where you can input your host and it will do a deep analysis of the SSL and report any issues.

As an alternate (less recommended) solution you can reduce how strictly the desktop app enforces SSL. However, be aware that this solution will mean less security (because it will hide the true SSL problem), and it will need to be done on every installation of the desktop app.

  • Edit the file at /Applications/Adobe Experience Manager Desktop.app/Contents/Resources/javascript/lib-smb/config.json
  • Locate the element at "shares > DAM"
  • Beneath that element, add a new item: "strictSSL": false
  • Save the file and restart the desktop app

The new configuration might look similar to this:

{ ... "shares": { "DAM": { "backend": "rq", "description": "AEM Assets RQ Share", "strictSSL": false, ... } } ... }
Level 2
May 11, 2017

Hi Mark,

Thanks for your suggestion. The file under Windows 7 is actually at C:\Program Files (x86)\Adobe\Adobe Experience Manager Desktop\javascript\config.json.

There I found suggested structure and added "strictSSL": false row. It helped for the case without SAML enabled (Adobe Granite SAML 2.0 Authentication Handler).

Once the config entry added - I have successfully connected to AEM Author instance. Security is not so critical right now for the current application deployment. But for the future troubleshooting of our certificate, could you please point out to the description how exactly Desktop App performs verification of certificate? Does it use some specific remote API or uses some local command line tool verifications?

My final goal is to find out whether AEM Desktop App can work with SSO enabled (SAML case) and have PoC for this case. Like I described in previous post.

I still have empty log file and blank white screen for SSO case. Normally (in the browser) user gets "redirected" to the IdP sign in URL and back like it is described in the article of troubleshooting of Desktop App (https://helpx.adobe.com/experience-manager/kb/troubleshooting-companion-app.html#TroubleshootingAEMDesktopconnectionissues) - the case described there works fine (/content/dam.json).

How could I proceed to get more logging (enable debug) or what can I do to understand the root cause of issue with SSO case not working?

Thanks, Alex

Level 2
May 12, 2017

> Is it Internet Explorer instance, BTW? If so, which version?

The window is using a .NET WebBrowser control that is emulating IE 10. So while it's not technically an embedded IE instance, you can consider it as if it were IE 10. I'd recommend verifying that the sign-in page renders correctly in a small IE 10 window. Are there scrollbars on the login window? Maybe the page is rendering but you just can't see the content.

You're correct about /content/dam.json - the Windows version requests /content/dam instead. In other AEM instances that I've worked with, that URL usually results in a Forbidden status code but it's enough for the app to know when it's authenticated. For what it's worth, we're currently working on improving the login process so that both operating systems use /content/dam.json, but that won't be available for a few months.


I've just verified our login page in IE10 (IE 11 in Document mode 10) with smallest resolution available. From what I see it is absolutely fine. More than that, it is responsive, so obviously there are no any scroll bars. The content adjusts to any resolution, even much smaller than Desktop App window size. Besides this, from what I saw while configuring SAML SSO, our login page shows errors and their details if they happen on server side. This is company wide SSO, so I don't think there are any issues with this.

Do you have any other ideas what to check and how to ensure on which stage the issue happens?