Hello, Kind of new to this so fair warning if this is a bit obvious to some. We have a wildcard SSL for *.ourdomain.com and would like to use it for 4 sites like so; www.ourdomain.com samp.ourdomain.com west.ourdomain.com site.ourdomain.com What is the best
way to go about this? Can all 4 be the same IP on the IIS machine and just different ports? Thanks for any advice!
A straightforward solution which allows you to keep the preexisting DNS resource records for the subdomains in tact while only using one numeric IP address on one IIS server as well as using the one and only default TCP port 443 for HTTPS communications
is: utilize the well-tested SNI (Server Name Indication) extension originally specified for TLS version 1.0 in the IETF document RFC3546 back in 2003. It was expanded upon later by RFC4366 in 2006, and most recently RFC6066 in January of 2011. Thanks to consistent
development in the previous decade, SNI now has an almost ubiquitous implementation that's very solid in terms of both web server and browser/client support.
Essentially, it works by transmitting the fully qualified DNS domain name of the desired host as an optional TLS protocol data unit; more specifically, the hostname is set within an extended version of the ClientHello message type during the initial TLS
session negotiation process which takes place shortly after the TCP handshake under ideal circumstances. This technique is in stark contrast to the conventional approach based on detecting the Internet address assigned to the network interface where the
SOCKETaccept()'d the incoming TCP connection.
Admittedly, this is assuming that your initial desire wasn't to listen() on additional ports in the first place--I simply thought that option only came under consideration because of the lack of any other well-known or reasonable
solutions. There's also one relatively small catch: you'll need to be running version 8 of IIS in order to take full advantage of SNI; unless, of course, you'd rather run a public-facing HTTP daemon that has UNIX attitude like Apache, nginx, or Cherokee.
Otherwise, the forthcoming release of Windows Server 8 should offer an elegant remedy for you and many others in similar situations. The only other drawback you may encounter revolves around issues of compatability, but only if your user base is stuck with severely
antiquated browsers. If you ask me, encrypting transport layer data isn't going to do much good anyway, if the browser software hasn't been updated for five or more years.
If none of the above works for you at all, then perhaps this thread from a few years ago will:
http://forums.iis.net/p/1161905/1930148.aspx#1930148. Another individual stuck in a situation rather similar to yours was given advice to invest in a UCC (Unified Communications Certificate.) There's
a brief outline and a batch script included to help get you up and running fast if you're in a hurry.
In closing, I'd just like to point out what appears to be a URI syntax error in the first reply to the original poster's message. If I'm not mistaken, the colon-delimited port number should be infixed between the end of the hostname and the beginning of
the directory path, (instead of being appended to the filename extension.) Please inform me if that's incorrect; it's possible that I just haven't done much IIS server administration lately.
Hope This Helps,
Derek Callaway
P.S. Hyperlinked references related to my response are listed below:
Windows Server "8" Beta and
Consumer Preview have been released for quite a few weeks now, so I was wondering what sorts of experiences other beta testers have been having. I'm happy to see an MS-DOS command line that can be used to manage Server Name Indication (SNI) certificates.
I'm sure there's a way to do it with PowerShell, although there wasn't any mention in the articles posted on the official site here:
Don't forget you'll need to add "Centralized SSL Certificate Support" in Server Manager. This feature should save significant amounts of money on SSL certificates, i.e. less signatures from upstream authorities, because less purchases from a third-party
for e-commerce verification means less CSR's (certificate signing requests). Furthermore, multiple certificates with matching numeric IP addresses, but completely different domain names, allows server consolidation such that server consolidation may epitomize
the current cloudy virtualization trend; what a bargain! Save money on encryption, hardware, electricity, support, etc. Not to mention all the superfluous peripheral costs that come along with baby-sitting extraneous rackmount/blade servers that aren't even
really necessary to begin with; in fact, they're often counter-productive by stifling time that could have been spent increasing revenue and building customer relationships. It's also possible to optimize the caching of oft-needed
OCSP (Open Certificate Status Protocol) responses.
If implemented properly, this feature should thoroughly decrease typical business maintenance costs. One caveat that must be mentioned with respect to IIS web server consolidation on Windows 8 is the grave security risk that can arise from serving some site(s)
that require additional protection from the sophisticated attack techniques now emanating from all corners of the globe. In other words, avoid placing a merchandising site that regularly processes high volumes of orders for big ticket items on the same SNI
SSL certificate or IIS web server that are otherwise dedicated to disseminating data almost entirely for informational purposes. Instead, isolate the high value site in its own Hyper-V virtual machine instance. If it still demands more safety, then simply host
it on a completely different server. Spending a little bit extra to protect reputations will be well worth it in the long run. It's not worth risking a costly incident against your most valued web presence simply because a lesser site happened to get compromised
in a manner unbeknownst to system administrators pre-occupied with other urgent tasks.
Aside from administrator mistakes, the only other concerns I have are the discovery of remotely exploitable memory corruption bugs in the Microsoft CryptoAPI or IIS itself, similar to cases of software requiring GnuTLS and/or OpenSSL such as
WebDAV. Aside from that, and as long as Microsoft performs a sufficient pre-release security analysis of the new IIS 8 code, therefore mitigating any repeat of
"Code Red" worms and such, then I feel comfortable going forward with Windows 8 as a whole. Overall, I've trusted Windows more than Linux for the past several years since Microsoft has really gotten their act together as far as kernel space anti-exploitation
features, SDLC (Secure Development LifeCycle) processes, and just a more proactive attitude towards ongoing trends in the information security sphere. Admittedly, any contemporary open source BSD flavors beat them both out. About a decade ago, I ran Windows
inside Linux--no more. As long the crew in Redmond continue to stay a few handspans ahead of the Linux advocates in both security and usability, I'll be running Linux in Windows and not the other way around for the forseeable future.
Happy Hacking,
Derek Callaway
P.S. Could it be possible or even feasible that SNI+SSL gets integrated into more encrypted Microsoft network services--FTP or SMTP perhaps??
SSLftpSMTPSNIIIS8Windows Server Consumer PreviewBSDCryptoAPISDLC
rahlquist
8 Posts
Wildcard SSL, multiple sites, single IP?
Nov 08, 2011 12:11 PM|LINK
jeff@zina.co...
3379 Posts
MVP
Moderator
Re: Wildcard SSL, multiple sites, single IP?
Nov 08, 2011 02:17 PM|LINK
The issue with alternate ports is that you will need to assign the port on the URL for anything other than standard HTTPS. Something like:
https://www.sample.com/mylinks/securefile.aspx:8080
Then you would need to configure the site to answer SSL on port 8080.
An alternative is to create the subdomains of www, samp, site, etc. and rewrite them to apps within the same site.
Jeff
decal
2 Posts
Re: Wildcard SSL, multiple sites, single IP?
Nov 12, 2011 03:35 AM|LINK
A straightforward solution which allows you to keep the preexisting DNS resource records for the subdomains in tact while only using one numeric IP address on one IIS server as well as using the one and only default TCP port 443 for HTTPS communications is: utilize the well-tested SNI (Server Name Indication) extension originally specified for TLS version 1.0 in the IETF document RFC3546 back in 2003. It was expanded upon later by RFC4366 in 2006, and most recently RFC6066 in January of 2011. Thanks to consistent development in the previous decade, SNI now has an almost ubiquitous implementation that's very solid in terms of both web server and browser/client support.
Essentially, it works by transmitting the fully qualified DNS domain name of the desired host as an optional TLS protocol data unit; more specifically, the hostname is set within an extended version of the ClientHello message type during the initial TLS session negotiation process which takes place shortly after the TCP handshake under ideal circumstances. This technique is in stark contrast to the conventional approach based on detecting the Internet address assigned to the network interface where the SOCKET accept()'d the incoming TCP connection.
Admittedly, this is assuming that your initial desire wasn't to listen() on additional ports in the first place--I simply thought that option only came under consideration because of the lack of any other well-known or reasonable solutions. There's also one relatively small catch: you'll need to be running version 8 of IIS in order to take full advantage of SNI; unless, of course, you'd rather run a public-facing HTTP daemon that has UNIX attitude like Apache, nginx, or Cherokee. Otherwise, the forthcoming release of Windows Server 8 should offer an elegant remedy for you and many others in similar situations. The only other drawback you may encounter revolves around issues of compatability, but only if your user base is stuck with severely antiquated browsers. If you ask me, encrypting transport layer data isn't going to do much good anyway, if the browser software hasn't been updated for five or more years.
If none of the above works for you at all, then perhaps this thread from a few years ago will: http://forums.iis.net/p/1161905/1930148.aspx#1930148. Another individual stuck in a situation rather similar to yours was given advice to invest in a UCC (Unified Communications Certificate.) There's a brief outline and a batch script included to help get you up and running fast if you're in a hurry.
In closing, I'd just like to point out what appears to be a URI syntax error in the first reply to the original poster's message. If I'm not mistaken, the colon-delimited port number should be infixed between the end of the hostname and the beginning of the directory path, (instead of being appended to the filename extension.) Please inform me if that's incorrect; it's possible that I just haven't done much IIS server administration lately.
Hope This Helps,
Derek Callaway
P.S. Hyperlinked references related to my response are listed below:
SSL TLS http UCC RFC TCP SNI IETF URI IIS8 UNIX
decal
2 Posts
Re: Wildcard SSL, multiple sites, single IP?
Apr 24, 2012 12:05 PM|LINK
Windows Server "8" Beta and Consumer Preview have been released for quite a few weeks now, so I was wondering what sorts of experiences other beta testers have been having. I'm happy to see an MS-DOS command line that can be used to manage Server Name Indication (SNI) certificates. I'm sure there's a way to do it with PowerShell, although there wasn't any mention in the articles posted on the official site here:
netsh http show sslcert
http://learn.iis.net/page.aspx/1096/iis-80-server-name-indication-sni-ssl-scalability/
http://learn.iis.net/page.aspx/1091/iis-80-centralized-ssl-certificate-support-ssl-scalability-and-manageability/
Don't forget you'll need to add "Centralized SSL Certificate Support" in Server Manager. This feature should save significant amounts of money on SSL certificates, i.e. less signatures from upstream authorities, because less purchases from a third-party for e-commerce verification means less CSR's (certificate signing requests). Furthermore, multiple certificates with matching numeric IP addresses, but completely different domain names, allows server consolidation such that server consolidation may epitomize the current cloudy virtualization trend; what a bargain! Save money on encryption, hardware, electricity, support, etc. Not to mention all the superfluous peripheral costs that come along with baby-sitting extraneous rackmount/blade servers that aren't even really necessary to begin with; in fact, they're often counter-productive by stifling time that could have been spent increasing revenue and building customer relationships. It's also possible to optimize the caching of oft-needed OCSP (Open Certificate Status Protocol) responses.
If implemented properly, this feature should thoroughly decrease typical business maintenance costs. One caveat that must be mentioned with respect to IIS web server consolidation on Windows 8 is the grave security risk that can arise from serving some site(s) that require additional protection from the sophisticated attack techniques now emanating from all corners of the globe. In other words, avoid placing a merchandising site that regularly processes high volumes of orders for big ticket items on the same SNI SSL certificate or IIS web server that are otherwise dedicated to disseminating data almost entirely for informational purposes. Instead, isolate the high value site in its own Hyper-V virtual machine instance. If it still demands more safety, then simply host it on a completely different server. Spending a little bit extra to protect reputations will be well worth it in the long run. It's not worth risking a costly incident against your most valued web presence simply because a lesser site happened to get compromised in a manner unbeknownst to system administrators pre-occupied with other urgent tasks.
Aside from administrator mistakes, the only other concerns I have are the discovery of remotely exploitable memory corruption bugs in the Microsoft CryptoAPI or IIS itself, similar to cases of software requiring GnuTLS and/or OpenSSL such as WebDAV. Aside from that, and as long as Microsoft performs a sufficient pre-release security analysis of the new IIS 8 code, therefore mitigating any repeat of "Code Red" worms and such, then I feel comfortable going forward with Windows 8 as a whole. Overall, I've trusted Windows more than Linux for the past several years since Microsoft has really gotten their act together as far as kernel space anti-exploitation features, SDLC (Secure Development LifeCycle) processes, and just a more proactive attitude towards ongoing trends in the information security sphere. Admittedly, any contemporary open source BSD flavors beat them both out. About a decade ago, I ran Windows inside Linux--no more. As long the crew in Redmond continue to stay a few handspans ahead of the Linux advocates in both security and usability, I'll be running Linux in Windows and not the other way around for the forseeable future.
Happy Hacking,
Derek Callaway
P.S. Could it be possible or even feasible that SNI+SSL gets integrated into more encrypted Microsoft network services--FTP or SMTP perhaps??
SSL ftp SMTP SNI IIS8 Windows Server Consumer Preview BSD CryptoAPI SDLC