By: Carsten Buchenau user 23 May 2018 at 2:29 p.m. CDT

20 Responses
Carsten Buchenau gravatar
Hi, Probably related to this one: https://support.gluu.org/installation/5508/can-not-access-gluu-server-after-isntalled-it-successfully/ After installation, I cannot access the GUI via HTTPS. I get the HTTPS handshake and are asked to make exceptions for the certificate, and I received the login panel once. But a login timed out, and since then I get timeouts. It actually looks like there is a redirection to HTTP, which is not open from external (after browser timeout, the URL in the address window is http://iam.cpnv.ch/identity/login) What I have done: - Installed Ubuntu 16.04, modified the file descriptors etc. as per documentation - Installed gluu-server-3.1.3 package via apt-get - ran the setup.py script: - Kept local IP 192.168.17.2 - Hostname is iam.cpnv.ch From external, iam.cpnv.ch resolves to public IP 145.232.235.158. Only HTTPS (and ssh) are open from external, and only from specific public IP subnets (for now). Any idea? Is HTTP also required, and if yes, can this be avoided?

By Carsten Buchenau user 23 May 2018 at 2:36 p.m. CDT

Carsten Buchenau gravatar
UPDATE: Interestingly, I can login with Safari. Firefox and Chrome do not work (Timeout). On MacOS-X, obviously.

By Thomas Gasmyr Mougang staff 23 May 2018 at 2:46 p.m. CDT

Thomas Gasmyr Mougang gravatar
Welcome Carsten, Check the following: 1. Disable any firewall protection 1. Make sure your server match the [minimum server requirement](https://gluu.org/docs/ce/3.1.3/installation-guide/#system-requirements). 1. if possible make a short video where we can see the behavior describe above Thanks, Gasmyr.

By Carsten Buchenau user 24 May 2018 at 2:38 a.m. CDT

Carsten Buchenau gravatar
Thanks Gasmyr, - We have no Firewall installed on the server itself - There are 2 Firewalls in between for packet filtering, and only HTTPS is allowed from outside. My understanding of the ports-section in "minimum requirements" is that HTTP is open on the server by default, but it is supposed to be redirected to HTTPS anyway - Server is installed with 2 vCPUs, 8GB of RAM and 40GB HD space. I just checked again, and still the same from my MacBook: - Ok with Safari - Not Ok with Firefox and Chrome Maybe a certificate / TLS settings issue? Can you point me to the right direction to find out? I am at a conference today, I will try to create a video later today or tomorrow. carsten

By Thomas Gasmyr Mougang staff 26 May 2018 at 7:39 a.m. CDT

Thomas Gasmyr Mougang gravatar
Hi Carsten, How it is going?

By Thomas Gasmyr Mougang staff 28 May 2018 at 1:22 a.m. CDT

Thomas Gasmyr Mougang gravatar
Hi, Closing this ticket for inactivity.

By Carsten Buchenau user 28 May 2018 at 1:33 a.m. CDT

Carsten Buchenau gravatar
Excuse me for not working over the weekend. Still the same situation, it works with Safari but not with Chrome or Firefox. Confirmed by my colleagues as well. I suspect the certificate and its browser compatibility. Questions: Under which circumstances would Firefox and Chrome fall back to HTTP? Do you actually require HTTP to be open? If yes, can this be changed to HTTPS only? I will see to change the server certificate. I have not yet looked at the Docs for how to do it, I am assuming this is straight forward?

By Carsten Buchenau user 28 May 2018 at 1:34 a.m. CDT

Carsten Buchenau gravatar
And please re-open the ticket. Thank you!

By Thomas Gasmyr Mougang staff 28 May 2018 at 1:46 a.m. CDT

Thomas Gasmyr Mougang gravatar
Hi, > Do you actually require HTTP to be open? ** No.** If possible make a short video where we can see the behavior describe above.

By Carsten Buchenau user 28 May 2018 at 6:22 a.m. CDT

Carsten Buchenau gravatar
Hello Thomas, I have created 3 videos now. Setup: - Chrome - ssh to server, tail -f on Apache2 log file - Recording tool limited to 120s per recording 1. First run: New session, browser just opened. The last timeout at the end is not recorded anymore, but it is again an HTTP redirect, same URL as at the end of the 2nd session. 1. Second run: same browser window 1. Third run: after restarting the browser. You see I am logged-in now, but I still get redirected to HTTP. It should be noted that I am not always receiving the login window. But if I do, it's like that (with Chrome, Firefox, IE and Edge). Only Safari is never a problem.

By Carsten Buchenau user 28 May 2018 at 6:22 a.m. CDT

Carsten Buchenau gravatar
2nd video

By Carsten Buchenau user 28 May 2018 at 6:23 a.m. CDT

Carsten Buchenau gravatar
3rd video. Let me know if you need anything else. Thanks, carsten

By Thomas Gasmyr Mougang staff 28 May 2018 at 6:36 a.m. CDT

Thomas Gasmyr Mougang gravatar
Okay, Thanks, we are going to check the videos provide and let you know when done.

By Yuriy Movchan staff 29 May 2018 at 4:50 a.m. CDT

Yuriy Movchan gravatar
Hi Carsten, Thank you for sharing video. I think you get wrong behavior due to self signed CE certificate. Modern browsers do not trust them. I can't even open CE in Firefox due to browser + antivirus protection. I use [Firefox developer](https://www.mozilla.org/en-US/firefox/developer/) version for this. I offer to open in Firefox network debug console. There is keyboard shortcut `Ctrl+Shift+E`. After that you can set checkbox "Persist Logs" and record all request. In Chrome there is similar functionality too (`Ctrl+Shift+I`). These networks traces will help us to answer the question. But I didn't remember that we do redirect from HTTPS to HTTP in CE. Probably browser offer to use http instead of https if there is untrusted self signed certificate. That's why it put in URL link without https.

By Carsten Buchenau user 29 May 2018 at 5:08 a.m. CDT

Carsten Buchenau gravatar
Thanks Yuriy. Were suspecting this, and the customer has already offered to user their Wildcard certificate. We will install this, test again, and let you know. Thanks a lot for looking into this!!

By William Lowe user 31 May 2018 at 8:38 a.m. CDT

William Lowe gravatar
Thanks, Carsten. I'm closing the ticket for now. Please open a new ticket if needed.

By Carsten Buchenau user 31 May 2018 at 8:40 a.m. CDT

Carsten Buchenau gravatar
Sure, thanks for your help. I am currently waiting for the customer to provide us the PFX file.

By William Lowe user 31 May 2018 at 8:42 a.m. CDT

William Lowe gravatar
Sounds good! That should take care of the issue :)

