หน้านี้มีคำแนะนำในการตั้งค่า HTTPS ในเซิร์ฟเวอร์ รวมถึงขั้นตอนต่อไปนี้
- การสร้างคู่คีย์สาธารณะ/ส่วนตัว RSA 2048 บิต
- การสร้างคำขอลงนามใบรับรอง (CSR) ที่ฝังคีย์สาธารณะ
- การแชร์ CSR กับผู้ออกใบรับรอง (CA) เพื่อรับใบรับรองสุดท้ายหรือเชนใบรับรอง
- การติดตั้งใบรับรองสุดท้ายในที่ที่เข้าถึงเว็บไม่ได้ เช่น
/etc/ssl(Linux และ Unix) หรือที่ใดก็ตามที่ IIS กำหนด (Windows)
สร้างคีย์และคําขอลงนามใบรับรอง
ส่วนนี้ใช้โปรแกรมบรรทัดคำสั่ง openssl ซึ่งมาพร้อมกับระบบ Linux, BSD และ Mac OS X ส่วนใหญ่เพื่อสร้างคีย์ส่วนตัวและคีย์สาธารณะ รวมถึง CSR
สร้างคู่คีย์สาธารณะ/ส่วนตัว
เริ่มต้นด้วยการสร้างคู่คีย์ RSA 2,048 บิต คีย์ที่สั้นอาจถูกทำลายได้จากการโจมตีด้วยการเดาแบบ Brute Force และคีย์ที่ยาวจะใช้ทรัพยากรโดยไม่จำเป็น
ใช้คําสั่งต่อไปนี้เพื่อสร้างคู่คีย์ 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 บางรายหรือตัวแทนจำหน่ายของ CA อาจทำให้กระบวนการบางส่วนหรือทั้งหมดเป็นแบบอัตโนมัติ ซึ่งรวมถึงการสร้างคู่คีย์และ CSR ในบางกรณี
ส่ง CSR ไปยัง CA แล้วทําตามวิธีการของ 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 Server Test ของ 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
- ตั้งค่า Flag "ปลอดภัย" ในคุกกี้เสมอ
ก่อนอื่น ให้ใช้ Strict Transport Security เพื่อแจ้งให้ไคลเอ็นต์ทราบว่าควรเชื่อมต่อกับเซิร์ฟเวอร์ของคุณโดยใช้ HTTPS เสมอ แม้กระทั่งเมื่อทำตามการอ้างอิง http:// วิธีนี้จะช่วยป้องกันการโจมตีอย่างเช่นการลบข้อมูล SSL และหลีกเลี่ยงค่าใช้จ่ายในการส่งข้อมูลไปกลับของ 301 redirect ที่เราเปิดใช้ในการเปลี่ยนเส้นทาง HTTP เป็น HTTPS
หากต้องการเปิด HSTS ให้ตั้งค่าส่วนหัว Strict-Transport-Security หน้า HSTS ของ OWASP มีลิงก์ไปยังวิธีการสำหรับซอฟต์แวร์เซิร์ฟเวอร์ประเภทต่างๆ
เว็บเซิร์ฟเวอร์ส่วนใหญ่มีความสามารถในการเพิ่มส่วนหัวที่กำหนดเองที่คล้ายกัน
นอกจากนี้ คุณควรตรวจสอบว่าไคลเอ็นต์ไม่ได้ส่งคุกกี้ (เช่น สำหรับการรับรองความถูกต้องหรือค่ากําหนดของเว็บไซต์) ผ่าน HTTP ตัวอย่างเช่น หากมีการเปิดเผยคุกกี้การตรวจสอบสิทธิ์ของผู้ใช้ในรูปแบบข้อความธรรมดา รับประกันความปลอดภัยสำหรับเซสชันทั้งหมดของผู้ใช้จะสูญเปล่า แม้ว่าคุณจะทำทุกอย่างถูกต้องแล้วก็ตาม
หากต้องการหลีกเลี่ยงปัญหานี้ ให้เปลี่ยนเว็บแอปให้ตั้งค่า Flag "ปลอดภัย" ในคุกกี้ที่ตั้งค่าไว้เสมอ หน้า OWASP นี้อธิบายวิธีตั้งค่า Flag ที่ปลอดภัยในเฟรมเวิร์กแอปหลายรายการ เฟรมเวิร์กแอปทุกเฟรมเวิร์กมีวิธีตั้งค่า Flag
เว็บเซิร์ฟเวอร์ส่วนใหญ่มีฟีเจอร์การเปลี่ยนเส้นทางง่ายๆ ใช้ 301 (Moved Permanently)
เพื่อบ่งบอกให้เครื่องมือค้นหาและเบราว์เซอร์ทราบว่าเวอร์ชัน HTTPS เป็น Canonical และเปลี่ยนเส้นทางผู้ใช้จาก HTTP ไปยังเว็บไซต์เวอร์ชัน HTTPS
การจัดอันดับการค้นหา
Google ใช้ HTTPS เป็นตัวบ่งชี้คุณภาพการค้นหาเชิงบวก นอกจากนี้ Google ยังเผยแพร่คู่มือวิธีโอน ย้าย หรือย้ายข้อมูลเว็บไซต์โดยรักษาอันดับการค้นหาของเว็บไซต์ไว้ นอกจากนี้ Bing ยังเผยแพร่หลักเกณฑ์สําหรับผู้ดูแลเว็บด้วย
ประสิทธิภาพ
เมื่อปรับแต่งเลเยอร์เนื้อหาและแอปพลิเคชันอย่างดีแล้ว (ดูคำแนะนำในหนังสือของ Steve Souders) ข้อกังวลด้านประสิทธิภาพของ TLS ที่เหลือโดยทั่วไปจะน้อยเมื่อเทียบกับต้นทุนโดยรวมของแอปพลิเคชัน นอกจากนี้ คุณยังลดและแบ่งชำระค่าใช้จ่ายเหล่านั้นได้ด้วย ดูคําแนะนําเกี่ยวกับการเพิ่มประสิทธิภาพ TLS ได้ที่เครือข่ายเบราว์เซอร์ที่มีประสิทธิภาพสูงโดย Ilya Grigorik รวมถึงตำรา OpenSSL และ SSL และ TLS ที่ปลอดภัยของ Ivan Ristic
ในบางกรณี TLS อาจช่วยปรับปรุงประสิทธิภาพได้ โดยส่วนใหญ่เป็นผลมาจากการใช้ HTTP/2 ได้ ดูข้อมูลเพิ่มเติมได้ที่การบรรยายของ Chris Palmer เกี่ยวกับประสิทธิภาพของ HTTPS และ HTTP/2 ที่ Chrome Dev Summit 2014
ส่วนหัว Referer
เมื่อผู้ใช้ไปยังเว็บไซต์ HTTP อื่นๆ จากเว็บไซต์ HTTPS ของคุณ User Agent จะไม่ส่งส่วนหัว Referer หากพบปัญหานี้ คุณสามารถแก้ปัญหาได้หลายวิธี ดังนี้
- เว็บไซต์อื่นๆ ควรเปลี่ยนไปใช้ HTTPS หากเว็บไซต์อ้างอิงทำตามส่วนเปิดใช้ HTTPS ในเซิร์ฟเวอร์ของคู่มือนี้จนเสร็จสมบูรณ์ คุณจะเปลี่ยนลิงก์ในเว็บไซต์ของคุณเป็นลิงก์ของเว็บไซต์อ้างอิงจาก
http://เป็นhttps://หรือใช้ลิงก์ที่ขึ้นอยู่กับโปรโตคอลได้ - หากต้องการแก้ปัญหาต่างๆ เกี่ยวกับส่วนหัว Referer ให้ใช้มาตรฐานนโยบาย URL ที่มาใหม่
รายได้จากโฆษณา
ผู้ดำเนินการเว็บไซต์ที่สร้างรายได้จากเว็บไซต์ด้วยการแสดงโฆษณาต้องการตรวจสอบว่าการเปลี่ยนไปใช้ HTTPS จะไม่ลดการแสดงโฆษณา อย่างไรก็ตาม <iframe> ของ HTTP จะใช้ไม่ได้ในหน้า HTTPS เนื่องจากข้อกังวลด้านความปลอดภัยของเนื้อหาแบบผสม
ผู้ดำเนินการเว็บไซต์จะย้ายข้อมูลไปยัง HTTPS ไม่ได้หากผู้ลงโฆษณาไม่เผยแพร่ผ่าน HTTPS แต่ผู้ลงโฆษณาก็ไม่มีแรงจูงใจที่จะเผยแพร่ผ่าน HTTPS หากผู้ดำเนินการเว็บไซต์ไม่ย้ายข้อมูล
คุณเริ่มกระบวนการแก้ปัญหานี้ได้โดยการใช้ผู้ลงโฆษณาที่ให้บริการโฆษณาผ่าน HTTPS และขอให้ผู้ลงโฆษณาที่ไม่ได้แสดงโฆษณาผ่าน HTTPS เลยอย่างน้อยให้แสดงโฆษณาผ่าน HTTPS เป็นตัวเลือก คุณอาจต้องเลื่อนทำให้ URL ภายในเว็บไซต์เป็น URL แบบสัมพัทธ์จนกว่าผู้ลงโฆษณาจำนวนมากพอจะทำงานร่วมกันได้อย่างถูกต้อง