หน้านี้มีคำแนะนำเกี่ยวกับการตั้งค่า 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>
<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>
<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>
อัปเดตลิงก์ด้วยสคริปต์แทนการเขียนด้วยตนเองเพื่อหลีกเลี่ยงข้อผิดพลาด หากเนื้อหาของเว็บไซต์อยู่ในฐานข้อมูล ให้ทดสอบสคริปต์ในสำเนาการพัฒนาของฐานข้อมูล หากเนื้อหาของเว็บไซต์มีแต่ไฟล์ง่ายๆ เท่านั้น ให้ทดสอบสคริปต์ในสำเนาการพัฒนาของไฟล์ พุชการเปลี่ยนแปลงไปยังเวอร์ชันที่ใช้งานจริงหลังจากที่ การเปลี่ยนแปลงผ่าน 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 มีความเกี่ยวข้องออกไป จนกว่าจะมีผู้ลงโฆษณาจำนวนมากพอที่ทำงานร่วมกันได้อย่างถูกต้อง