Tested on a fresh server and an upgraded one. When an Internet site has “Redirect TCP to SSL” option checked on security tab, all requests into that server redirect to itself and browser returns “Too many redirects” error.
Subject: RE: Redirect TCP to SSL setting and infinite redirection
Hi Mike.
FYI: it seemed to work for me when I was already logged in.
I had only the Web Site document “Redirect to SLL” enabled and it worked when I was already logged in (session login).
When I logged out and tried the server again it failed (infinite loop).
Subject: Can you confirm a couple of settings
- I assume you are using session authentication, (single server or lpta). Is that correct?, If not what type of authentication configuration are you using?
- I assume you have a custom login page defined in domcfg.nsf, correct? (depends on answer above)
- If you have a custom login page in domcfg, could you rename your domcfg.nsf to something else and retry, this will bring up the default/fallback login page (will need to restart http), that would help narrow what code paths may be involved?
Thanks
Subject: Need more information
Need to understand the configuration better.
This is used all the time so something is different in your configuration and we cannot reproduce.
Question.
Are you running IHS in front of the Domino Server?
To help figure out what is going on would like to get the thread logs from the server,
Can do this by
“tell http debug thread on” at the console
One can look at the request/response chains and see what we are sending out for a redirection and what the browser is sending and whether we are doing
an SSL handshake or receiving the request over http
Some more configuration information
At the console
“tell http dump config”
this will create a httpcfg.txt file in the IBM_TECHNICAL_SUPPORT directory which will list all the rules for the web sites.
If that does not help it may be necessary to raise a PMR to support for further investigation
Subject: RE: Redirect TCP to SSL setting and infinite redirection
I did now finally have time to track down this issue …
I checked again our production servers and there we indeed have the HTTPEnableConnectorHeaders=1 set. We distribute this via a configuration document and I have to find out why - we don’t use IIS front end servers. I guess we should be able to disable it and then perhaps see what fails … if anything. 
I also found out why I saw on my test server what I thought is the same problem: I made a typing error for the SSL keyring file so it was not loaded and I always overlooked the error message telling me so … how embarrassing. So after fixing this the “Redirect to SSL” problem of course went away.
Sorry for wasting so much of your time!
I guess for the case of HTTPEnableConnectorHeaders=1 this will be fixed in an upcoming fixpack?
Subject: Yes, fix will be in next 90 update
Subject: RE: Redirect TCP to SSL setting and infinite redirection
Mike,
Since we can’t repeat this on any servers, I thought it must be a result of a setting coming from my names.nsf. I tried 10-15 different things and found the difference
I have a notes.ini setting “HTTPEnableConnectorHeaders=1” which is defined in the configuration document. So it comes to every servers I have (My servers were behind plugin before). After deleting this entry, it is back to normal. I guess the IHS implementation may have changed this behaviour.
Thx for the effort!
Subject: HTTPEnableConnectorHeaders=1
Yes, this will cause all kinds of problems if not running IHS in front of Domino in self contained mode or running with the WAS Websphere Web Connectors (reverse proxy modules). This parameter indicates that we should look for special context headers and use those headers for the context of the SSL connection between the Browser and IHS. If the SSL context header is not present we think the connection between IHS and the browser is not SSL and can get into an infinite redirection loop.
The Domino SSL network connection has no effect on whether the connection is SSL or not with this ini. The connection may be normal http between IHS and the Browser and SSL between IHS and Domino (not a likely configuration, but possible).
That explains the behavior you are seeing, and why we were not reproducing in the lab,
This ini should only be set if running Domino in back of the WAS Reverse Proxy Plugins/modules. It is not used/needed for the case where Domino runs IHS for the TLS stack locally on the same machine, and it should never be used when Domino is a contacted directly by browser clients.
Thanks for the info, this is something we should tech note and/or make support aware of in case others run into this.
Subject: RE: Redirect TCP to SSL setting and infinite redirection
Mike,
I did some additional tests with SSL redirect enabled at Internet site configuration level.
Authentication has no effect. I tested my test server with and without session authentication. Even a database with anonymous access allowed causes the problem. According to thread logs, if we request such a database resource, it stops at the authentication level and return to redirection.
I have also tried using different host names to check if the problem is related to host-name binding but it doesn’t matter.
Interestingly, the only page I can reach is /names.nsf?login. I can reach this page, see the login form (without images) but authentication doesn’t change anything (it doesn’t get authenticated, no cookies).
*** Start SSL Handshake: Session 2a, Thread 7d74, Clock 100231 *** SSL Handshake Success: Session 2a, Thread 7d74, Clock 100246 *** New Request – Parse and Check Request: Session 2a, Thread 7d74, Clock 100246 GET /names.nsf?login HTTP/1.1 Host: mobile1.developi.info User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Language: en,tr;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive *** Process Request: Session 2a, Thread 7d74, Clock 100246 *** Client IP Address [127.0.0.1], Server IP Address [127.0.0.1]: Session 2a, Thread 7d74, Clock 100246 *** Start Request Step: Session 2a, Thread 7d74, Clock 100246 *** Raw Request Step: Session 2a, Thread 7d74, Clock 100246 *** Pre Authenticate Step: Session 2a, Thread 7d74, Clock 100246 *** Post write Buffer, bytes [205]: Session 2a, Thread 7d74, Clock 100246 HTTP/1.1 200 OK Server: Lotus-Domino Date: Thu, 28 Mar 2013 09:36:24 GMT Expires: Tue, 01 Jan 1980 06:00:00 GMT Content-Type: text/html; charset=UTF-8 Content-Length: 6299 Cache-control: no-cache
I get the login form after that, and submit username password;
*** Start SSL Handshake: Session 17d, Thread 7d74, Clock 431359 *** SSL Handshake Success: Session 17d, Thread 7d74, Clock 431374 *** New Request – Parse and Check Request: Session 17d, Thread 7d74, Clock 431374 POST /names.nsf?Login HTTP/1.1 Host: mobile1.developi.info User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Language: en,tr;q=0.5 Accept-Encoding: gzip, deflate Referer: https://mobile1.developi.info/names.nsf?Login https://mobile1.developi.info/names.nsf?Login Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 91 *** Process Request: Session 17d, Thread 7d74, Clock 431374 *** Client IP Address [127.0.0.1], Server IP Address [127.0.0.1]: Session 17d, Thread 7d74, Clock 431374 *** Start Request Step: Session 17d, Thread 7d74, Clock 431374 *** Raw Request Step: Session 17d, Thread 7d74, Clock 431374 *** Pre Authenticate Step: Session 17d, Thread 7d74, Clock 431374 *** Authenticate Step: Session 17d, Thread 7d74, Clock 431374 *** Post write Buffer, bytes [176]: Session 17d, Thread 7d74, Clock 431374 HTTP/1.1 302 Found Server: Lotus-Domino Date: Thu, 28 Mar 2013 09:41:55 GMT Connection: close Location: https://mobile1.developi.info/names.nsf?Login https://mobile1.developi.info/names.nsf?Login Content-Length: 0 *** End Request Step: Session 17d, Thread 7d74, Clock 431374 *** Log Request: Session 17d, Thread 7d74, Clock 431374
The problem might be related to authentication, but it acts strange. I tried turning off Name & Password authentication for SSL, the problem still continues.
Subject: We still cannot reproduce
No matter what we have done, set redirection settings in both internet sites, web configuration view and on database properties we have not been able to reproduce the issue. We have tried this on new/overlay installs on many machines and we cannot reproduce the problem (very frustrating). Even some of our internal 90 servers that have these settings do not exhibit this issue.
The only explanation we have is that It appears that some context that is passed into the Domino Web App Layer is clobbered or not set for some reason and the code thinks the connection is not ssl, so it does a redirect. There are no code changes in these areas so it is a mystery why this is happening in some environments and not others.
In all cases that have been uploaded with regard to the Redirect TCP to SSL settings in the NAB, the request processing has already gone by the check that is made by the http stack, so the http stack is not doing the redirect to ssl and is correctly seeing the network connection is ssl. The redirect is being done in a different location.
If the http stack does the redirection one sees the following sequence in the htthr* log files (see below)
You will notice that if the http stack does the redirection, you will NOT see any of the processing steps, like the following, see the log example below from my attempt to reproduce.
*** Start Request Step: Session 2, Thread 281c, Clock 67860
*** Raw Request Step: Session 2, Thread 281c, Clock 69358
*** Pre Authenticate Step: Session 2, Thread 281c, Clock 69358
*** Authenticate Step: Session 2, Thread 281c, Clock 69373
In your case below, you see the following steps in the log, which means the http stack check of the Redirect tcp to SSL flag in the NAB has already been done and has not resulted in a redirect. It looks like checks done in the authentication code is causing the redirect. And it appears that can only happen only if the code fails the ssl connection check, bad context.
*** Start Request Step: Session 17d, Thread 7d74, Clock 431374
*** Raw Request Step: Session 17d, Thread 7d74, Clock 431374
*** Pre Authenticate Step: Session 17d, Thread 7d74, Clock 431374
*** Authenticate Step: Session 17d, Thread 7d74, Clock 431374
*** Post write Buffer, bytes [176]: Session 17d, Thread 7d74, Clock 431374
In the other cases with mail the redirect occurred in process request step and was also pass the http stack Redirect TCP to SSL check. That also may point to some context that was clobbered/incorrect.
I may be helpful to know all of your security settings (many of them do have interactions with other settings).
Thanks for the update
One of my attempts to reproduce, I get the login page and when I login I will get the resource over ssl, I have tried all the combinations I can think of, and our QE has also attempted to independently reproduce but still no joy.
*** New Request – Parse and Check Request: Session 0, Thread 281c, Clock 66674
GET /foo.txt HTTP/1.1
Host: xxx…ibm.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
*** Process Request: Session 0, Thread 281c, Clock 66690
*** Client IP Address [x.xx.xxx.xxx], Server IP Address [x.xx.xxx.xxx]: Session 0, Thread 281c, Clock 66690
HTTP STACK DOES THE REDIRECTION HERE AND PROCESSING ENDS, NOTICE NO REQUEST STEPS.
*** Post write Buffer, bytes [165]: Session 0, Thread 281c, Clock 66690
HTTP/1.1 302 Found
Server: Lotus-Domino
Date: Thu, 28 Mar 2013 16:06:20 GMT
Connection: close
Location: https://xxx.ibm.com/foo https://wrath.swg.usma.ibm.com/foo.txt
Content-Length: 0
*** Log Request: Session 0, Thread 281c, Clock 66690
*** Start SSL Handshake: Session 2, Thread 281c, Clock 67720
*** SSL Handshake Success: Session 2, Thread 281c, Clock 67735
*** New Request – Parse and Check Request: Session 2, Thread 281c, Clock 67829
GET /foo.txt HTTP/1.1
Host: xxx…ibm.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
*** Process Request: Session 2, Thread 281c, Clock 67860
*** Client IP Address [x.xx.xxx.xxx], Server IP Address [x.xx.xxx.xxx]: Session 2, Thread 281c, Clock 67860
*** Start Request Step: Session 2, Thread 281c, Clock 67860
*** Raw Request Step: Session 2, Thread 281c, Clock 69358
*** Pre Authenticate Step: Session 2, Thread 281c, Clock 69358
*** Authenticate Step: Session 2, Thread 281c, Clock 69373
*** Post write Buffer, bytes [205]: Session 2, Thread 281c, Clock 69373
HTTP/1.1 200 OK
Server: Lotus-Domino
Date: Thu, 28 Mar 2013 16:06:23 GMT
Expires: Tue, 01 Jan 1980 06:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1369
Cache-control: no-cache
Subject: bases is chose Require SSL connection
I have a similar problem if beside bases is chose Require SSL connection
decision already there is?
Subject: Looks like an authentication issue
Looks like 2 different issues
Issue 1,
Assuming you have session base authentication enable, looks like the server is not sending back the login page. The redirect response is coming from the authentication step. We are already passed the code where http to https redirect flag is checked, so the redirect from http to https flag is not causing the problem, looks like there is an issue with authentication failing to do the correct action.
Issue 2
DWA redirect DB
Do not know why that would be sending back a 302
Do not know if the issues are related to the same root cause, may be an issue with Authentication processing
Will continue to investigate
This appears that a code fix may be needed, so a PMR will be needed in any event for any fixes to be given out.
Thanks for the info, it will help narrow the use case.
Subject: RE: Redirect TCP to SSL setting and infinite redirection
I just upgraded our 8.5.3 server to Domino 9 and I can confirm that I have the same problem with “redirect to SSL” as a server setting.
I have used tihs setting to redirect all traffic to SSL for several years without a problem and right after the upgrade it now does not work at all.
Firefox says:
The page isn’t redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
Because the whole server (Web site document for the domain) is set in the security Tab to “Redirect TCP to SSL” no http now works! (sad face).
This is very very bad.
Especially since we have had a working environment for s few years and the upgrade now forces me to remove SSL from the whole server.
It looks to me as if SSL is “broken” on Domino 9.
UPDATE: I removed the “Redirect to SSL” in the Web Site Document and also removed the “Redirect to SSL” TCP/IP port status on the server document (ports → Internet ports → Web tab)
This made my server “usable” again. (without SSL)
Observe! SSL now works if I manually add the https tag on the url.
But with the 2 settings I described above set to redirect to SSL the server goes in an infinite redirect loop.
I even tried to remove the “server document” setting and only use the Web site redirect but it still went into infinite loops.
(even though It looked like it worked when I was logged in already).
Subject: RE: Redirect TCP to SSL setting and infinite redirection
Mike,
The issue occurs on three different servers of mine (two of them are test servers, one on linux, one on windows). I can confirm that it happens on w32, w64 and SLES x86. Two test servers are fresh install, the other one is upgrade from 8.5.3.
When you enable IHS, the problem disappears.
I checked the thread logs for my local test server:
*** Start SSL Handshake: Session 2a, Thread 2724, Clock 46676 *** SSL Handshake Success: Session 2a, Thread 2724, Clock 46676 *** New Request – Parse and Check Request: Session 2a, Thread 2724, Clock 46676 GET /xpagesext.nsf/ HTTP/1.1 Host: mobile1.developi.info Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22 DNT: 1 Accept-Encoding: gzip,deflate,sdch Accept-Language: tr,en-US;q=0.8 Accept-Charset: windows-1254,utf-8;q=0.7,;q=0.3 Cookie: __utma=136476325.946743872.1357160024.1357160024.1357300380.2; __utmz=136476325.1357160024.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=68591373.1911003467.1361202217.1361202217.1361202217.1; __utmz=68591373.1361202217.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) *** Process Request: Session 2a, Thread 2724, Clock 46691 *** Client IP Address [127.0.0.1], Server IP Address [127.0.0.1]: Session 2a, Thread 2724, Clock 46691 *** Start Request Step: Session 2a, Thread 2724, Clock 46691 *** Raw Request Step: Session 2a, Thread 2724, Clock 46691 *** Pre Authenticate Step: Session 2a, Thread 2724, Clock 46691 *** Authenticate Step: Session 2a, Thread 2724, Clock 46691 *** Post write Buffer, bytes [175]: Session 2a, Thread 2724, Clock 46691 HTTP/1.1 302 Found Server: Lotus-Domino Date: Mon, 25 Mar 2013 11:20:25 GMT Connection: close Location: https://mobile1.developi.info/xpagesext.nsf/ https://mobile1.developi.info/xpagesext.nsf/ Content-Length: 0 *** Post write Buffer(1), no pending buffers: Session 2a, Thread 2724, Clock 46691 *** Post write buffer(4), Buffer written to network: Session 2a, Thread 2724, Clock 46691 *** Release write Buffer, bytes written [200], bytes in buffer [200], info [0]: Session 2a, Thread 2724, Clock 46691 *** End Request Step: Session 2a, Thread 2724, Clock 46691 *** Log Request: Session 2a, Thread 2724, Clock 46691 *** Start SSL Handshake: Session 2d, Thread 2724, Clock 46754 *** SSL Handshake Success: Session 2d, Thread 2724, Clock 46754 *** Start SSL Handshake: Session 30, Thread 2724, Clock 46816 *** SSL Handshake Success: Session 30, Thread 2724, Clock 46816 *** New Request – Parse and Check Request: Session 30, Thread 2724, Clock 46816 GET /xpagesext.nsf/ HTTP/1.1 Host: mobile1.developi.info Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22 DNT: 1 Accept-Encoding: gzip,deflate,sdch Accept-Language: tr,en-US;q=0.8 Accept-Charset: windows-1254,utf-8;q=0.7,;q=0.3 Cookie: __utma=136476325.946743872.1357160024.1357160024.1357300380.2; __utmz=136476325.1357160024.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=68591373.1911003467.1361202217.1361202217.1361202217.1; __utmz=68591373.1361202217.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none) *** Process Request: Session 30, Thread 2724, Clock 46816 *** Client IP Address [127.0.0.1], Server IP Address [127.0.0.1]: Session 30, Thread 2724, Clock 46816 *** Start Request Step: Session 30, Thread 2724, Clock 46816 *** Raw Request Step: Session 30, Thread 2724, Clock 46816 *** Pre Authenticate Step: Session 30, Thread 2724, Clock 46816 *** Authenticate Step: Session 30, Thread 2724, Clock 46816 *** Post write Buffer, bytes [175]: Session 30, Thread 2724, Clock 46816 HTTP/1.1 302 Found Server: Lotus-Domino Date: Mon, 25 Mar 2013 11:20:26 GMT Connection: close Location: https://mobile1.developi.info/xpagesext.nsf/ https://mobile1.developi.info/xpagesext.nsf/ Content-Length: 0
This redirection sequence goes the same until browser gives up.
Configuration is nothing special. I’m using Internet sites with SSL enabled.
I can’t open PMR for myself (I’m a business partner and don’t have Value Package) and I can’t share log/dump files publicly. But I can post this issue into DP forum.
Thanks.
Subject: RE: Redirect TCP to SSL setting and infinite redirection
Our two servers are both affected. Both run 32-bit Domino (on 64-bit Windows). Without IHS.
One uses Internet Sites and one traditional Web Configuration documents.
As I wrote, I did not use the server-global “Redirecto to SSL” port setting but rather individual “Require SSL” properties on NSF databases.
But I guess the bad effect is the same.
I can provide these debug log files. Mike, please download with the link below? Too large to paste in here.
Download here http://www.ars.de/file/redirect-ssl-bug.zip
Subject: RE: Redirect TCP to SSL setting and infinite redirection
This is a serious one.
And it is even worse:
It is sufficient if you set the “Redirect to SSL” flag on a single database then accessing it with the browser will send you into the redirection loop.
This has worked for decades so how did they manage to break this now!
Subject: RE: Redirect TCP to SSL setting and infinite redirection
Would it be helpful if I prepare a VM as I described and make it available to you?
Subject: VM
Yes, we could try that,
or we can also try the following following as a first step, then do the vm as a second step
Provide the following
- Your Test Server NAB (and maybe the db you are testing with the ssl bit set you are testing with like webadmin.nsf from the test machine.).
- Your Test Server ID, and any admin id file to admin the server.
- Your notes.ini file
- Any user id/passwords you are using or open up the db with the ssl bit, or if you can open the db to anonymous access (and still reproduce the issue), that would be great
- Exact details on what you are doing to reproduce, so I can do exactly the same steps.
I can change the keyring file to use my keyring so the ssl port works.
If I can reproduce it with your configuration, I will be able to debug and find the problem quickly.
If I cannot reproduce with the above, then getting a vm is the next step, but the vm need a little more work getting going here in our lab (I have to involve other groups).
The key for us is to get it reproduced
Thanks for the offer
Subject: RE: Redirect TCP to SSL setting and infinite redirection
We are using Multi-Server SSO (LTPA). However, we have been using this for years.
And yes, we have a domcfg.nsf but it is using the default form coming with it (just to avoid the ugly default form).
As I wrote the problem goes away once I remove the “Require SSL” flag from the NSF database.
Removing the domcfg.nsf completely, does not change the behaviour.
Disabling SSO also does not change it.
Subject: RE: Redirect TCP to SSL setting and infinite redirection
Mike, I’ll collect/send later this weekend.
Can you send me an e-mail address where to send to?
Mine is rommel at ars.de …