เปิดใช้ HTTPS ในเซิร์ฟเวอร์ของคุณ

Chris Palmer
Chris Palmer

หน้านี้มีคำแนะนำเกี่ยวกับการตั้งค่า HTTPS บนเซิร์ฟเวอร์ รวมถึงขั้นตอนต่อไปนี้

  • การสร้างคู่คีย์สาธารณะ/ส่วนตัว RSA 2048 บิต
  • กำลังสร้างคำขอลงชื่อใบรับรอง (CSR) ที่ฝังคีย์สาธารณะของคุณ
  • แชร์ CSR กับผู้ออกใบรับรอง (CA) เพื่อรับใบรับรองขั้นสุดท้ายหรือชุดใบรับรอง
  • ติดตั้งใบรับรองเวอร์ชันสุดท้ายในที่ที่ไม่สามารถเข้าถึงได้บนเว็บ เช่น /etc/ssl (Linux และ Unix) หรือที่ที่ IIS ต้องใช้ (Windows)

สร้างคีย์และคำขอลงชื่อใบรับรอง

ส่วนนี้ใช้โปรแกรมบรรทัดคำสั่ง openssl ซึ่งมาพร้อมกับระบบ Linux, BSD และ Mac OS X ส่วนใหญ่เพื่อสร้างคีย์ส่วนตัวและคีย์สาธารณะ ตลอดจน CSR

สร้างคู่คีย์สาธารณะ/ส่วนตัว

เริ่มต้นด้วยการสร้างคู่คีย์ RSA 2,048 บิต คีย์ที่สั้นกว่าอาจเสียหายได้โดยการคาดเดาการโจมตีแบบบรูตฟอร์ซ ส่วนคีย์ที่ยาวจะใช้ทรัพยากรที่ไม่จำเป็น

ใช้คำสั่งต่อไปนี้เพื่อสร้างคู่คีย์ RSA

openssl genrsa -out www.example.com.key 2048

ซึ่งจะแสดงเอาต์พุตต่อไปนี้

Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)

สร้างคำขอลงชื่อใบรับรอง

ในขั้นตอนนี้ คุณจะฝังคีย์สาธารณะและข้อมูลเกี่ยวกับองค์กรและเว็บไซต์ของคุณไว้ในคำขอลงชื่อใบรับรองหรือ CSR คำสั่ง openssl จะขอข้อมูลเมตาที่จำเป็นจากคุณ

กำลังเรียกใช้คำสั่งต่อไปนี้

openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr

เอาต์พุตต่อไปนี้

You are about to be asked to enter information that will be incorporated
into your certificate request

What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

หากต้องการตรวจสอบความถูกต้องของ CSR ให้เรียกใช้คำสั่งนี้:

openssl req -text -in www.example.com.csr -noout

คำตอบควรมีลักษณะดังนี้

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
                    f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
                    ...
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
         2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
         ...

ส่ง CSR ไปยังผู้ออกใบรับรอง

ผู้ออกใบรับรอง (CA) หลายแห่งกำหนดให้คุณต้องส่ง CSR ให้หน่วยงานดังกล่าวด้วยวิธีที่แตกต่างกัน ซึ่งอาจรวมถึงการใช้แบบฟอร์มบนเว็บไซต์หรือการส่ง CSR ทางอีเมล CA บางรายหรือตัวแทนจำหน่ายอาจทำกระบวนการบางส่วนหรือทั้งหมดโดยอัตโนมัติ ซึ่งรวมถึงการสร้างคู่คีย์และการสร้าง CSR ด้วยในบางกรณี

ส่ง CSR ไปยัง CA ของคุณและทำตามวิธีการเพื่อรับใบรับรองขั้นสุดท้ายหรือชุดใบรับรอง

CA แต่ละรายจะเรียกเก็บเงินจำนวนไม่เท่ากันสำหรับบริการรับรองคีย์สาธารณะ

นอกจากนี้ ยังมีตัวเลือกในการแมปคีย์กับชื่อ DNS มากกว่า 1 ชื่อ รวมถึงชื่อที่แตกต่างกันหลายๆ ชื่อ (เช่น ทุกชื่อใน example.com, www.example.com, example.net และ www.example.net) หรือชื่อ "ไวลด์การ์ด" เช่น *.example.com

คัดลอกใบรับรองไปยังเซิร์ฟเวอร์ส่วนหน้าทั้งหมดในตำแหน่งที่ไม่ใช่เว็บที่เข้าถึงได้ เช่น /etc/ssl (Linux และ Unix) หรือที่ที่ IIS (Windows) ต้องใช้

