Webservice over SSL with multiple servers
-
We have four web servers each hosting our web service. We use DNS round robin to load balance across these four servers. In order to use SSL we have a certificate called for example, www.loadbalanced.com which is installed on all four machines. Things work beautifully. However, We now have a new internal application that needs to consume the web service over SSL but requires access to specific web servers, i.e. using they internal hostname, Unfortunely the SSL connection no longer works, I'm assuming this is because the hostname does not match the SSL certificate name. Can this be programmatically overriden? Just like clicking the security warning dialog box that appears when browsing a secure site using IE with a different hostname. Many thanks in advance. ps Alternative ways of depoloying the application to achieve the same affect also welcomed
-
We have four web servers each hosting our web service. We use DNS round robin to load balance across these four servers. In order to use SSL we have a certificate called for example, www.loadbalanced.com which is installed on all four machines. Things work beautifully. However, We now have a new internal application that needs to consume the web service over SSL but requires access to specific web servers, i.e. using they internal hostname, Unfortunely the SSL connection no longer works, I'm assuming this is because the hostname does not match the SSL certificate name. Can this be programmatically overriden? Just like clicking the security warning dialog box that appears when browsing a secure site using IE with a different hostname. Many thanks in advance. ps Alternative ways of depoloying the application to achieve the same affect also welcomed
There doesn't seem to be any way to override it without implementing your own SSL handshaking. The fact that IE (or any web browser for that matter) allows you to do that isn't actually an accepted process since it means the certificate is not verifiable and be using an ADK to encrypt for a different server. Now, I'm not sure about your network topology, but in our setup, the web servers sit on a DMZ and have different names internally and externally. SSL could be forced on the site for external use but not for internal use (controlled by the firewall). Since this app is internal, why not just let it talk to the servers insecurely? Heck, you don't even need a DMZ to accomplish this, it's just easier to tell IIS how to differentiate traffic in case you've set IIS up to force SSL for connections. If you haven't done this for the whole site, you don't need to do anything really. Just segment the services so that the ones your clients use are forced to SSL and the ones you use aren't. If this is an externally deployed web site, you could do the same thing but you should take a look at WS-Security to secure your services. This could even be used for client access, but puts more burden on the developers as opposed to IIS, so it isn't always desired.
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
There doesn't seem to be any way to override it without implementing your own SSL handshaking. The fact that IE (or any web browser for that matter) allows you to do that isn't actually an accepted process since it means the certificate is not verifiable and be using an ADK to encrypt for a different server. Now, I'm not sure about your network topology, but in our setup, the web servers sit on a DMZ and have different names internally and externally. SSL could be forced on the site for external use but not for internal use (controlled by the firewall). Since this app is internal, why not just let it talk to the servers insecurely? Heck, you don't even need a DMZ to accomplish this, it's just easier to tell IIS how to differentiate traffic in case you've set IIS up to force SSL for connections. If you haven't done this for the whole site, you don't need to do anything really. Just segment the services so that the ones your clients use are forced to SSL and the ones you use aren't. If this is an externally deployed web site, you could do the same thing but you should take a look at WS-Security to secure your services. This could even be used for client access, but puts more burden on the developers as opposed to IIS, so it isn't always desired.
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
We have a similar topology with a DMZ but unfortunetly require ALL traffic to be secured with SSL (or other encryption) because of the sensitive data. How do we 'tell IIS to differentiate traffic', do you mean set different SSL requirements on different virtual directories? what if our internal & external clients are using the same pages? I'll have a read through WS-Security but I was hoping that IIS and ASP.NET could already handle this
-
We have a similar topology with a DMZ but unfortunetly require ALL traffic to be secured with SSL (or other encryption) because of the sensitive data. How do we 'tell IIS to differentiate traffic', do you mean set different SSL requirements on different virtual directories? what if our internal & external clients are using the same pages? I'll have a read through WS-Security but I was hoping that IIS and ASP.NET could already handle this
There are several ways you can do this. Our DMZ, for example, is on the reserved subnet 172.16. We have two IP addresses bound to it for different apps. You could, instead, bind two different IPs to each machine and have the firewall redirect to the appropriate IP based on whether or not the traffic is internal or external. Then in IIS, make two different Web apps pointing to the same directory. For the external web app, require SSL. For the internal web app, leave it as optional. If you did use WS-Security, you could get around this by checking the remote machine's IP and and skip encryption and verification for that traffic. Again, though, this will leave you with some of the work, although WS-Security does make it easier than just using the crypto classes directly. You may find, too, that WS-Security gives you some additional features that would be nice in your app, such as policies for requiring certain things. It will require some changes in both the client and server, but depending on your business model it may be better in the end. The big problem is that the .NET BCL doesn't really have a way for overriding the SSL handshaking that I've ever seen. If the SSL cert doesn't verify, an exception is thrown. There doesn't seem to be a way to change that. Technically speaking, that's the way it should be (you wouldn't want to trust a certificate from the server with an ADK since that opens you up for a man-in-the-middle attack), but I can understand that it isn't always desired. Perhaps you can make a comment to the .NET team for future enhancements on the .NET section of MSDN.
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
We have a similar topology with a DMZ but unfortunetly require ALL traffic to be secured with SSL (or other encryption) because of the sensitive data. How do we 'tell IIS to differentiate traffic', do you mean set different SSL requirements on different virtual directories? what if our internal & external clients are using the same pages? I'll have a read through WS-Security but I was hoping that IIS and ASP.NET could already handle this
Oh, one more thing. VeriSign does offer domain certificates. I don't know exactly how they work since it's been a long time since I've looked into what they offer, but it might be worth checking out. I don't know if the certificate contains special OIDs or something, or if you can just buy bulk certificates, but each server could, potentially, be able to use different keys based on the requested Host header.
-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----