Products

Price/Order

Support

Partners

Testimonials

Test Results

About us

Contact
 TRtcHttpServer with multiple SSL hosts
Bottom
 
Total posts: 10
 Author TRtcHttpServer with multiple SSL hosts
Richard Berends

07.05.2009 20:46:42
Registered user
I'm looking at adding SSL to a web server project so I'm trying out SecureBlackBox, which all seemed to fit together quite nicely - with one host/dir/certificate. However as soon as I add a second host/dir/certificate, it seems to insist on using the first certificate... Is there any way to get it to use the correct certificate?

The only way so far that I've found to make it use the right one, is to intercept TRtcHttpServer.OnConnecting and swap out the TSSLServerRtcCryptPlugin's CertStorage with one that has just the single correct certificate, of course this isn't a real solution since at this point Request.Host isn't filled in so outside the IDE I don't know which is the right certificate to plug in...

Rick
Danijel Tkalcec [RTC]

07.05.2009 20:59:07
Registered user
To find a solution to your current problem, I would recommend you to contact "Eldos". RTC SDK only provides a plug-in interface for SSL encryption components, but the encryption components as well as their plug-ins with any properties and events are entirely implemented by encryption component vendors ("Eldos" wrote the plug-in for "SecureBlackBox" components, while "StreamSec" wrote the plug-in for "StreamSec Tools" components).

I can not help you solve your problem, but I am quite positive that changing properties of the encryption plug-in component on an active Server will result in chaos because all connection components are sharing the same encryption plug-in and changing properties on that plug-in or components connected to the plug-in will affect all connections and not only the connection which is making the change. On top of that, making changes on the plug-in of a running Server will probably result in Access Violations in case any other connection is using the plug-in at the time the change is being made.

Best Regards,
Danijel Tkalcec
Richard Berends

08.05.2009 12:35:56
Registered user
OK, thanks Danijel, I'll try Eldos..

BTW, I've a couple of bug fixes I need to send you, one is the with WinHTTP timeouts, remember I had that problem with 30 sec WinSock Timeouts? well the same is happening after we had to switch to WinHTTP, so in rtcWinHttpCliProv.pas I had to add:

procedure TRtcWinHttpClientProvider.WriteHeader(SendNow:boolean=True);
  var
...
    myTimeout:DWORD;
...
  myTimeout := 600000;
  InternetSetOption(hRequest, WINHTTP_OPTION_RESOLVE_TIMEOUT, Addr(myTimeout), SizeOf(myTimeout));
  InternetSetOption(hRequest, WINHTTP_OPTION_CONNECT_TIMEOUT, Addr(myTimeout), SizeOf(myTimeout));
  InternetSetOption(hRequest, WINHTTP_OPTION_SEND_TIMEOUT, Addr(myTimeout), SizeOf(myTimeout));
  InternetSetOption(hRequest, WINHTTP_OPTION_RECEIVE_TIMEOUT, Addr(myTimeout), SizeOf(myTimeout));
  InternetSetOption(hRequest, WINHTTP_OPTION_RECEIVE_RESPONSE_TIMEOUT, Addr(myTimeout), SizeOf(myTimeout));
...

Not sure if this is exactly the right place/thing to do, but you get the idea..

The other one is with Portal, but I need to sort out our subscription etc, and you may have already fixed it. It's a problem with RTCHost on a Windows server with the Mirror driver and TS Clients connecting, as soon as a TS Client connects, RTCHost connections give back a white screen. I traced the problem to dfmVideoDriver.pas where you're enumerating the screens correctly, but ignoring the matching mirror driver screen and going with the default then after a TS Connection the default screen seems to be the last TS Session which gives the white screen.

Rick
Richard Berends

08.05.2009 12:53:12
Registered user
Well unfortunately Eugene says the SSL/TLS handshake happens before HTTP, so it has to have it's own IP address, darn this is going to get complicated..

Rick
Danijel Tkalcec [RTC]

08.05.2009 13:20:40
Registered user
Hi Richard,

Thanks for your feedback on the timeout issue with the WinHTTP API.

The place you've added the code seems about right (I guess you are doing this after the "hRequest" variable was successfully initialized). I will add your suggested code for extending SEND, RECEIVE and RECEIVE_RESPONSE timeouts to the standard RTC SDK implementation with the next update, but I will leave the RESOLVE and CONNECT timeouts at their default values, so the user does not end up waiting too long if they enter a wrong Address or Port number.

As for the RTC Portal issue after a Terminal Services Client connects, I still have that problem. If someone else was using MS RDP, the screen of the RTC Host will go white/blank when you try to use it. I do not know what the problem is or how to solve it, but if you think you have found a working solution, I'd be happy to give you a lifetime RTC Portal VCL subscription if you are willing to share that fix.

I've extended your RTC Portal VCL subscription so you can download the latest version and see if you can get it working with MS RDP. If you have the fix already working on your local copy, you can either post the changes here (like you've done for the WinHTTP update above) or send me the complete "dfmVideoDriver.pas" file by E-Mail (RTC Support address), so I can include it in the next RTC Portal VCL update.

Best Regards,
Danijel Tkalcec
Richard Berends

08.05.2009 14:16:19
Registered user
Hi Danijel,

Thanks for all that, I'll WinMerge your latest into mine and double check the fix still works. Then I'll reply to your mail about getting the fix to you..

Rick
Richard Berends

08.05.2009 16:00:12
Registered user
Hi Danijel,

Well things are getting a bit complicated. I was on 3.31 with my fix, no white screens (W/S or Server). I installed your latest 3.47 without my fixes, under Delphi 7, within an XP VM, with the Mirror driver enabled, I get a white screen straight off. Thought it might have been something to do with my build environment, so I downloaded your 3.47 exe's, same result, white screen. Disabled mirror driver and all OK.

To double check I went back to the un-modified 3.31, worked fine, added my fixes, still fine (since they only really apply to TS, that was kinda expected). Disabled mirror driver and still OK.

Is this a known problem with 3.47, or is there something strange at my end..

Rick
Danijel Tkalcec [RTC]

08.05.2009 16:33:31
Registered user
Hi Richard,

if you are testing this with a Host running as a Service, try uninstalling the old Host service and installing the new one. Not sure if this has anything to do with your problem, but older Host Service versions did NOT require the "interact with desktop" option to be enabled, while the NEW one does (had something to do with making the code compatible with D2009).

Also, make sure to use the latest RTC Control, because the old RTC Control does not understand the new screen encoding mode implemented in the new RTC Host, so you will always get a white screen with the old Control when used with the new Host, even if the new Host is running as a normal windowed process.

Let me know if that has solved your problem.

Regards,
Danijel
Richard Berends

08.05.2009 16:52:02
Registered user
Hi Danijel,

Yep, thanks that was it, the 3.31 control doesn't like the 3.47 hosts. Now to check it works on the TS server...

Rick
Danijel Tkalcec [RTC]

08.05.2009 20:54:01
Registered user
Thanks for the file.

I've tested your solution on two systems where MS RDP is often used in combination with RTC Host and your modifications make quite a difference. Updated RTC SDK and RTC Portal VCL components with your suggested additions are now available through the RTC Download Area.

Thanks again for sharing. I've updated your RTC Portal VCL subscription.

Best Regards,
Danijel Tkalcec