SNI คืออะไร เปิดหลาย SSL บน IP เดียว

ในยุคแรกของ HTTPS เซิร์ฟเวอร์หนึ่งเครื่องสามารถมี SSL Certificate ได้เพียงหนึ่งใบต่อหนึ่ง IP Address ซึ่งหมายความว่าถ้าต้องการโฮสต์หลาย Domain บนเซิร์ฟเวอร์เดียวก็ต้องมี IP หลายอัน แต่ปัจจุบัน SNI ได้แก้ปัญหานี้ไปแล้ว บทความนี้อธิบายว่า SNI คืออะไรและทำงานอย่างไร

SNI คืออะไร

SNI ย่อมาจาก Server Name Indication เป็น Extension ของโปรโตคอล TLS ที่ช่วยให้ไคลเอนต์ (เบราว์เซอร์) บอกชื่อโฮสต์ที่ต้องการเชื่อมต่อในขั้นตอน TLS Handshake ก่อนที่การเชื่อมต่อ SSL จะถูกสร้างขึ้น

พูดง่ายๆ คือ SNI ทำให้เซิร์ฟเวอร์รู้ว่าเบราว์เซอร์กำลังจะเชื่อมต่อกับ Domain ไหน จึงส่ง Certificate ที่ถูกต้องกลับไปได้ แม้จะมีหลาย Domain อยู่บน IP เดียวกัน

ก่อน SNI มีปัญหาอะไร

ปัญหาคือ SSL/TLS Handshake เกิดขึ้น ก่อน ที่เบราว์เซอร์จะส่ง HTTP Request ที่มีชื่อ Domain ในส่วน Host Header ดังนั้นเซิร์ฟเวอร์ไม่รู้ว่าต้องส่ง Certificate ของ Domain ไหนกลับไป

ผลที่ตามมาคือก่อน SNI เว็บโฮสติ้งต้อง:

• กำหนด 1 IP ต่อ 1 Domain ที่มี SSL
• ทำให้ Shared Hosting มี SSL ได้ยาก เพราะ IP มีจำกัด
• ผู้ให้บริการต้องคิดค่าใช้จ่าย IP เพิ่มสำหรับทุก SSL Domain

SNI แก้ปัญหาอย่างไร

SNI เพิ่ม field "server_name" เข้าไปใน TLS Client Hello Message ซึ่งเป็นข้อความแรกที่ไคลเอนต์ส่งในขั้นตอน TLS Handshake ข้อมูลนี้บอกเซิร์ฟเวอร์ว่าต้องการเชื่อมต่อกับ Domain ไหน

กระบวนการทำงานของ SNI:

1. เบราว์เซอร์เริ่มต้น TLS Handshake และส่ง Domain name ใน Client Hello
2. เซิร์ฟเวอร์อ่าน SNI field และเลือก Certificate ที่ถูกต้อง
3. เซิร์ฟเวอร์ส่ง Certificate กลับไปให้เบราว์เซอร์
4. เบราว์เซอร์ตรวจสอบ Certificate และสร้างการเชื่อมต่อ HTTPS

Browser รองรับ SNI หรือยัง

ปัจจุบันเบราว์เซอร์สมัยใหม่รองรับ SNI ทั้งหมด รวมถึง:

• Chrome — รองรับตั้งแต่ Chrome 6+ (2010)
• Firefox — รองรับตั้งแต่ Firefox 2+ (2006)
• Safari — รองรับตั้งแต่ Safari 3+ (2007)
• Edge / IE — IE8+ บน Windows Vista ขึ้นไป, Edge ทุกเวอร์ชัน
• Mobile — iOS Safari, Android Chrome รองรับทั้งหมด

เบราว์เซอร์เก่าที่ไม่รองรับ SNI เช่น IE6 บน Windows XP นั้นมีส่วนแบ่งน้อยมากจนไม่มีนัยสำคัญ

การตั้งค่า SNI บนเซิร์ฟเวอร์

Apache

Apache รองรับ SNI ตั้งแต่ Apache 2.2.12 โดยใช้ NameVirtualHost บน port 443:

<VirtualHost *:443>
    ServerName domain1.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/domain1.crt
    SSLCertificateKeyFile /etc/ssl/domain1.key
</VirtualHost>

<VirtualHost *:443>
    ServerName domain2.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/domain2.crt
    SSLCertificateKeyFile /etc/ssl/domain2.key
</VirtualHost>

Nginx

Nginx รองรับ SNI ตั้งแต่ Nginx 0.5.23 โดยใช้ server blocks แยกกัน:

server {
    listen 443 ssl;
    server_name domain1.com;
    ssl_certificate /etc/ssl/domain1.crt;
    ssl_certificate_key /etc/ssl/domain1.key;
}

server {
    listen 443 ssl;
    server_name domain2.com;
    ssl_certificate /etc/ssl/domain2.crt;
    ssl_certificate_key /etc/ssl/domain2.key;
}

SNI กับ Shared Hosting ของ AsiaGB

AsiaGB Hosting ใช้ DirectAdmin ที่รองรับ SNI เต็มรูปแบบ ลูกค้าสามารถมี SSL Certificate หลายใบสำหรับ Domain และ Subdomain ต่างๆ บน IP ที่แชร์กันได้ ไม่ว่าจะเป็น Let's Encrypt ฟรีหรือ Paid SSL Certificate ก็รองรับทั้งหมด

ข้อจำกัดของ SNI ที่ต้องรู้

แม้ SNI จะแก้ปัญหาหลักได้แล้ว แต่ยังมีกรณีพิเศษบางอย่างที่ควรเข้าใจก่อนวางแผน Infrastructure

1. Client เก่าที่ไม่รองรับ SNI

เช่น Java Virtual Machine รุ่นเก่า (ก่อน Java 7), curl บน OpenSSL รุ่นเก่า หรือ Library SSL บน Embedded Device บางชนิด หากต้องรองรับ Client เหล่านี้อย่างเคร่งครัด อาจต้องใช้ IP เฉพาะสำหรับ Domain นั้น

2. SNI ไม่ใช่ Wildcard

SNI ช่วยให้เซิร์ฟเวอร์ระบุ Certificate ที่ถูกต้องสำหรับแต่ละ Domain แต่ไม่ได้หมายความว่า Certificate ใบเดียวครอบ Domain ทั้งหมด ยังต้องมี Certificate แยกต่างหากสำหรับแต่ละ Domain หรือใช้ Wildcard Certificate ที่ครอบคลุม Subdomain ทั้งหมดของ Domain เดียว

3. SNI กับ ESNI / ECH (ความเป็นส่วนตัวขั้นสูง)

ปัญหาหนึ่งของ SNI มาตรฐานคือชื่อ Domain ส่งแบบ Plaintext ใน TLS Handshake ทำให้ผู้ดักฟัง Network อ่านได้ว่าผู้ใช้กำลังเข้าเว็บใด ทางแก้คือ Encrypted Client Hello (ECH) ซึ่งเบราว์เซอร์สมัยใหม่กำลังรองรับมากขึ้น แต่ไม่ได้เปลี่ยนวิธีทำงานของ SNI ที่เซิร์ฟเวอร์

SNI กับ Wildcard SSL: เลือกอะไรดี

เมื่อมีหลาย Subdomain บน Domain เดียวกัน มีสองทางเลือกหลัก ได้แก่ ใช้ Certificate แยกกันทุก Subdomain โดยพึ่ง SNI บนเซิร์ฟเวอร์ หรือใช้ Wildcard Certificate ใบเดียวที่ครอบทุก Subdomain

ราคา Wildcard SSL Certificate ของ AsiaGB เริ่มต้นที่ 5,000 บาทต่อปี (RapidSSL Wildcard) ซึ่งคุ้มค่ามากสำหรับเว็บที่มีหลาย Subdomain

SNI กับ Let's Encrypt: ออก Certificate หลายใบบน IP เดียว

Let's Encrypt เป็น Certificate Authority ที่ออก SSL Certificate ฟรีและมีระยะเวลา 90 วัน ซึ่งทำงานร่วมกับ SNI ได้ดีมาก ทำให้ผู้ให้บริการ Shared Hosting สามารถออก Certificate ให้ลูกค้าแต่ละรายโดยอัตโนมัติบน IP เดียวกันได้

กระบวนการออก Let's Encrypt Certificate ด้วย SNI

