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

Chris Palmer

Matt Gaunt

Twitter หน้าแรก

ขั้นตอนที่กล่าวถึงในบทความนี้

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

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

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

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

เริ่มต้นด้วยการสร้างคู่คีย์ RSA แบบ 2,048 บิต คีย์ที่เล็กกว่าอย่าง 1,024 บิตนั้นไม่เพียงพอต่อการคาดเดาของการโจมตีแบบบรูตฟอร์ซ คีย์ที่มีขนาดใหญ่กว่า เช่น 4,096 บิต เป็นคีย์ที่มากเกินไป เมื่อเวลาผ่านไป ขนาดคีย์จะเพิ่มขึ้นเมื่อ การประมวลผลด้วยคอมพิวเตอร์มีราคาถูกลง ขณะนี้มี 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

ตัวอย่างเช่น ปัจจุบัน CA แห่งหนึ่งเสนอราคาเหล่านี้

• มาตรฐาน: $16/ปี ใช้ได้กับ example.com และ www.example.com
• ไวลด์การ์ด: $150/ปี ใช้ได้สำหรับ example.com และ *.example.com

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

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

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

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

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

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

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

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

อย่างไรก็ตาม ผู้ให้บริการเว็บไซต์ส่วนใหญ่จะใช้โฮสติ้งเสมือนที่อิงตามชื่อเพื่อสงวนที่อยู่ IP และเนื่องจากเป็นวิธีที่สะดวกกว่าโดยทั่วไป ปัญหาของ IE บน Windows XP และ Android เวอร์ชันเก่ากว่า 2.3 คือผู้ใช้ไม่เข้าใจ Server Name Indication (SNI) ซึ่งสำคัญมากสำหรับโฮสติ้งเสมือนที่ใช้ชื่อ HTTPS

ลูกค้าที่ไม่รองรับ SNI จะถูกแทนที่ด้วยซอฟต์แวร์ที่ทันสมัยในเร็วๆ นี้ ตรวจสอบสตริง User Agent ในบันทึกคำขอเพื่อให้ทราบเมื่อมีผู้ใช้ย้ายข้อมูลไปยังซอฟต์แวร์ที่ทันสมัยมากพอ (คุณสามารถเลือกเกณฑ์ของคุณได้ เช่น น้อยกว่า 5% หรือน้อยกว่า 1%)

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

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

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

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

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

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

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

นอกจากนี้ เมื่อคุณลิงก์ไปยังหน้าเว็บอื่นๆ ในเว็บไซต์ ผู้ใช้อาจถูกดาวน์เกรดจาก HTTPS เป็น HTTP

ปัญหาเหล่านี้เกิดขึ้นเมื่อหน้าเว็บมี URL ภายในเว็บไซต์ที่มีคุณสมบัติครบถ้วนที่ใช้รูปแบบ http://

<h1>Welcome To Example.com</h1>
<script src="http://example.com/jquery.js"></script>
<link rel="stylesheet" href="http://assets.example.com/style.css"/>
<img src="http://img.example.com/logo.png"/>;
<p>A <a href="http://example.com/2014/12/24/">new post on cats!</a></p>

กล่าวคือ ทำให้ 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

คุณต้องวางลิงก์ Canonical ที่ส่วนหัวของหน้าเว็บเพื่อบอกเครื่องมือค้นหาว่า HTTPS เป็นวิธีที่ดีที่สุดในการเข้าถึงเว็บไซต์

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

เปิดใช้การรักษาความปลอดภัยในการรับส่งข้อมูลแบบเข้มงวดและคุกกี้ที่ปลอดภัย

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

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

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

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

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

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

ดังนั้น โปรดเปลี่ยนเว็บแอปพลิเคชันของคุณให้ตั้งค่าสถานะความปลอดภัยในคุกกี้ที่แอปพลิเคชันตั้งค่าเสมอ หน้า OWASP นี้จะอธิบายถึงวิธีตั้งค่าแฟล็กที่ปลอดภัยในเฟรมเวิร์กแอปพลิเคชันต่างๆ ทุกเฟรมเวิร์กแอปพลิเคชันมีวิธีการตั้งค่าสถานะ

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

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

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

การแสดง

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

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

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

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

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

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

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

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

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