Jump to content
Welcome to our new Citrix community!

querying SNI header does not work as expected

Recommended Posts

A usual HTTPS request starts it's SSL session with a Client Helo. In this client Helo, the browser sends the so-called server_name extension, also known as SNI header. It only exists, if the user spezifies a FQDN, it is missing, if the user tries to access the IP address.


What I want to do is simple: I want to keep users from going to, instead, users should use https://norz.at. The reason is, I want to hide my customer's gateway from people scanning the internet for open ports. This can be done in several different ways. The easiest way is by blocking the HTTP request. Unfortunately, the HTTP request comes rather late. The vServer already sent its certificate back to the client, so a hacker gets valuable information (owner of the certificate and several more), so he would be able to guess the right name for the server. My customer is an organization with extreme needs for safety and plenty of enemies. So I thought of checking the SNI header in a SSL policy.


add ssl policy ssl_pol_sni-header -rule "CLIENT.SSL.CLIENT_HELLO.SNI.CONTAINS(\"norz.at\").NOT -action RESET


This policy does not work. It blocks all traffic, independent of the content of the SNI Header. My policy exactly follows https://docs.netscaler.com/de-de/citrix-adc/current-release/ssl/ssl-actions-and-policies/config-built-in-ssl-actions.html (add ssl policy snipolicy -rule client.ssl.client_hello.sni.contains("abc") -action pick_ca_group). I even copy/pasted this policy into my configuration, but it didn't work for me.

I tried with NetScaler 13.1 built 45.63 and 13.0 built 85.15.

Any idea?

Link to comment
Share on other sites

Good Morning Johannes,

i did a quick check on


My Scenario is maybe a little bit different to yours because i probably don´t have the kind of certificates you use, but i think it is okay for reproducing the issue.



- Virtual Server behind Content Switch with SNI enabled

- Certificates bound as SNI Certificates:

*.a.abc.de (with SAN *.a.abc.de and a.abc.de)


- Content Switching Policy for a.abc.de (covered by SAN of first certificate) and b.abc.de (covered by second certificate)


When i open a.abc.de or b.abc.de my website is shown. I created you mentioned SSL Policy and bound it to the Content Switch:



add ssl policy ssl_pol_sni-header -rule "CLIENT.SSL.CLIENT_HELLO.SNI.CONTAINS(\"a.abc.de\").NOT" -action RESET

bind ssl vserver cs_Test -policyName ssl_pol_sni-header -priority 100 -type CLIENTHELLO_REQ


When i try to access a.abc.de now, it works too (like expected).

When i try to access b.abc.de now, it doesn´t work.


I think your policy should work. Did you also bind it as type "CLIENTHELLO_REQ"?


But its also possible that my scenario is too different.


Best regards,


Link to comment
Share on other sites

  • 2 weeks later...
On 5/12/2023 at 12:38 PM, Jens Dellner 2 said:

add ssl policy ssl_pol_sni-header -rule "CLIENT.SSL.CLIENT_HELLO.SNI.CONTAINS(\"a.abc.de\").NOT" -action RESET

bind ssl vserver cs_Test -policyName ssl_pol_sni-header -priority 100 -type CLIENTHELLO_REQ

Thanks, Jens.


This is my setup, it's just a simple cs-vserver, all straight forward, no SNI:


add cs vserver cs_vs_ssl-test SSL 443 -cltTimeout 180 -httpProfileName http-quic -persistenceType NONE

set ssl vserver cs_vs_ssl-test -sslProfile ns_default_ssl_profile_secure_frontend

bind ssl vserver cs_vs_ssl-test_quic -cipherName APlus_Ciphers

bind ssl vserver cs_vs_ssl-test -eccCurveName P_256
bind ssl vserver cs_vs_ssl-test -eccCurveName P_384
bind ssl vserver cs_vs_ssl-test -eccCurveName P_224
bind ssl vserver cs_vs_ssl-test -eccCurveName P_521

bind ssl vserver cs_vs_ssl-test -certkeyName josel.net


add ssl policy ssl_pol_hostname -rule "CLIENT.SSL.CLIENT_HELLO.SNI.CONTAINS(\"josel.net\").NOT" -action RESET
bind ssl vserver cs_vs_ssl-test -policyName ssl_pol_hostname -priority 100 -type CLIENTHELLO_REQ


I could not connect using the IP address or the hostname (ssltest.josel.net). However, I can, as soon as I unbind the policy, or remove the .NOT from the expression, no matter if I use the FQDN, or the IP. That's odd, as my policy "does something", but it seems not to respect the SNI header. I'm using 13.0 91.12

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...