This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal


~Karl Quetjumitherikle
Mar 25, 2013, 11:30 AM
8 Posts

Redirect TCP to SSL setting and infinite redirection

  • Category: Domino Server
  • Platform: Windows
  • Release: 9.0
  • Role: Administrator
  • Tags: HTTP,SSL,Security
  • Replies: 24

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.

 

~James Umretherli
Mar 25, 2013, 6:45 PM
18 Posts
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!

~Arnold Frofreeburoni
Mar 25, 2013, 7:12 PM
27 Posts
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
~Phil Brewesonettu
Mar 26, 2013, 8:42 AM
2 Posts
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).

 

~Karl Quetjumitherikle
Mar 26, 2013, 9:08 AM
8 Posts
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
 
 
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
 
 
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.

 

~James Umretherli
Mar 26, 2013, 10:59 AM
18 Posts
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

~Arnold Frofreeburoni
Mar 26, 2013, 1:25 PM
27 Posts
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.
~Phil Brewesonettu
Mar 26, 2013, 2:05 PM
2 Posts
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).

~Arnold Frofreeburoni
Mar 26, 2013, 2:45 PM
27 Posts
Can you confirm a couple of settings
1. I assume you are using session authentication, (single server or lpta). Is that correct?, If not what type of authentication configuration are you using?
2. I assume you have a custom login page defined in domcfg.nsf, correct? (depends on answer above)
3. 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
~James Umretherli
Mar 26, 2013, 6:34 PM
18 Posts
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.

~Karl Quetjumitherikle
Mar 28, 2013, 9:43 AM
8 Posts
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
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
 
 
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. 

 

~Arnold Frofreeburoni
Mar 28, 2013, 4:15 PM
27 Posts
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.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
~Karl Quetjumitherikle
Mar 29, 2013, 12:10 PM
8 Posts
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!

~Arnold Frofreeburoni
Apr 1, 2013, 12:39 PM
27 Posts
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.
~James Umretherli
Mar 29, 2013, 5:13 PM
18 Posts
RE: Redirect TCP to SSL setting and infinite redirection

Mike, I don't know what you are trying, but ...

I just took a fresh plain Windows Server 2008 R2 VM and installed Domino 9.0 with as few clicks as possible, e.g. all defaults but plus IHS. Of course I also installed a Domino admin in order to manage it.

Then I set up/configured that Domino server, again with as few clicks as possible, everything left as defaults (except enabling the HTTP task). I created SSL keys and certificates as usual, via an internal CA we have (Domino CA in our production environment). Enabled SSL, worked fine. Authentication was left as basic (default). No internet sites, no web configs, no nothing.

I used webadmin.nsf for the test. I fired it up and HTTP and HTTPS access worked fine to webadmin.nsf. I went to the Domino Admin and set the "Require SSL" flag on webadmin.nsf. Started a fresh IE browser and accessed the webadmin.nsf and voila, had the bug, i.e. the browser got into that endless redirection loop, even before the authentication came up (so like someone else also stated, I guess this will also happen for anonymous access).

Mike, I cannot understand how you are unable to reproduce this ... hard to imagine a simpler reproducible setup and bug.

By the way, out of curiosity, I also tested with the new IHS feature (that was the actual reason why I installed this test server, to evaluate IHS).

I also created the necessary SSL keys/certificates for it and activated it. Interestingly, when going through IHS, the problem did NOT show up.

However, I think not everyone will rush out and use IHS just because it appeared in the product ...

 

~Arnold Frofreeburoni
Apr 1, 2013, 12:52 PM
27 Posts
What do you mean by this
Did exactly what you did, cannot reproduce.

All defaults but plus IHS????, what does that statement mean. We have set up new servers we tested without IHS and cannot reproduce no matter what we do.  We have also tested with IHS (not Websphere Web Proxy Modules) and cannot reproduce there either.  There is something specific in your environment and your problem (if not related to HTTPEnableConnectorHeaders) is different from the other customer who resolved their issue.