เปิดใช้ HTTPS บนเซิร์ฟเวอร์

การเปิดใช้ HTTPS บนเซิร์ฟเวอร์เป็นขั้นตอนสำคัญในการรักษาความปลอดภัยให้กับหน้าเว็บ

  • ใช้เครื่องมือกำหนดค่าเซิร์ฟเวอร์ของ Mozilla เพื่อตั้งค่าให้เซิร์ฟเวอร์รองรับ HTTPS
  • ทดสอบเว็บไซต์ของคุณเป็นประจำด้วยการทดสอบเซิร์ฟเวอร์ SSL ของ Qualys และตรวจสอบให้แน่ใจว่าคุณได้รับ A หรือ A+ เป็นอย่างน้อย

ในขั้นนี้คุณต้องตัดสินใจเรื่องการดำเนินการที่สำคัญ เลือกข้อใดข้อหนึ่งต่อไปนี้

  • กำหนดที่อยู่ IP ที่ไม่ซ้ำกันให้กับแต่ละชื่อโฮสต์ที่เว็บเซิร์ฟเวอร์ของคุณแสดงเนื้อหา
  • ใช้โฮสติ้งเสมือนที่อิงตามชื่อ

หากใช้ที่อยู่ IP ที่แตกต่างกันสำหรับแต่ละชื่อโฮสต์ ก็อาจรองรับทั้ง HTTP และ HTTPS สำหรับไคลเอ็นต์ทั้งหมด อย่างไรก็ตาม ผู้ให้บริการเว็บไซต์ส่วนใหญ่ใช้โฮสติ้งเสมือนตามชื่อเพื่อประหยัดที่อยู่ IP และเนื่องจากโดยทั่วไปสะดวกกว่า

หากยังไม่มีบริการ HTTPS ในเซิร์ฟเวอร์ ให้เปิดใช้ทันที (โดยไม่ต้องเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS ดูเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS สำหรับข้อมูลเพิ่มเติม) กำหนดค่าเว็บเซิร์ฟเวอร์เพื่อใช้ใบรับรองที่คุณซื้อและติดตั้ง คุณอาจพบว่าโปรแกรมสร้างการกําหนดค่าของ Mozilla อาจมีประโยชน์

หากคุณมีชื่อโฮสต์หรือโดเมนย่อยจำนวนมาก แต่ละรายการจะต้องใช้ใบรับรองที่ถูกต้อง

โปรดตรวจสอบการกำหนดค่า HTTPS ในการทดสอบเซิร์ฟเวอร์ SSL ของ Qualys เป็นประจำตลอดอายุการใช้งานของเว็บไซต์ เว็บไซต์ของคุณควรได้คะแนน A หรือ A+ พิจารณาทุกสิ่งที่ทำให้คะแนนต่ำกว่าเป็นข้อบกพร่องและขยันหมั่นเพียรอยู่เสมอ เพราะจะมีการพัฒนาการโจมตีอัลกอริทึมและโปรโตคอลใหม่ๆ อยู่เสมอ

ทำให้ URL ในเว็บไซต์สัมพัทธ์

เมื่อแสดงเว็บไซต์ทั้งใน HTTP และ HTTPS แล้ว สิ่งต่างๆ ต้องทำงานได้อย่างราบรื่นที่สุดเท่าที่จะเป็นไปได้ไม่ว่าจะใช้โปรโตคอลใดก็ตาม ปัจจัยสำคัญคือการใช้ URL แบบสัมพัทธ์สำหรับลิงก์ภายในเว็บไซต์

ตรวจสอบว่า URL ภายในและ URL ภายนอกไม่ได้ขึ้นอยู่กับโปรโตคอลที่เฉพาะเจาะจง ใช้เส้นทางสัมพัทธ์หรือปล่อยโปรโตคอลไว้เช่นใน //example.com/something.js

การแสดงหน้าเว็บที่มีทรัพยากร HTTP โดยใช้ HTTPS อาจก่อให้เกิดปัญหาได้ เมื่อเบราว์เซอร์พบหน้าเว็บที่มีความปลอดภัยอื่นๆ โดยใช้ทรัพยากรที่ไม่ปลอดภัย เบราว์เซอร์จะเตือนผู้ใช้ว่าหน้าเว็บนั้นไม่ปลอดภัยอย่างสมบูรณ์ และเบราว์เซอร์บางเบราว์เซอร์ปฏิเสธที่จะโหลดหรือดำเนินการกับทรัพยากร HTTP ซึ่งจะทำลายหน้าเว็บ แต่คุณรวมทรัพยากร HTTPS ไว้ในหน้า HTTP ได้อย่างปลอดภัย ดูคำแนะนำเพิ่มเติมเกี่ยวกับการแก้ไขปัญหาเหล่านี้ได้ที่การแก้ไขเนื้อหาผสม