Certbot (เครื่องมือออก Let's Encrypt) ใช้ ACME Protocol ซึ่งมี Challenge หลายแบบ สำหรับ Shared Hosting ที่ใช้ SNI มักใช้ HTTP-01 Challenge:

1. Certbot ขอ Certificate สำหรับ yourdomain.com จาก Let's Encrypt
2. Let's Encrypt ส่ง Token กลับมาให้วางที่ /.well-known/acme-challenge/ ของ Domain นั้น
3. Let's Encrypt เรียก URL ดังกล่าวผ่าน HTTP เพื่อยืนยัน Ownership
4. เมื่อผ่าน Challenge แล้ว Certificate จะถูกออกและติดตั้งโดยอัตโนมัติ
5. Certbot ตั้ง Cron Job ต่ออายุ Certificate ทุก 60 วัน โดยไม่ต้องดำเนินการเอง

DirectAdmin ของ AsiaGB รองรับ Let's Encrypt Certificate แบบอัตโนมัติทุกแผน ลูกค้าเพียงแค่เปิด SSL ใน Control Panel และระบบจะออก Certificate ให้ทุก Domain และ Subdomain ที่เพิ่มเข้ามา

ข้อดีของ Let's Encrypt กับ SNI บน Shared Hosting

• ฟรีสมบูรณ์ — ไม่มีค่าใช้จ่ายสำหรับ DV Certificate (Domain Validation)
• ต่ออายุอัตโนมัติ — ไม่ต้องจดจำวันหมดอายุ ระบบดูแลให้
• รองรับ Wildcard — Let's Encrypt ออก Wildcard Certificate ได้ (ใช้ DNS-01 Challenge)
• ติดตั้งง่ายบน DirectAdmin — กดเปิดผ่าน UI ไม่ต้องรู้คำสั่ง Command Line

ทดสอบว่า Server รองรับ SNI จริงหรือไม่

ก่อนย้าย Domain หลายอันมาบน IP เดียว ควรทดสอบให้แน่ใจว่า Server รองรับ SNI อย่างถูกต้อง และ Certificate ที่ส่งออกมาตรงกับ Domain ที่ร้องขอ

วิธีที่ 1: ใช้ OpenSSL

# ทดสอบ SNI ด้วย OpenSSL — ระบุ servername ใน Client Hello
openssl s_client -connect YOUR_SERVER_IP:443 \
  -servername domain1.com \
  -verify_return_error

# ดูที่ output บรรทัด "subject" — ต้องตรงกับ domain1.com
# ทดสอบซ้ำกับ domain2.com เพื่อยืนยันว่าได้ Certificate คนละใบ

วิธีที่ 2: ใช้ curl

# curl รองรับ SNI ตั้งแต่เวอร์ชัน 7.18.1 เป็นต้นมา
curl -vI --resolve domain1.com:443:YOUR_IP https://domain1.com 2>&1 | grep -E "subject|issuer|SSL"
curl -vI --resolve domain2.com:443:YOUR_IP https://domain2.com 2>&1 | grep -E "subject|issuer|SSL"

วิธีที่ 3: ตรวจผ่าน Online Tool

เว็บ SSL Labs (ssllabs.com/ssltest/) แสดงข้อมูล Certificate ที่ส่งให้ Browser อย่างละเอียด รวมถึงว่า Server รองรับ SNI หรือไม่ ผ่านการทดสอบจากหลาย IP

SNI กับ Load Balancer และ Reverse Proxy

ในระบบที่ซับซ้อนขึ้น เช่น มี Load Balancer หน้า Web Server หรือใช้ Nginx เป็น Reverse Proxy SNI ยังคงทำงานได้ปกติ แต่ต้องตั้งค่าในชั้นที่รับ Connection SSL ก่อน ซึ่งเป็นสิ่งสำคัญที่ต้องเข้าใจเมื่อออกแบบ Infrastructure สำหรับเว็บที่มีหลาย Microservice

Nginx Reverse Proxy + SNI

# Nginx รับ HTTPS connection พร้อม SNI แล้วส่งต่อไป Backend แบบ HTTP
server {
    listen 443 ssl;
    server_name shop.example.com;
    ssl_certificate     /etc/ssl/shop.crt;
    ssl_certificate_key /etc/ssl/shop.key;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

server {
    listen 443 ssl;
    server_name api.example.com;
    ssl_certificate     /etc/ssl/api.crt;
    ssl_certificate_key /etc/ssl/api.key;

    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_set_header Host $host;
    }
}

Nginx อ่าน SNI field ใน Client Hello เลือก Certificate ที่ถูกต้อง จากนั้นส่ง Request ไปยัง Backend Server ที่เหมาะสม ทำให้ IP เดียวรองรับได้ทั้ง API, Frontend และ Service ย่อยต่างๆ บนพอร์ต 443 รูปแบบนี้เป็น Architecture มาตรฐานสำหรับเว็บสมัยใหม่ที่ใช้ Microservice ซึ่งช่วยประหยัด IP Address ได้อย่างมาก

HAProxy กับ SNI Passthrough

สำหรับระบบที่ต้องการ SNI Passthrough (ให้ Backend Server เป็นผู้จัดการ TLS เอง แทนที่จะให้ Load Balancer Terminate SSL) HAProxy รองรับ Mode นี้ด้วย:

# HAProxy config สำหรับ SNI-based TCP passthrough
frontend https-in
    bind *:443
    mode tcp
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }

    # Route ตามชื่อ Domain ใน SNI
    use_backend be_api    if { req.ssl_sni -m end api.example.com }
    use_backend be_shop   if { req.ssl_sni -m end shop.example.com }
    default_backend       be_default

backend be_api
    mode tcp
    server api1 10.0.0.1:443 check
backend be_shop
    mode tcp
    server shop1 10.0.0.2:443 check

วิธีนี้มีประโยชน์เมื่อต้องการ End-to-End Encryption และไม่ต้องการให้ Load Balancer มี Private Key ของ Certificate อยู่ด้วย เหมาะกับระบบ Financial หรือระบบที่มีความต้องการ Security สูง