Also see above post about HTTPEnableConnectorHeaders=1, this must not be in your INI.

I just took a fresh plain Windows Server 2008 R2 VM and installed Domino 9.0 with as few clicks as possible, e.g. all defaults but plus IHS. Of course I also installed a Domino admin in order to manage it.

~Arnold Frofreeburoni
Apr 1, 2013, 4:40 PM
27 Posts
Think we found the use case/issue causing the problem
I believe the missing configuration setting that you have set and we do not is HTTPEnableConnectorHeaders=1.  It was not clear that this was a player in the configuration until the recent posts.

Looking at the changes between 853 and 9.0 if one sets the ini HTTPEnableConnectorHeaders=1 and one connects to the Domino Server locally (not going through IHS Reverse Proxy Modules) with a redirect to ssl on, the infinite redirection loop can occur.

The code looks for the $WSIS header, and if not present will set the ssl connection to false (even if the direct connection to Domino is ssl).

 In 8.53 if the header was not present and the HTTPEnableConnectorHeaders=1, the ssl connection was set based on the local Domino tcp port (443, 80) etc.
In 9.0 if the header is not present and HTTPEnableConnectorHeaders=1, the ssl connection is set to false, thereby causing the layers of code below to think the connection is not ssl and to do the redirection.

The change that introduced  this was made in the context of the new IHS/mod_domino proxy changes made to 90.

The use case that I suspect is that one has is that local one does admin over ssl by direct connections to the Domino Server, but has all other clients going through the IHS Reverse Proxy plugins for access to the Domino server.

If not using IHS WAS reverse proxy modules, then one can remove the above ini and things will work correctly.

We have generated spr DMEA96CMVX for this issue

Thanks for the info.

This spr should be addressed in the first update to the Domino 9.0 release
~James Umretherli
Apr 1, 2013, 7:48 PM
18 Posts
RE: Redirect TCP to SSL setting and infinite redirection

Well, it means what I wrote. I installed with everything left at defaults except that I added IHS. However, that of course does not activate IHS yet.

My later text explains that the problem happened only when working with the regular HTTP task without activating IHS.

And of course also the notes.ini was left at defaults (that means no changes whatsoever by me) for that last test.

It is - in my opinion - not possible that you cannot reproduce it ... :-)

If you don't believe - we can do a TeamViewer session ...

~Arnold Frofreeburoni
Apr 1, 2013, 7:56 PM
27 Posts
one use case, the key was having HTTPEnableConnectorHeader
Without the above ini we cannot reproduce, we have tried on about 10 different machines, new installs over installs etc, however, if the ini is present in the notes.ini we can reproduce the issue. We have installed new servers many times taking all the defaults and still cannot make it happen.  I attempted to exactly what you did Windows 2008r2, both 32 bit and 64 bit versions production version, created a key ring file, set the bit on webadmin.nsf to redirect to ssl and everything works as it should, no redirection loops.

We do believe you that you are having an issue, we just cannot figure out how do get it to reproduce.  We have one code path/configuration combination that makes it happen, but it sounds like there may be another one as well.
~James Umretherli
Apr 2, 2013, 9:12 PM
18 Posts
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?

~Arnold Frofreeburoni
Apr 2, 2013, 9:24 PM
27 Posts
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

1. 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.).
2. Your Test Server ID, and any admin id file to admin the server.
3. Your notes.ini file
4. 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
5. 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
~Samuel Desboosizenakoi
Apr 5, 2013, 10:51 AM
1 Posts
bases is chose Require SSL connection
 I have a similar problem if beside bases is chose Require SSL connection



decision already there is?
~James Umretherli
Apr 6, 2013, 9:29 AM
18 Posts
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 ...

~James Umretherli
Apr 6, 2013, 6:51 PM
18 Posts
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?

 


This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal