AEM 6.2 Desktop App SSL issue

[AlexSel]

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

[Mark_Frisbey]

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, ... } } ... }

[AlexSel]

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#TroubleshootingAEMD...) - 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

[Mark_Frisbey]

> Does it use some specific remote API or uses some local command line tool verifications?

The backend uses Node.js to make HTTP requests. Specifically, it uses the request module. I'm not sure how the module verifies SSL internally, but hopefully that information should give you an idea of where to start looking.

> My final goal is to find out whether AEM Desktop App can work with SSO enabled (SAML case) and have PoC for this case

AEM Desktop supports SSO - we have many customers using it. When you say you get a blank white screen, which screen is it and when do you see it? For example, does the login screen show as empty immediately? Are you able to enter your credentials?

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

On Windows, open C:\Program Files (x86)\Adobe\Adobe Experience Manager Desktop\Adobe Experience Manager Desktop.exe.config and change <level value="INFO"/> to <level value="DEBUG"/>

[AlexSel]

Ok, I switched logging to DEBUG level.

> When you say you get a blank white screen, which screen is it and when do you see it? For example, does the login screen show as empty immediately? Are you able to enter your credentials?

No login prompt of any kind. I just click connect and see blank screen (in embedded browser, I guess). Is it Internet Explorer instance, BTW? If so, which version?

Here is log for connection attempt:

2017-05-12 00:41:50,331 [1] DEBUG AemCompanion.ContextMenus - Menu_Opening: entering with sender: System.Windows.Forms.ContextMenuStrip, Name: , Items: 11, e: System.ComponentModel.CancelEventArgs 2017-05-12 00:41:50,331 [1] DEBUG AemCompanion.ContextMenus - Menu_Opening: exiting 2017-05-12 00:41:50,341 [1] DEBUG AemCompanion.ProcessIcon - ni_MouseClick: entering with sender: System.Windows.Forms.NotifyIcon, e: System.Windows.Forms.MouseEventArgs 2017-05-12 00:41:50,341 [1] DEBUG AemCompanion.ProcessIcon - ni_MouseClick: exiting 2017-05-12 00:41:51,111 [1] DEBUG AemCompanion.ContextMenus - Mount_Click: entering with sender: &Connect, e: System.EventArgs 2017-05-12 00:41:51,111 [1] DEBUG AemCompanion.ContextMenus - GetCredentials: entering 2017-05-12 00:41:51,121 [1] DEBUG AemCompanion.ContextMenus - GetCredentials: exiting 2017-05-12 00:41:51,121 [1] DEBUG AemCompanion.ContextMenus - Mount_Click: exiting 2017-05-12 00:41:53,441 [1] DEBUG AemCompanion.ProcessExecutor - ValidateOptions: entering with host: https://mgmt-lms-aem.lab.[COMPANY].com, user: , drive: A 2017-05-12 00:41:53,441 [1] DEBUG AemCompanion.ProcessExecutor - ValidateDrive: entering with drive: A 2017-05-12 00:41:53,441 [1] DEBUG AemCompanion.ProcessExecutor - ValidateDrive: exiting with 0 2017-05-12 00:41:53,441 [1] DEBUG AemCompanion.ProcessExecutor - ValidateOptions: exiting with 0 2017-05-12 00:41:53,441 [1] DEBUG AemCompanion.Mount - Login browser navigating to https://mgmt-lms-aem.lab.[COMPANY].com/content/dam?.ts=636301465134411197 2017-05-12 00:41:53,871 [1] DEBUG AemCompanion.Mount - Login browser navigated to https://mgmt-lms-aem.lab.[COMPANY].com/content/dam?.ts=636301465134411197 2017-05-12 00:41:53,881 [1] DEBUG AemCompanion.Mount - Login browser navigating to https://login.[COMPANY].com/adfs/ls/ 2017-05-12 00:41:54,683 [1] DEBUG AemCompanion.Mount - Login browser navigated to https://login.[COMPANY].com/adfs/ls/wia

