What effect does the configuration SSLStrictSNIVHostCheck on have on an Apache HTTPD virtual host?

Question

Options

• AThe clients connecting to the virtual host must provide a client certificate that was issued by the
• BThe virtual host is served only to clients that support SNI.
• CAll of the names of the virtual host must be within the same DNS zone.
• DThe virtual host is used as a fallback default for all clients that do not support SNI.
• EDespite its configuration, the virtual host is served only on the common name and Subject

• B
  95% (19)
• E
  5% (1)

Explanation

SSLStrictSNIVHostCheck on enforces that the virtual host is only accessible to TLS clients that support Server Name Indication (SNI) - clients that cannot send an SNI extension in their TLS handshake will be refused, receiving a "no shared cipher" error. This is option B because the directive is specifically about SNI capability gating, not certificate requirements, DNS zones, or fallback behavior.

Why the distractors are wrong:

• A confuses SNI (server-side name routing) with mutual TLS client certificate authentication - completely different mechanisms.
• C is fabricated; the directive has no concept of DNS zones.
• D is the opposite - SSLStrictSNIVHostCheck off is what allows a vhost to serve as a fallback for non-SNI clients; on rejects them.
• E mixes up SNI with Subject Alternative Names (SANs) in certificates - different layer entirely.

Memory tip: Think of "Strict SNI Check" as a bouncer: on means "SNI required to enter." If your client can't present SNI at the door, you're turned away - no fallback, no certificate tricks, just rejected.

No community discussion yet for this question.