Hi, Gregg. Could you share your Apache config from this instance? Should be at this location: `/etc/apache2/sites-enabled/https_gluu.conf` Also, what is output of `# hostname` and `# ifconfig` **from inside container** there (or `# ip addr` if the later is not present)?

Apache Config ``` <VirtualHost *:80> ServerName ssostaging.hypersign.net Redirect / https://ssostaging.hypersign.net/ DocumentRoot "/var/www/html/" </VirtualHost> <VirtualHost *:443> DocumentRoot "/var/www/html/" ServerName ssostaging.hypersign.net:443 LogLevel debug SSLEngine on SSLProtocol -all +TLSv1.1 +TLSv1.2 SSLHonorCipherOrder On SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-RSA-AES128-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK SSLCertificateFile /etc/certs/httpd.crt SSLCertificateKeyFile /etc/certs/httpd.key # SetEnv proxy-nokeepalive 1 SetEnv proxy-initial-not-pooled 1 Timeout 60 ProxyTimeout 60 # Security headers # Header always append X-Frame-Options SAMEORIGIN Header always set X-Xss-Protection "1; mode=block" Header always set X-Content-Type-Options nosniff # Header always set Content-Security-Policy "default-src 'self' 'unsafe-inline' https://ssostaging.hypersign.net" Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" Header edit Set-Cookie ^((?!session_state).*)$ $1;HttpOnly SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 # Unset X-ClientCert to make sure that we not get certificate in request RequestHeader unset X-ClientCert # Turn off support for true Proxy behaviour as we are acting as a transparent proxy ProxyRequests Off # Turn off VIA header as we know where the requests are proxied ProxyVia Off # Turn on Host header preservation so that the servlet container # can write links with the correct host and rewriting can be avoided. ProxyPreserveHost On # Preserve the scheme when proxying the request to Jetty RequestHeader set X-Forwarded-Proto "https" env=HTTPS Header unset ETag FileETag None RedirectMatch ^(/)$ /identity/ # Set the permissions for the proxy <Proxy *> AddDefaultCharset off Order deny,allow Allow from all </Proxy> <Location /idp> ProxyPass http://localhost:8086/idp retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /identity> ProxyPass http://localhost:8082/identity retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /cas> ProxyPass http://localhost:8083/cas retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /oxauth-rp> ProxyPass http://localhost:8085/oxauth-rp retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /passport> ProxyPass http://localhost:8090/passport retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /casa> ProxyPass http://localhost:8099/casa retry=5 connectiontimeout=60 timeout=60 Order deny,allow Allow from all </Location> <Location /oxauth> ProxyPass http://localhost:8081/oxauth retry=5 connectiontimeout=60 timeout=60 # Header set Access-Control-Allow-Origin "*" Order deny,allow Allow from all </Location> <LocationMatch /oxauth/auth/cert/cert-login> SSLVerifyClient optional_no_ca SSLVerifyDepth 10 SSLOptions -StdEnvVars +ExportCertData # Forward certificate to destination server RequestHeader set X-ClientCert %{SSL_CLIENT_CERT}s </LocationMatch> ProxyPass /.well-known/openid-configuration http://localhost:8081/oxauth/.well-known/openid-configuration ProxyPass /.well-known/simple-web-discovery http://localhost:8081/oxauth/.well-known/simple-web-discovery ProxyPass /.well-known/webfinger http://localhost:8081/oxauth/.well-known/webfinger ProxyPass /.well-known/uma2-configuration http://localhost:8081/oxauth/restv1/uma2-configuration ProxyPass /.well-known/fido-configuration http://localhost:8081/oxauth/restv1/fido-configuration ProxyPass /.well-known/fido2-configuration http://localhost:8081/oxauth/restv1/fido2/configuration ProxyPass /.well-known/fido-u2f-configuration http://localhost:8081/oxauth/restv1/fido-configuration ProxyPass /.well-known/scim-configuration http://localhost:8082/identity/restv1/scim-configuration </VirtualHost> ``` ifconfig ``` eth0 Link encap:Ethernet HWaddr 22:00:0a:9e:c5:2f inet addr:10.158.197.47 Bcast:10.158.197.255 Mask:255.255.255.0 inet6 addr: fe80::2000:aff:fe9e:c52f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:172150 errors:0 dropped:0 overruns:0 frame:0 TX packets:148900 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:24090684 (24.0 MB) TX bytes:39077515 (39.0 MB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:100610 errors:0 dropped:0 overruns:0 frame:0 TX packets:100610 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:32651901 (32.6 MB) TX bytes:32651901 (32.6 MB) ``` hostname = ssostaging.hypersign.net