As you can see, the last thing it does, it tries to open IDP URL, but unfortunately for some reason cannot display it, right? This is at least according to the log sequence.

In this case, if the reason is that embeded browser cannot display the page, is there a way to find out why? I tested SSO functionality for this server with IE, Chrome and FF - everywhere it works as expected.

But after that I noticed that it doesn't actually request /content/dam.json like described in troubleshooting page, but instead it requests /content/dam?.ts=636301465134411197 which actually results in 500 error on the fully functional AEM Author server:

12.05.2017 00:55:15.990 *ERROR* [10.6.61.18 [1494539715987] GET /content/dam/ HTTP/1.1] org.apache.sling.engine.impl.SlingRequestProcessorImpl service: Uncaught Throwable java.lang.IllegalArgumentException: Not a valid identifier 'index,index.html'

So, is there a configuration that changes this URL, that Desktop App tries to reach? Or is it some expected behaviour?

[Mark_Frisbey]

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

[AlexSel]

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?

[AlexSel]

Hi Mark,

I've just changed one more configuration value in C:\Program Files (x86)\Adobe\Adobe Experience Manager Desktop\Adobe Experience Manager Desktop.exe.config:

<setting name="DebugLogin" serializeAs="String"> <value>True</value> </setting>

from "False" to "True", restarted the application and Desktop Application login started working as expected!

When I chnaged it back and restarted, it stopped working and vice versa again...

So, this seems to be an issue to be fixed.

Alex

[Mark_Frisbey]

Thanks for the detail, Alex. When you originally said that all you saw was a white screen, were you seeing the "Loading..." image or was it completely blank?

The DebugLogin option that you set essentially hides the loading image, so maybe the desktop app wasn't recognizing that your login page had loaded in the window.

[AlexSel]

Hi Mark,

Thank you for your help on the issue! Should I mark as correct the first answer (the original question was about SSL and than we moved to SSO topic)?

When you originally said that all you saw was a white screen, were you seeing the "Loading..." image or was it completely blank?

No, it was not the loading screen for sure. I saw the loading screen before. But the issue resulted in blank white screen.

So, the suquence of events is the following (DebugLogin = False):

1. User puts the site root URL to the address bar
2. User clicks the Go button
3. Go button becomes disabled
4. The "Loading..." screen shown
5. The "Loading..." screen disappeared
6. The white screen shown
7. Nothing happens after white screen shown

[AlexSel]

Hi Mark,

As far as I understand Node.js request module, you've mentionned, doesn't use the system certificates store, thus it is not obeing manually added root CA certificates.

Could you please suggest the best way to pass our company's root and intermediate certificates chain to the AEM Desktop App in order to try to avoid using strictSSL = false flag? Our internal root CA certificate is self-signed, that's probably why AEM Desktop App was throwing self-signed certificate error (cause of self-signed root in chain that server sends). I would like to force import / pass our root CA as trusted for AEM Desktop App.

From what I see it is possible to be done in request module, but this requires code changes in JS files and I'm not sure where to put it, etc... On other hand, it is not a good approach for future releases upgrade process to newest AEM Desktop App versions.

Please suggest the way to handle the case of custom made certificates with own root CA  (self-signed root in chain, intermediate cert and domain certificate with CN = hostname) which is not issued by any trusted parties. Is it possible to pass them to AEM Desktop App in any way so that they are treated like trusted? Do you have some strategy how this can be solved in next releases otherwise?

[AlexSel]

Hi Mark,

We've changed the certificate to the one which is trusted (in all browsers and all tools that can verify it) and now we have another error in AEM Desktop App:

Error: unable to verify the first certificate 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)

Is it possible to use the following solution in AEM Desktop App (module ssl-root-cas) or do you recommend any other solution for this error?

• https://git.daplie.com/Daplie/node-ssl-root-cas