It looks like those info and warn messages are in the error log on successful login as well, so they probably don't give any clues.
Here's the inspect element from Chrome on loading the SSL proxied author ...
(blocked:mixed-content) (hovering over shows it is an http link). On logging in, there are two more cancelled token.json showing in red - both to https.
Thanks for any help!
Here's some output from cURL ...
the blocked mixed content in the screen.png points to http, looks like it's getting blocked before it can redirect?
HTTP/1.1 302 Found
Date: Fri, 30 Mar 2018 16:15:02 GMT
Server: Apache/2.2.15 (CentOS)
Content-Type: text/html; charset=iso-8859-1
HTTP/1.1 200 OK
Date: Fri, 30 Mar 2018 16:15:07 GMT
I received a hint from Adobe Support who pointed me at this article, and mentioned I look at III and IV specifically:
Everything in IV was already there by default and since it was the only instruction specifically for 6.3, there was no change. So I did the last part of II and all or III (specifically parts 2 & 3, which needed to be updated) ...
Here are the steps listed in the above posted link (I had to do those with *** to get my Apache SSL proxy to work):
II. Update Dispatcher /clientheaders configuration
Refer to the documentation of your load balancer to find out which header it sets to notify downstream systems that it terminated SSL. For simplicity, in these steps we assume that the correct HTTP header is "X-Forwarded-Proto: https"
Log in to the dispatcher server.
Open the dispatcher farm .any configuration.
Add the header to the /clientheaders section.
If you are using dispatcher without a load balancer or if your load balancer or proxy fails to set the X-Forwarded-Proto header, then you can set it at the web server or dispatcher level. If you are using Apache HTTP Server, then update your HTTPS VirtualHost with this directive:
*** RequestHeader set X-Forwarded-Proto "https"
III. Update the Header Configurations:
Go to http://host:port/system/console/configMgr/org.apache.felix.http.sslfilter.SslFilter, and log in as administrator.
*** Set SSL forward header to X-Forwarded-Proto.
*** Set SSL forward value to https.
There is no standard for reverse proxy headers that tell the back end which protocol is used. However, here are some that are known:
Amazon ELB (Elastic Load Balancer) uses the "X-Forwarded-Proto: https" header.
Amazon Cloudfront CDN uses "X-Cloudfront-Proto: https" header.
IV. Update the Jetty OSGi Configuration (AEM 6.3 and later versions)
all of these were defaults, so I didn't need to change
On AEM 6.3 and later versions there is an addition configuration required:
Enable the setting Enable Proxy/Load Balancer Connection, and save it.
Search for Sling Authentication Service and open the configuration.
Deselect Allow Anonymous Access.
can you check chapter 3 of the referenced link as well? If I recall correctly, the PID for the SSLFilter has changed recently, so please make sure that you have set the PID for the correct service.
Can you indicate, which request returns invalid data or an unexpected response?
I did look at III and changed 2 default values (see *** 's above), along with setting a header in Apache, i.e., RequestHeader set X-Forwarded-Proto "https", specified in chapter II.
It seems to be working now.
I'm not sure where the PID is referenced or how it comes into play in getting this to work.
glad that it works now.
When you have changed the configuration for PID "A" in AEM 6.2, but in AEM 6.3 the same functionality now uses PID "B" (using the very same structure and names), you have to move the configuration from A to B. And as the PID forms the names of the configurations, it should be obvious :-)