GitHub user jp557198 opened an issue:

    https://github.com/apache/trafficserver/issues/1344

    Origin SNI

    I currently have ATS configured to support a pristine host header.
    
       proxy.config.url_remap.pristine_host_hdr 1
    
    I also have ATS configured to verify the origin server certificate.
    
       proxy.config.ssl.client.verify.server 1
    
    My remap looks like this.
    
       map https://edge.tld/ https://origin.tld/
    
    
    Because pristine is enabled, when ATS sends a request back to the origin, 
it uses a SNI value of:
    
         edge.tld
    
    However, the origin returns a certificate that does not match the SNI. 
Specifically a CN of 'origin.tld'
    
    Because the requested SNI and the returned CN/SAN do not match, coupled 
with verify.server enabled, ATS throws a TLS alert and sends a 502 back to the 
client.
    
    After some testing it appears that when the origin request is built, the 
SNI is derived from the original client HOST header.  In situations where the 
origin certificate will not match the requested SNI value, the ATS 
administrator needs the ability to change the SNI accordingly.
    
    A current work around is to use a lua script to modify the original client 
HOST header as the origin request is being built.
    
    ++++++++
    function cache_lookup()
       ts.client_request.header['Host'] = 'origin.tld'
        return 0
    end
    function do_remap()
      ts.hook(TS_LUA_HOOK_CACHE_LOOKUP_COMPLETE, cache_lookup)
         return 0
    end
    ++++++++     
    
    Ideally there should be an over-ride option that sets the SNI which has 
priority over the client HOST header. One thought is to pass origin TLS options 
on the remap line.
    
    Something like..
    
    map https://edge.tld/ https://origin.tld/ 
tlsopt:sni=origin.tld;tlsopt2=foo;tlsopt3=bar
    
    (maybe as a start only support a SNI tlsopt. add support for more tlsopts 
as ATS evolves)


----

----


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to