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

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.

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

Hi Carsten, How it is going?

Hi, Closing this ticket for inactivity.

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?

And please re-open the ticket. Thank you!

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

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.

2nd video

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

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

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.

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

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

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

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

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

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!

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)