Thanks, Gregg, it seems fine to me. I guess we need to double-check the whole installation process for AWS. I'll get back to you soon.

Hi, Gregg. My first install of CE 4.0 in Xenial-based AWS instance worked just fine. I'll record a screencast of my next attempt and share with you, so you could compare your steps with mine. Just to be sure: when installing, you were following [this doc](https://gluu.org/docs/ce/4.0/installation-guide/install-ubuntu/) yourself, the part marked "For Ubuntu 16.04.x", correct?

That is the document I followed. Just trying to think of anything that may be different between our environment and yours. One difference is that I didn't do any of the static ip related setup in the VM Setup section given that we have an ELB in front of the server and the DNS points to that load balancer which obviously has a static ip already. I did assign an elastic ip to the server though that's probably not needed either. During the execution of setup.py I did specify the AWSi nternal ip as the ip and ssostaging.hypersign.net as the hostname. The only other thing I can think of is that our server is running in the classic EC2 and not a VPC.

>During the execution of setup.py I did specify the AWSi nternal ip as the ip Do you mean you had to actually type in another ip address instead of the one it suggested as default one? It's believed that it's better to just confirm the default ip address `setup.py` offers to you. I personally have never actually tried to change it, and I'm not sure setup on multi-homed or multi-ip host is tested very thoroughly. I would say, ideally, you should install on a vm with a single network interface which has just one ip address assigned, anything else may not work as expected.

I did not have to type in another ip address. The default was the internal IP from AWS

Maybe the ELB is causing the issue? Based on the flow of redirects it seems like it's losing the IP address as somepoint and trying to route to just port 443 which you can't do so AWS is inserting the bogus ip 0.0.1.187. I'm not, by any means, a sys admin so a lot of this is foreign to me.

In our previous setups we didn't have issues with ELB. But it turns out in my recent test ELB wasn't a part of the setup. I'll re-try installation with it added now.

Hi, Gregg. One thing I still can't figure out - how exactly did you configure your Load Balancer in AWS? What type did you select, and why did you need it at all? Do you have several Gluu Server instances running behind it, perhaps?

We use the load balancer because that's where we house our SSL certs. We have to use the classic load balancer since our server is EC2 and not VPC. It's listening on ports 80 and 443. So our DNS, ssostaging.hypersign.net is pointed to the load balancer. That connection is HTTPS. We only have one gluu server so the ELB hands off to it. Let me know if you need more information on how it's setup.

We don't have to use the load balancer, it's just normally how we set things up. I took the server out of the load balancer, uninstalled everything, rebooted and then reinstalled. I'm still getting errors. If you could post that video that might help.

I was able to get this to work without the ELB. I had typo'd the hostname in my local hosts file.

Hi, Gregg. Please find the video attached. This is installation done at Xenial EC2 (VPC, not Classic, as we don't have ability to create the later, due to limitations of our AWS account). It's not behind any LB, just an elastic IP assigned EC2 instance.

>I was able to get this to work without the ELB. I had typo'd the hostname in my local hosts file. Oh, I see. That makes sense. So, does it also work when you put it behind LB now? Or the original issue still persists?

I will check and let you know, but I doubt it since we had the DNS ssostaging.hypersign.net registered it wouldn't have been needed in my local hosts file.

Hi, Gregg. Any progress with making it work?

Hey Aliaksandr, I'm still in the same spot as before. It works without the load balancer, but once I turn on the ELB it breaks. I can continue to go ahead and get the rest of my stuff setup for testing without the ELB. We would prefer to be able to use the ELB, but if worse comes to worst we can install the cert on the server bypass the ELB. Thanks! -Gregg

Hello Gregg, For ELB, one suggestion... can you please enable Sticky Session? Let's see how that goes?

Hello all. Same error in our installation. Trying to set 1 Gluu 4.0 node behind Classic ELB (backend httpd certificate -or without it-, sticky sessions, public signed cert). I just made all the same things like in our Gluu 3.1.2, but it throws us to 0.0.1.187 I checked httpd config (we use CentOS 7) comparing with v3.1.2. Just two differences: - LoadModule env_module modules/mod_env.so - AddIcon /icons/binary.gif .bin .exe If I set dns directly to Gluu node, it works. Security Groups are checked (same as 3.1.2) and I don't know what can I do.

I think I am going to spin a VM in AWS and share how everything goes with screencast video. Re-assigning ticket to me. I'll go with CentOS 7 first.

I think I am able to reproduce your issue. Screenshot attached.

that's it! All this morning trying to elude that failed jump. I hope you'll find the reason :/

Yep, that screenshot is exactly what I see.

[Here](https://github.com/GluuFederation/oxCore/issues/168) is the github issue. Thanks for your report!