locked
Unable to get SNI certificate on Windows Server 2012 RRS feed

  • Question

  • User-2128161688 posted

    1. Create SNI binding "123.123.123.123:443:sni.iis8.com" with certificate "cert1" on "Default Web Site"
    2. Create non-SNI binding "123.123.123.123:443:non-sni.iis8.com" with certificate "cert2" on any web site
    3. Try to browse https://sni.iis8.com by SNI
    compliant browser - I get certificate "cert2" instead of "cert1"
    4. Remove non-SNI binding and browse 
    https://sni.iis8.com again - I get certificate "cert1"

    Is it a bug?

    How can I satisfy SNI compliant and non-SNI compliant browsers at the same time?
    Monday, October 1, 2012 10:47 PM

Answers

  • User690216013 posted
    I went through RFC6066 http://tools.ietf.org/html/rfc6066#page-6, but it does not go to details on how a web server should support both SNI and non-SNI clients. It either does not mention any required behavior in your scenario. Therefore, Microsoft has its freedom to implement whatever they think reasonable. It is so easy to say "I find a bug", but if it is by design, you will have to adapt to it. If you are a Microsoft Premier customer, you might discuss with your account manager.
    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, October 3, 2012 9:11 AM

All replies

  • User690216013 posted
    By searching about SSL host headers on the Internet, you might come across many posts that can explain the root cause. On 123.123.123.123:443, you might be able to set up many web sites with different host headers, but you cannot bind more than one certificate. That's what you noticed. It is not a bug, but a design limitation of HTTPS (any other web server suffers it too). Better solution is to use two IP addresses, such as 123.123.123.123:443 for cert1, and 123.123.123.124:443 for cert2. There are other solutions if you search.
    Tuesday, October 2, 2012 4:44 AM
  • User-2128161688 posted

    http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-server-name-indication-sni-ssl-scalability

     

     I can bind more then one certificate in SNI binding "123.123.123.123:443:host-name" on IIS 8

    Tuesday, October 2, 2012 4:56 AM
  • User690216013 posted
    Clearly in that article the binding is not IP:port. It states clearly that what is treated as traditional SSL bindings (IP:Port) and what are SNI bindings (Hostname:Port). As far as I can see, you are still using traditional SSL bindings, which suffers the traditional problem.
    Tuesday, October 2, 2012 5:56 AM
  • User-2128161688 posted

     I use traditional binding (IP:port) for non-SNI compliant browsers, and SNI binding (Hostname:Port) for SNI compliant browsers:

    ---------------------------------------------------------------

    Windows PowerShell
    Copyright (C) 2012 Microsoft Corporation. All rights reserved.

    PS C:\Users\Administrator> netsh http show sslcert

    SSL Certificate bindings:
    -------------------------

        IP:port                      : 10.52.183.108:443
        Certificate Hash             : e145c49fe92699fd4c7047b90b77a41ab01e9062
        Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
        Certificate Store Name       : My
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : (null)
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled

        Hostname:port                : sni.iis8.com:443
        Certificate Hash             : 0806be2a883f99cdeabbd6de3d9a241ef05445f7
        Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
        Certificate Store Name       : WebHosting
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : (null)
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled


    PS C:\Users\Administrator>

    --------------------------------------------------------------- 

    My part of applicationHost.config:

    --------------------------------------------------------------- 

    <bindings>
        <binding protocol="http" bindingInformation="*:80:" />
        <binding protocol="https" bindingInformation="10.52.183.108:443:sni.iis8.com" sslFlags="1" />
        <binding protocol="https" bindingInformation="10.52.183.108:443:non-sni.iis8.com" sslFlags="0" />
    </bindings>

    --------------------------------------------------------------- 

    Tuesday, October 2, 2012 6:26 AM
  • User690216013 posted
    <bindings>
        <binding protocol="http" bindingInformation="*:80:" />
        <binding protocol="https" bindingInformation="10.52.183.108:443:sni.iis8.com" sslFlags="1" />
        <binding protocol="https" bindingInformation="10.52.183.108:443:non-sni.iis8.com" sslFlags="0" />
    </bindings>
    Did you try to set the second one to *:443:sni.iis8.com?
    Tuesday, October 2, 2012 8:09 AM
  • User-2128161688 posted

     Yes, I tried set the second one to "*.443:sni.iis8.com" (replace "10.52.183.108:443:sni.iis8.com" to "*:443:sni.iis8.com") - I get non-SNI certificate (cert2) in this case.

     

    I tried set the third one to "*.443:non-sni.iis8.com" (replace "10.52.183.108:443:non-sni.iis8.com" to "*:443:non-sni.iis8.com") - I get SNI certificate (cert1) in this case (as expected). But this is not my use-case...

     

     My use-case:

    1. Each IP is associated with its own SSL certificate - traditional (IP:Port) SSL certificate binding for non-SNI compliant clients:

    ---------------------------------------------------------------------------
        IP:port                      : 10.52.183.107:443
        Certificate Hash             : 61b2501a27338521a13eb91f09d470ce70edb2ba
        Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
        Certificate Store Name       : My
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : (null)
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled


        IP:port                      : 10.52.183.108:443
        Certificate Hash             : e145c49fe92699fd4c7047b90b77a41ab01e9062
        Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
        Certificate Store Name       : My
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : (null)
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled

    --------------------------------------------------------------------------- 

    2. Each Web site has SNI (Hostname:Port) SSL certificate binding associated with its own SSL certificate for SNI compliant clients:

        Hostname:port                : site1.iis8.com:443
        Certificate Hash             : 0806be2a883f99cdeabbd6de3d9a241ef05445f7
        Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
        Certificate Store Name       : WebHosting
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : (null)
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled

     

        Hostname:port                : site2.iis8.com:443
        Certificate Hash             : 82c2900165f35dd1207c5dcaca19182f2242c237
        Application ID               : {4dc3e181-e14b-4a21-b022-59fc669b0914}
        Certificate Store Name       : WebHosting
        Verify Client Certificate Revocation : Enabled
        Verify Revocation Using Cached Client Certificate Only : Disabled
        Usage Check                  : Enabled
        Revocation Freshness Time    : 0
        URL Retrieval Timeout        : 0
        Ctl Identifier               : (null)
        Ctl Store Name               : (null)
        DS Mapper Usage              : Disabled
        Negotiate Client Certificate : Disabled 

     

    So, each Web site has bindings in applicationHost.config:

    <binding protocol="https" bindingInformation="10.52.183.107:443:siteN.iis8.com" sslFlags="1" />
    <binding protocol="https" bindingInformation="10.52.183.107:443:non-sni.siteN.iis8.com" sslFlags="0" />

    <binding protocol="https" bindingInformation="10.52.183.108:443:siteN.iis8.com" sslFlags="1" />
    <binding protocol="https" bindingInformation="10.52.183.108:443:non-sni.siteN.iis8.com" sslFlags="0" /> 

     

    When SNI compliant client (like IE9) browsing https://siteN.iis8.com it should get SNI SSL certificate (but really gets SSL certificate associated with current IP - like non-SNI compliant client).

    When non-SNI compliant client (like IE6) browsing https://siteN.iis8.com it should get SSL certificate associated with current IP.

    Tuesday, October 2, 2012 9:45 PM
  • User-2128161688 posted

    IMHO current implementation of SNI on Windows Server 2012 has a bug in HTTP.sys

     

    I expected the following behavior:

    1. The client sends a Client Hello to the server. The client sends a specific protocol version, the list of supported cipher suites along with the hostname as part of this Client Hello.

    2. The server uses hostname information available from the Client Hello and checks the corresponding combination of Hostname:Port.

    3. If the above step fails i.e., if the server couldn’t find a corresponding Hostname:Port, then it would use the IPAddress available to search for a legacy SSL binding for that IPAddress and PORT.

    Tuesday, October 2, 2012 10:35 PM
  • User690216013 posted
    I went through RFC6066 http://tools.ietf.org/html/rfc6066#page-6, but it does not go to details on how a web server should support both SNI and non-SNI clients. It either does not mention any required behavior in your scenario. Therefore, Microsoft has its freedom to implement whatever they think reasonable. It is so easy to say "I find a bug", but if it is by design, you will have to adapt to it. If you are a Microsoft Premier customer, you might discuss with your account manager.
    • Marked as answer by Anonymous Tuesday, September 28, 2021 12:00 AM
    Wednesday, October 3, 2012 9:11 AM
  • User-776338287 posted

    Lex is right. However this is what you can do.

    You can add a legacy SSL binding for Port and IP, no SNI or CCS.

    This way non-SNI compliant browsers will end up here. Or the best approach is to setup a separate site for legacy IP:Port binding and have a error page (default) displaying that the browser is not SNI compliant or the SNI Header information is not available. :)

    This should work.

    I was going to blog this. Sorry for the delay, I have been held up with a lot of work.

    Wednesday, October 17, 2012 6:38 AM
  • User-1165664085 posted

    Unfortunately - this IS a bug. I has NOTHING to do with "non-sni" and "sni" browsers. It IS a bug in how IIS prioritizes the available bindings!

    I have reconfirmed by reproducing both the positive and negative case. I'm always testing with the SAME (SNI capable) browsers - but also with SSL tools that JUST deal with the certificate validity.

    I have tested with ONE site (using multiple bindings) but also using TWO sites - it makes no difference.

    If IIS has THESE binding:

    <binding protocol="http" bindingInformation="ip.ad.dr.01:80:" />                    
    <binding protocol="https" bindingInformation="ip.ad.dr.01:443:www.alternatesite.com" sslFlags="1" />                    
    <binding protocol="https" bindingInformation="ip.ad.dr.01:443:www.primarysite.com" sslFlags="1" />

    THEN, requests for both sites will apply the appropriate SSL certificate.

    However, the problem is that "primarysite" has many subdomains ("alternatesite used to have subdomains, but no longer), thus BOTH are wildcard certificates (*.alternatesite.com, *.primarysite.com). So for the primarysite subdomains, the FOLLOWING binding is needed:

    <binding protocol="http" bindingInformation="ip.ad.dr.01:80:" />                    
    <binding protocol="https" bindingInformation="ip.ad.dr.01:443:www.alternatesite.com" sslFlags="1" />                    
    <binding protocol="https" bindingInformation="ip.ad.dr.01:443:" sslFlags="0" />

    In THIS case, requests for any subdomain *.primarysite.com will apply the correct certificate.
    But requests for www.alternatesite.com will NOT use SNI to locate the correct certificate (as it did in the first example), instead it now OVERRIDES SNI and apply the "default" primarysite.com certificate (wrong!) - no matter if one or two sites are used.

    So, the problem is that IIS receives an SNI request for "ip.ad.dr.01" with host www.alternatesite.com and very clearly FIRST uses the non-SNI binding. But if BOTH bindings are configured with explicit host names, that IIS will use the correct binding for both.

    That is not "by design" or is not matter of vague RFCs. If IIS is capable of matching the correct "alternatesite.com" from the same browser in ONE case, but ignores it in favor of the non-specific (non-SNI) "global" binding, then this is a bug in the order of processing/priority. The "default" binding doesn't act as a "fall back" for non-SNI clients, it currently acts as an OVERRIDE that discards any SNI information! 

     

    Friday, September 13, 2013 8:34 AM
  • User-39730678 posted

    I am having the same issue as Anamera. I have a Web Role in Azure that uses a wildcard ssl certificate in the default https binding ("virtual_machine_ip:443:"). I want to add the functionality to support custom domains by using SNI ("virtual_machine_ip:443:custom_domain"). The problem is that the default, non-SNI binding acts as a catch-all binding. IIS just does not serves the certificates for the SNI bindings.

    If I connect through RDP to the VM, open IIS, modify all ip address of all bindings of my site to "All unassigned" (by default thay are set to the IP of the VM), and then connect from my home computer's browser, the custom domains work (the correct certificates are served). But if I open my site through the domain of the default https binding, it returns "HTTP Error 503. The service is unavailable.". 

    In that situation, if I open IE in the VM and modify the hosts file to point all my domains to 127.0.0.1, I can get the correct certificates for all the domains. I do not know why from outside of the cloud I get Error 503 for the domain of the default binding "*:443:".

    In conclusion,

    1) If I have a non-sni binding with the IP specified ("ip:443:"), IIS will ignore the sni bindings.

    2)If I have a non-sni binding without the IP specified ("*:443:"), IIS will NOT ignore the sni bindings, but from outside the cloud the non-sni binding cannot be reached (IIS returns Error 503).

    Tuesday, September 17, 2013 2:56 AM