By Steve Larsen user 01 Jun 2018 at 4:36 a.m. CDT

Steve Larsen gravatar
I have experienced the exact same issue. the login works in safari but fails in chrome.

By Carsten Buchenau user 01 Jun 2018 at 6:50 a.m. CDT

Carsten Buchenau gravatar
All good, installing a proper certificate (Wildcard, issued by RapidSSL with intermediate CA) did the trick. I followed this procedure: https://gluu.org/docs/ce/admin-guide/certificate/ Thanks again for your support!

By Thomas Maerz user 21 Jun 2018 at 2:36 a.m. CDT

Thomas Maerz gravatar
I am experiencing the same issue here with a new 3.1.3 installation. A couple comments: This might be more than a more than a certificate issue. When Chrome and FF have an issue with your SSL certificate, they will usually tell you about it. This is causing a timeout in the browser! Looks like the certificate is signed with SHA-256 with RSA Encryption ( 1.2.840.113549.1.1.11 ), so that is fine. Then, there's the issue of the certificate being self-signed at all, which throws errors but should NOT prevent the user from accessing the site if they tell the browser they trust the certificate. In this case, there's something else happenging. Late last year/early this year, browsers started checking for subject alternate names in certain scenarios for self-signed certificates. I'm seeing that is the case here in developer tools security tab when viewing the site in Google Chrome. Chrome dev tools says: ```This page is not secure (broken HTTPS). Certificate - Subject Alternative Name missing The certificate for this site does not contain a Subject Alternative Name extension containing a domain name or IP address. View certificate Certificate - missing This site is missing a valid, trusted certificate (net::ERR_CERT_AUTHORITY_INVALID). View certificate ``` Looks like this can be fixed during the generation process: [Invalid self signed SSL cert - “Subject Alternative Name Missing”](https://stackoverflow.com/questions/43665243/invalid-self-signed-ssl-cert-subject-alternative-name-missing). That link contains some potential workarounds and much more detailed information that I have in my brain. Since this is happening out-of-the "box" (installation repos) with current browser versions, it would be nice to see a bugfix be entered for it. If it indeed is an issue with the self-signed autogenerated certificate and it's using improper cypher or something, that should be readily fixable with a small commit. It could be quite discouraging for new users to try to fire up a test instance and not be able to get it to work. Update: Final note/nod to reporter and other posters, I am not sure if it is the browser or the application server redirecting to HTTP/80, but the reason it's causing an issue for us is the same. We have an external firewall running, and we keep the idp boxes in the DMZ for security purposes. So they have only bare-minimum ports open to the LAN and to the WAN. Since SAML is naked and insecure with SSL, HTTPS/80 is not open so that's why it seems like the fresh install is broken. I do think this could be an easy fix if setup.py's certificate generation commands added in a subject alternative field. Here's a link specific to that: [enter link description here](https://stackoverflow.com/questions/7580508/getting-chrome-to-accept-self-signed-localhost-certificate/43666288#43666288), but it's specific to Linux and OpenSSL. I am assuming this is happening with Java keytool so here's an example of that: [Java Keytool Chrome/Firefox friendly self-signed cert method w/subjectaltname](https://serverfault.com/questions/605843/unable-to-generate-certificate-with-subject-alternate-name-using-java-1-7-keytoo)