เปิดใช้ 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 บิต คีย์ที่สั้นอาจถูกทำลายได้จากการโจมตีด้วยการเดาแบบ 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>
ใช้ 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>
ใช้ URL ของ HTTPS สำหรับลิงก์ไปยังเว็บไซต์อื่นๆ หากเป็นไปได้

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