หน้านี้มีคำแนะนำเกี่ยวกับการตั้งค่า 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 บางรายหรือตัวแทนจำหน่ายของลูกค้าอาจดำเนินการโดยอัตโนมัติบางส่วนหรือทั้งหมด ของกระบวนการ รวมถึงในบางกรณี คู่คีย์และการสร้าง 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 การสนับสนุน
- ทดสอบเว็บไซต์ของคุณเป็นประจำด้วย Qualys' ทดสอบและตรวจสอบว่าเซิร์ฟเวอร์ SSL อย่างน้อยคุณก็จะได้ A หรือ A+
ณ จุดนี้ คุณต้องทำการตัดสินใจที่สำคัญในการดำเนินการ เลือกตัวเลือกใดตัวเลือกหนึ่ง ดังต่อไปนี้:
- กำหนดที่อยู่ IP ที่ไม่ซ้ำกันสำหรับแต่ละชื่อโฮสต์ที่เว็บเซิร์ฟเวอร์ของคุณแสดงเนื้อหา จาก
- ใช้โฮสติ้งเสมือนตามชื่อ
หากคุณใช้ที่อยู่ IP ที่ไม่ซ้ำกันสำหรับชื่อโฮสต์แต่ละชื่อ คุณสามารถสนับสนุน ทั้ง HTTP และ HTTPS สำหรับไคลเอ็นต์ทั้งหมด อย่างไรก็ตาม ผู้ดำเนินการเว็บไซต์ส่วนใหญ่จะใช้ชื่อ โฮสติ้งเสมือนเพื่อประหยัดที่อยู่ IP และเนื่องจากเป็นวิธีที่สะดวกมากกว่า ทั่วไป
หากคุณยังไม่มีบริการ HTTPS บนเซิร์ฟเวอร์ ให้เปิดใช้งานทันที (โดยไม่ต้องเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS ดูเปลี่ยนเส้นทาง HTTP ไปยัง HTTPS ) กำหนดค่าเว็บเซิร์ฟเวอร์เพื่อใช้ใบรับรอง ซื้อและติดตั้งแล้ว คุณอาจเห็นการกำหนดค่าของ Mozilla โปรแกรมสร้าง มีประโยชน์
ถ้าคุณมีชื่อโฮสต์หรือโดเมนย่อยหลายรายการ แต่ละชื่อโฮสต์จะต้องใช้ ใบรับรอง
ตรวจสอบ HTTPS ในขณะนี้และเป็นประจำตลอดอายุการใช้งานเว็บไซต์ การกำหนดค่าด้วย Qualys" การทดสอบเซิร์ฟเวอร์ SSL เว็บไซต์ของคุณควรได้คะแนน A หรือ A+ ปฏิบัติต่อทุกสิ่งที่ทำให้คะแนนต่ำลง เช่น ข้อบกพร่องและมีความขยัน เพราะการโจมตีใหม่ๆ ต่ออัลกอริทึมและโปรโตคอล มักได้รับการพัฒนาอยู่เสมอ
ทำให้ URL ภายในเว็บไซต์เป็นแบบสัมพัทธ์
เมื่อคุณแสดงเว็บไซต์ทั้งบน HTTP และ HTTPS แล้ว สิ่งต่างๆ ต้อง ได้อย่างราบรื่นที่สุดไม่ว่าจะเป็นแบบใดก็ตาม ปัจจัยสำคัญอย่างหนึ่งคือ Relative URL สำหรับลิงก์ภายในเว็บไซต์
ตรวจสอบว่า URL ภายในเว็บไซต์และ URL ภายนอกไม่ได้ขึ้นอยู่กับโปรโตคอลเฉพาะ
ใช้เส้นทางแบบสัมพัทธ์หรือละเว้นโปรโตคอลใน //example.com/something.js
การแสดงหน้าที่มีทรัพยากร HTTP โดยใช้ HTTPS อาจก่อให้เกิดปัญหา เมื่อเบราว์เซอร์เจอ หน้าเว็บที่มีการรักษาความปลอดภัยซึ่งใช้ทรัพยากรที่ไม่ปลอดภัย จะมีการเตือนผู้ใช้ว่าหน้าเว็บนั้น ไม่ปลอดภัย อย่างสมบูรณ์ และบางเบราว์เซอร์ปฏิเสธที่จะโหลดหรือเรียกใช้ HTTP ที่จะทำให้หน้าเว็บไม่ทำงาน อย่างไรก็ตาม คุณสามารถรวม HTTPS ได้อย่างปลอดภัย ในหน้า HTTP ดูคำแนะนำเพิ่มเติมในการแก้ไขปัญหาเหล่านี้ได้ที่ การแก้ไขเนื้อหาผสม
การลิงก์แบบ HTTP ที่ไปยังหน้าอื่นๆ ในเว็บไซต์จะเป็นการดาวน์เกรด
จาก HTTPS ไปเป็น HTTP ในการแก้ไขปัญหานี้ ให้สร้าง 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
และหลีกเลี่ยงค่าใช้จ่ายไป-กลับของ 301 redirect ที่เราเปิดใช้
เปลี่ยนเส้นทาง HTTP ไปยัง HTTPS
หากต้องการเปิด HSTS ให้ตั้งค่าส่วนหัว Strict-Transport-Security หน้า HSTS ของ OWASP
มีลิงก์ไปยังวิธีการ
สำหรับซอฟต์แวร์เซิร์ฟเวอร์ชนิดต่างๆ
เว็บเซิร์ฟเวอร์ส่วนใหญ่เพิ่มส่วนหัวที่กำหนดเองได้ในลักษณะเดียวกัน
สิ่งสำคัญอีกอย่างคือ การตรวจสอบว่าลูกค้าไม่ได้ส่งคุกกี้ (เช่น การตรวจสอบสิทธิ์หรือค่ากำหนดเว็บไซต์) ผ่าน HTTP ตัวอย่างเช่น หาก คุกกี้การตรวจสอบสิทธิ์ถูกเปิดเผยเป็นข้อความธรรมดา การรับประกันความปลอดภัยของคุณ ตลอดเซสชันทั้งหมดจะถูกทำลาย แม้ว่าคุณจะทำอย่างอื่นแล้วก็ตาม ใช่แล้ว
เพื่อหลีกเลี่ยงปัญหานี้ ให้เปลี่ยนเว็บแอปให้ตั้งค่าแฟล็กความปลอดภัยในคุกกี้เสมอ เซ็ต หน้า OWASP นี้อธิบายวิธีการตั้งค่าสถานะความปลอดภัย ในหลายเฟรมเวิร์กของแอป เฟรมเวิร์ก Appl ทั้งหมดมีวิธีการตั้งค่า Flag
เว็บเซิร์ฟเวอร์ส่วนใหญ่มีฟีเจอร์การเปลี่ยนเส้นทางที่ใช้งานง่าย ใช้ 301 (Moved Permanently)
เพื่อระบุให้เครื่องมือค้นหาและเบราว์เซอร์ทราบว่าเวอร์ชัน HTTPS เป็น Canonical
และเปลี่ยนเส้นทางผู้ใช้ไปยังเว็บไซต์เวอร์ชัน HTTPS จาก HTTP
การจัดอันดับการค้นหา
Google ใช้ HTTPS เป็นคุณภาพการค้นหาเชิงบวก สัญญาณบอกสถานะ นอกจากนี้ Google ยังเผยแพร่คำแนะนำเกี่ยวกับวิธีโอน ย้าย หรือย้ายข้อมูล เว็บไซต์พร้อมๆ กับการบำรุงรักษา อันดับการค้นหา นอกจากนี้ Bing ยังเผยแพร่หลักเกณฑ์สำหรับ ผู้ดูแลเว็บ
ประสิทธิภาพ
เมื่อปรับแต่งเนื้อหาและแอปพลิเคชันได้อย่างดีแล้ว (ดู Steve Souders เล่มที่ เพื่อรับคำแนะนำ) TLS ที่เหลือ ข้อกังวลด้านประสิทธิภาพโดยทั่วไปจะมีเพียงเล็กน้อยเมื่อเทียบกับค่าใช้จ่ายโดยรวมของ แอปพลิเคชัน คุณยังสามารถลดและตัดค่าใช้จ่ายเหล่านั้นได้ด้วย สำหรับคำแนะนำเกี่ยวกับ TLS โปรดดูการสร้างเครือข่ายเบราว์เซอร์ประสิทธิภาพสูงโดย Ilya Grigorik และช่อง Ivan Ristic OpenSSL Cookbook และ หัวข้อย่อยแบบ SSL และ TLS
ในบางกรณี TLS สามารถปรับปรุงประสิทธิภาพ โดยส่วนใหญ่เป็นผลจากการทำให้ HTTP/2 ที่เป็นไปได้ สำหรับข้อมูลเพิ่มเติม โปรดดู Chris Palmer's พูดคุยเกี่ยวกับประสิทธิภาพของ 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 ทั้งหมดเป็น 1 ตัวเลือกเป็นอย่างน้อย คุณอาจต้องเลื่อนการยืนยัน ทำให้ URL ของ IntraSite มีความเกี่ยวข้องจนกว่าจะมีผู้ลงโฆษณามากพอ ทำงานร่วมกันได้อย่างเหมาะสม