การติดตามลิงก์แบบ HTTP ที่ไปยังหน้าอื่นๆ ในเว็บไซต์จะดาวน์เกรดประสบการณ์ของผู้ใช้จาก HTTPS เป็น HTTP ได้เช่นกัน ในการแก้ไขปัญหานี้ ให้สร้าง URL ภายในเว็บไซต์ให้เป็นแบบสัมพัทธ์มากที่สุด โดยทำให้ URL เป็นแบบขึ้นอยู่กับโปรโตคอล (ไม่มีโปรโตคอล เริ่มต้นด้วย //example.com) หรือแบบสัมพันธ์กับโฮสต์ (เริ่มต้นด้วยเฉพาะเส้นทาง เช่น /jquery.js)

ควรทำ
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
ใช้ URL ภายในเว็บไซต์แบบสัมพัทธ์
ควรทำ
<h1>Welcome To Example.com</h1>
<script src="//example.com/jquery.js"></script>
<link rel="stylesheet" href="//assets.example.com/style.css"/>
<img src="//img.example.com/logo.png"/>;
<p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
หรือใช้ URL ภายในเว็บไซต์ที่ขึ้นอยู่กับโปรโตคอล
ควรทำ
<h1>Welcome To Example.com</h1>
<script src="/jquery.js"></script>
<link rel="stylesheet" href="/assets/style.css"/>
<img src="/images/logo.png"/>;
<p>A <a href="/2014/12/24">new post on cats!</a></p>
<p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
ใช้ HTTPS URL สำหรับลิงก์ไปยังเว็บไซต์อื่นๆ หากทำได้

อัปเดตลิงก์ด้วยสคริปต์แทนการเขียนด้วยตนเองเพื่อหลีกเลี่ยงข้อผิดพลาด หากเนื้อหาของเว็บไซต์อยู่ในฐานข้อมูล ให้ทดสอบสคริปต์ในสำเนาการพัฒนาของฐานข้อมูล หากเนื้อหาของเว็บไซต์มีแต่ไฟล์ง่ายๆ เท่านั้น ให้ทดสอบสคริปต์ในสำเนาการพัฒนาของไฟล์ พุชการเปลี่ยนแปลงไปยังเวอร์ชันที่ใช้งานจริงหลังจากที่ การเปลี่ยนแปลงผ่าน QA ตามปกติเท่านั้น คุณจะใช้สคริปต์ของ Bram van Damme หรือสิ่งที่คล้ายกันเพื่อตรวจหาเนื้อหาผสมในเว็บไซต์ได้

เมื่อลิงก์ไปยังเว็บไซต์อื่นๆ (แทนที่จะรวมทรัพยากรจากเว็บไซต์) อย่าเปลี่ยนโปรโตคอล คุณไม่มีสิทธิ์ควบคุมการทำงานของเว็บไซต์เหล่านั้น

เพื่อให้การย้ายข้อมูลเป็นไปอย่างราบรื่นยิ่งขึ้นสำหรับเว็บไซต์ขนาดใหญ่ เราขอแนะนำให้ใช้ URL ที่ขึ้นอยู่กับโปรโตคอล หากคุณไม่แน่ใจว่าคุณยังทำให้ HTTPS ใช้งานได้โดยสมบูรณ์หรือไม่ การบังคับให้เว็บไซต์ใช้ HTTPS สำหรับทรัพยากรย่อยทั้งหมดอาจมีผลย้อนกลับได้ อาจมีบางช่วงเวลาที่ HTTPS เป็นสิ่งใหม่และแปลกๆ สำหรับคุณ เว็บไซต์ HTTP ก็ยังคงต้องใช้งานได้ดีเช่นเคย เมื่อเวลาผ่านไป คุณจะย้ายข้อมูลจนเสร็จสมบูรณ์และล็อกไว้ใน HTTPS (ดู 2 ส่วนถัดไป)

หากเว็บไซต์ต้องใช้สคริปต์ รูปภาพ หรือทรัพยากรอื่นๆ ที่ให้บริการจากบุคคลที่สาม เช่น CDN หรือ jquery.com คุณมี 2 ตัวเลือก ดังนี้

  • ใช้ URL ที่ขึ้นอยู่กับโปรโตคอลสำหรับทรัพยากรเหล่านี้ หากบุคคลที่สามไม่แสดง HTTPS ให้ขอให้บุคคลที่สามทำ ซึ่งส่วนมากแล้ว รวมถึง jquery.com ด้วย
  • ให้บริการทรัพยากรจากเซิร์ฟเวอร์ที่คุณควบคุม ซึ่งนำเสนอทั้ง HTTP และ HTTPS ถึงอย่างนั้น กรณีนี้ก็มักจะเป็นความคิดที่ดี เนื่องจากคุณจะควบคุมรูปลักษณ์ ประสิทธิภาพ และความปลอดภัยของเว็บไซต์ได้ดีขึ้น และไม่จำเป็นต้องไว้วางใจบุคคลที่สามให้ช่วยดูแลเว็บไซต์ให้ปลอดภัยอีก

เปลี่ยนเส้นทาง HTTP ไปยัง HTTPS

หากต้องการบอกให้เครื่องมือค้นหาใช้ HTTPS เพื่อเข้าถึงเว็บไซต์ ให้ใส่ลิงก์ Canonical ที่ส่วนหัวของแต่ละหน้าโดยใช้แท็ก <link rel="canonical" href="https://…"/>

เปิดใช้ Strict Transport Security และคุกกี้ที่ปลอดภัย

ในตอนนี้ คุณก็พร้อมที่จะ "ล็อก" การใช้ HTTPS แล้ว

  • ใช้ HTTP Strict Transport Security (HSTS) เพื่อหลีกเลี่ยงค่าใช้จ่ายในการเปลี่ยนเส้นทาง 301
  • ตั้งค่าสถานะความปลอดภัยในคุกกี้เสมอ

ก่อนอื่นให้ใช้ Strict Transport Security เพื่อแจ้งไคลเอ็นต์ว่าควรเชื่อมต่อกับเซิร์ฟเวอร์ของคุณโดยใช้ HTTPS เสมอ แม้ว่าจะติดตามการอ้างอิง http:// ก็ตาม ซึ่งจะเอาชนะการโจมตีอย่างเช่น SSL Stripping และลดค่าใช้จ่ายในการรับส่งข้อมูลไปกลับของ 301 redirect ที่เราเปิดใช้ในการเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS

หากต้องการเปิด HSTS ให้ตั้งค่าส่วนหัว Strict-Transport-Security หน้า HSTS ของ OWASP มีลิงก์ไปยังวิธีการสำหรับซอฟต์แวร์เซิร์ฟเวอร์ประเภทต่างๆ

เว็บเซิร์ฟเวอร์ส่วนใหญ่มีความสามารถที่คล้ายกันในการเพิ่มส่วนหัวที่กำหนดเอง

สิ่งที่สำคัญอีกอย่างคือการตรวจสอบว่าไคลเอ็นต์ไม่ส่งคุกกี้ (เช่น เพื่อการตรวจสอบสิทธิ์หรือค่ากำหนดของเว็บไซต์) ผ่าน HTTP เช่น ถ้าเห็นคุกกี้การตรวจสอบสิทธิ์ของผู้ใช้เป็นข้อความธรรมดา ระบบจะทำลายการรับประกันความปลอดภัยสำหรับทั้งเซสชันของผู้ใช้ แม้ว่าคุณจะทำทุกอย่างถูกต้องแล้วก็ตาม

หากต้องการหลีกเลี่ยงปัญหานี้ ให้เปลี่ยนเว็บแอปเพื่อตั้งค่าแฟล็กที่ปลอดภัยในคุกกี้ที่ตั้งค่าไว้เสมอ หน้า OWASP นี้จะอธิบายถึงวิธีตั้งค่า Flag ที่ปลอดภัยในเฟรมเวิร์กแอปหลายรายการ เฟรมเวิร์ก Appl ทั้งหมดมีวิธีการตั้งค่าสถานะ

เว็บเซิร์ฟเวอร์ส่วนใหญ่มีฟีเจอร์การเปลี่ยนเส้นทางแบบง่าย ใช้ 301 (Moved Permanently) เพื่อแจ้งให้เครื่องมือค้นหาและเบราว์เซอร์ทราบว่าเวอร์ชัน HTTPS เป็นหน้า Canonical และเปลี่ยนเส้นทางผู้ใช้จาก HTTP ไปยังเว็บไซต์เวอร์ชัน HTTPS

การจัดอันดับการค้นหา

Google ใช้ HTTPS เป็นตัวชี้วัดคุณภาพการค้นหาเชิงบวก นอกจากนี้ Google ยังเผยแพร่คู่มือเกี่ยวกับวิธีโอน ย้าย หรือย้ายข้อมูลเว็บไซต์ขณะที่รักษาอันดับการค้นหาของเว็บไซต์ไว้ นอกจากนี้ Bing ยังเผยแพร่หลักเกณฑ์สำหรับผู้ดูแลเว็บด้วย

การแสดง

เมื่อชั้นเนื้อหาและเลเยอร์ของแอปพลิเคชันได้รับการปรับแต่งอย่างดี (ดูคำแนะนำในหนังสือของ Steve Souders) ข้อกังวลเรื่องประสิทธิภาพ TLS ที่เหลือมักจะเล็กน้อยเมื่อเทียบกับค่าใช้จ่ายโดยรวมของแอปพลิเคชัน นอกจากนี้ คุณยังสามารถลดและหักค่าใช้จ่ายเหล่านั้นได้อีกด้วย ดูคำแนะนำเกี่ยวกับการเพิ่มประสิทธิภาพ TLS ได้ที่เครือข่ายเบราว์เซอร์ประสิทธิภาพสูงของ Ilya Grigorik รวมถึง OpenSSL Cookbook ของ Ivan Ristics และ สัญลักษณ์แสดงหัวข้อย่อยแบบ SSL และ TLS ของ Ivan Ristic

ในบางกรณี TLS ช่วยปรับปรุงประสิทธิภาพ ซึ่งส่วนใหญ่เป็นผลจากการทำให้ HTTP/2 เป็นไปได้ สำหรับข้อมูลเพิ่มเติม โปรดดูการบรรยายของ Chris Palmer เกี่ยวกับประสิทธิภาพของ HTTPS และ HTTP/2 ที่งาน Chrome Dev Summit 2014

ส่วนหัวอ้างอิง

เมื่อผู้ใช้ติดตามลิงก์จากเว็บไซต์ HTTPS ไปยังเว็บไซต์ HTTP อื่นๆ User Agent จะไม่ส่งส่วนหัวผู้อ้างอิง หากปัญหามีหลายวิธี มีวิธีแก้ไขดังนี้

  • เว็บไซต์อื่นๆ ควรย้ายข้อมูลไปยัง HTTPS หากเว็บไซต์ที่ได้รับการอ้างอิงทำในส่วนเปิดใช้ HTTPS บนเซิร์ฟเวอร์ของคู่มือนี้จนเสร็จสมบูรณ์ คุณจะเปลี่ยนลิงก์ในเว็บไซต์เป็นลิงก์ของเว็บไซต์เหล่านั้นจาก http:// เป็น https:// หรือใช้ลิงก์ที่ขึ้นอยู่กับโปรโตคอลได้
  • หากต้องการแก้ไขปัญหาอันหลากหลายเกี่ยวกับส่วนหัวผู้อ้างอิง ให้ใช้มาตรฐานนโยบายการอ้างอิงใหม่

รายได้จากโฆษณา

ผู้ให้บริการเว็บไซต์ที่สร้างรายได้จากเว็บไซต์ของตนโดยการแสดงโฆษณาต้องการแน่ใจว่าการย้ายข้อมูลไปใช้ HTTPS จะไม่ลดการแสดงโฆษณา แต่เนื่องด้วยข้อกังวลด้านความปลอดภัยของเนื้อหาที่หลากหลาย HTTP <iframe> จึงไม่สามารถใช้ในหน้า HTTPS ได้ ผู้ให้บริการเว็บไซต์จะย้ายข้อมูลไปยัง HTTPS โดยไม่เสียรายได้จากโฆษณาจนกว่าผู้ลงโฆษณาจะเผยแพร่ผ่าน HTTPS ไม่ได้ แต่จนกว่าผู้บริการเว็บไซต์จะเปลี่ยนไปใช้ HTTPS ผู้ลงโฆษณาจะมีแรงจูงใจในการเผยแพร่ HTTPS น้อย

คุณสามารถเริ่มกระบวนการหยุดทางตันนี้โดยใช้ผู้ลงโฆษณาที่ให้บริการโฆษณาผ่าน HTTPS และขอให้ผู้ลงโฆษณาที่ไม่ได้ใช้ HTTPS เสนอเป็นตัวเลือกให้ คุณอาจต้องเลื่อนการทำให้ URL ของ IntraSite มีความเกี่ยวข้องออกไป จนกว่าจะมีผู้ลงโฆษณาจำนวนมากพอที่ทำงานร่วมกันได้อย่างถูกต้อง