Category: Network Configuration

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

เอาล่ะ ถ้าจะว่ากันตามตรงแล้ว งานที่ต้องเพิ่มขึ้นมาสำหรับการที่จะทำให้ เว็บเซิร์ฟเวอร์สามารถใช้ https ได้ ถ้าทำให้มันใช้ http ได้แล้ว โดยทั่วไปก็ไม่ได้ยุ่งยากมากขึ้นเท่าไหร่ ขึ้นอยู่กับระบบปฏิบัติการที่เลือกใช้ ขึ้นอยู่กับตัวเว็บเซิร์ฟเวอร์ที่เลือกใช้ ขึ้นอยู่กับเซอร์ติฟิเคท (certificate) ที่ใช้ด้วย แต่ว่ากันโดยทั่วไป ระบบที่มีผู้ใช้งานเยอะ ตัวติดตั้งซอฟต์แวร์ของระบบปฏิบัติการ ก็มักจะจัดเตรียมวิธีการตรงนี้ไว้ให้แล้ว เหลือแค่การเรียกใช้งานเพิ่มแค่ไม่กี่คำสั่ง ก็สามารถใช้งานได้เลย
ขอยกตัวอย่างเลยก็แล้วกัน สำหรับระบบปฏิบัติการเดเบียนลินุกซ์ (Debian Linux) รุ่น เจสซี่ (jessie) และ ใช้งาน apache เวอร์ชัน 2 เป็นเว็บเซิร์ฟเวอร์

วิธีการติดตั้งตัวเว็บเซิร์ฟเวอร์ก็คือ

$ sudo apt-get install apache2

เพียงเท่านี้ เราก็สามารถใช้งานเว็บเซิร์ฟเวอร์ สำหรับให้บริการแบบสแตติกไฟล์ และสามารถใช้สคริปต์แบบ CGI ได้แล้ว
แล้วถ้าต้องการให้มันรองรับแบบไดนามิก โดยใช้ภาษา php ได้ด้วยล่ะ? ก็ไม่ได้ยากอะไร ก็เพียงเพิ่มโมดูลของ php เข้าไป โดยใช้คำสั่ง

$ sudo apt-get install libapache2-mod-php5

ตัวโปรแกรมสำหรับติดตั้ง (apt-get) ก็จะตรวจสอบ แพกเกจที่จำเป็นต้องใช้และยังไม่ได้ติิดตั้งเอาไว้ เช่น php5 แล้วก็ติดตั้งแพกเกจเหล่านั้นให้ด้วยเลยโดยอัตโนมัติ หลังจากนั้นเราก็สามารถสร้าง index.php ในไดเรคตอรี่ /var/www/html/ แล้วก็เขียนโปรแกรมภาษา php ให้บริการบนเว็บได้เลย

ทีนี้ถ้าต้องการให้บริการเว็บ โดยใช้ https โปรโตคอลล่ะ เพื่อให้มีการเข้ารหัสข้อมูลที่มีการรับส่งระหว่าง ตัวเว็บเบราเซอร์ และ เว็บเซิร์ฟเวอร์ อันนี้ ไม่จำเป็นจะต้องติดตั้งโมดูลเพิ่มเติม เพราะตัว apache ติดตั้งให้โดยปริยายตั้งแต่แรกแล้ว แต่ ไม่ได้เปิดให้ใช้งานโดยอัตโนมัติ ผู้ดูแลระบบจะต้องสั่งเพิ่มว่า ให้เปิดบริการแบบ https ด้วย โดยใช้คำสั่งดังนี้

$ sudo a2enmod ssl
$ sudo a2ensite default-ssl

และสั่ง restart ตัวเว็บเซิร์ฟเวอร์โดยใช้คำสั่ง

$ sudo systemctl restart apache2

เท่านี้ ก็จะสามารถใช้งาน https โปรโตคอลเพิ่มเติมขึ้นมาจากเดิม ที่ใช้งานได้เฉพาะ http โปรโตคอล

แต่ … มันไม่ได้จบง่ายๆแค่นั้นน่ะสิ ถึงแม้ว่าการให้บริการจะโดยใช้ https โปรโตคอลจะมีการเข้ารหัสข้อมูลที่มีการรับส่งระหว่างตัวเบราเซอร์กับตัวเซิร์ฟเวอร์ แต่ เซอร์ติฟิเคท (certificate) สำหรับกุญแจที่ใช้ในการเข้ารหัสข้อมูลนั้น จะเป็นแบบที่เรียกว่า self-signed certificate ซึ่งตัวเบราเซอร์โดยทั่วไปจะ ไม่เชื่อถือ (un trusted) ว่าเป็นเซอร์ติฟิเคท ที่ออกให้กับเว็บไซท์ ที่ระบุว่าเป็นโดเมนนั้นๆจริง

ในการใช้งานเว็บไซท์ที่ตัวกุญแจเข้ารหัสใช้ self-signed certificate ตัวเบราเซอร์ก็จะ “เตือน”, และสร้างความยุ่งยากในการใช้งานให้กับ ผู้ใช้ที่ต้องการเข้าใช้งานเว็บไซท์นั้นๆ

นั่นอาจจะไม่ได้เป็นปัญหาใหญ่อะไร สำหรับเว็บไซท์ที่สร้างขึ้นมาเพื่อให้บริการภายในหน่วยงานกันเอง ซึ่งผู้ใช้งานในหน่วยงาน อาจจะใช้วิธีการอื่นๆ เช่นเดินไปถาม, โทรศัพท์ไปถาม, ส่ง e-mail ไปถาม … หรือในกรณีที่เป็นจริงส่วนใหญ่ ก็คือ ไม่ต้องถาม ก็แค่กดปุ่มยอมรับความเสี่ยง ให้ตัวเบราเซอร์จำเซอร์ติฟิเคทนั้นไว้ แล้วก็ใช้งานไปแค่นั้นเอง

แต่นั่น อาจจะเป็นปัญหาในเรื่องของความน่าเชื่อถือ ถ้าเว็บไซท์ดังกล่าว เปิดให้บริการให้กับบุคคลภายนอกหน่วยงานด้วย

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

มันเป็นสิ่งที่ไม่ดี ในทางหนึ่ง มันเป็นการฝึกให้ผู้ใช้งานเว็บไซต์ ยอมรับ ในความไม่ปลอดภัยที่อาจจะมี และ นำไปใช้งานกับเว็บไซท์อื่นๆด้วย

ทางแก้ล่ะ ก็ไม่ได้เป็นเรื่องยุ่งยาก “มาก” แต่อย่างใด ก็แค่หาเซอร์ติฟิเคทที่ยอมรับโดยตัวเบราเซอร์มาใช้งานแค่นั้นเอง

อย่างไร? … ก็ … จ่ายตังค์ ซื้อ … 🙂

นั่นอาจจะทำให้เป็นเรื่องยุ่งยาก “มาก” ขึ้นมาทันทีสำหรับ หลายๆหน่วยงาน (ฮา)

สำหรับหน่วยงานภายในมหาวิทยาลัยสงขลานครินทร์ อาจจะมีอีกหนึ่งทางเลือก นั่นคือว่า ถ้าเว็บไซท์ที่ผู้ดูแล มีโดเมนเป็น .psu.ac.th และไม่ได้เป็นโดเมนย่อยของ .psu.ac.th อีกที ตัวอย่างเช่น เว็บไซท์ www.psu.ac.th ถือว่าอยู่ในโดเมน .psu.ac.th แต่เว็บไซท์ www.coe.psu.ac.th จะอยู่ในโดเมนย่อย .coe ของ โดเมน .psu.ac.th อีกทีนึง

สำหรับเว็บไซท์ ที่อยู่ภายใต้โดเมน .psu.ac.th และไม่ได้อยู่ในโดเมนย่อย ก็จะสามารถติดต่อทาง ผู้ดูแลระบบเครือข่ายของศูนย์คอมพิวเตอร์ เพื่อขอใช้เซอร์ติฟิเคทสำหรับเว็บไซท์นั้นได้ เนื่องจากศูนย์คอมพิวเตอร์ จะซื้อเซอร์ติฟิเคทแบบที่เรียกว่า wildcard สำหรับโดเมน .psu.ac.th ซึ่งจะสามารถออกใบเซอร์ติฟิเคทสำหรับเว็บไซท์ ที่ไม่ได้อยู่ภายใต้โดเมนย่อยของ .psu.ac.th ให้ได้

แล้วสำหรับผู้ดูแลของเว็บไซท์ ที่ไปขอเซอร์ติฟิเคทของศูนย์คอมพิวเตอร์มาใช้งานไม่ได้ล่ะ ไม่ว่าจะสาเหตุเนื่องจาก โดเมนที่ใช้อยู่เป็นโดเมนย่อยของ .psu.ac.th อีกที หรือ ใช้โดเมนอื่นอยู่ที่ไม่ใช่ .psu.ac.th ทำอย่างไรดี?

ก็ … จ่ายตังค์ซื้อสิ … เฮ่ย ไม่ใช่!
งั้น … ใช้ self-signed certificate ต่อ … เฮ้ย! … แล้วจะเขียนมาหาพระแสงของ้าว อะไร …

โอเค อีกทางเลือกนึง ก็ตามที่เขียนไว้ในหัวข้อบทความน่ะแหละครับ มันมีทางเลือกที่เราจะใช้เซอร์ติฟิเคทที่รองรับโดยเบราเซอร์ทั่วไป และ ไม่ต้องจ่ายตังค์ นั่นคือใช้บริการของ letsencrypt ซึ่ง … ยังมีเรื่องที่ต้องพูดถึงกันอีกยาวพอสมควร และ โดยความขึ้เกียจของผู้เขียน ถ้าจะรอให้เขียนเสร็จเป็นบทความเดียวแล้วค่อยตีพิมพ์เลย ก็เดาได้ว่า คงจะไม่เสร็จแหละ สำหรับใครๆที่สนใจจะอ่านก่อนว่าขั้นตอนที่จะเอามาใช้งานทำได้อย่างไรบ้าง ก็เริ่มต้นจาก ที่นี่ https://letsencrypt.org/getting-started/ ได้ครับ

ผมขอจบบทความนี้ ไว้แค่นี้ก่อน แล้วค่อยมาต่อ ภาค 2 (หวังว่า) ในเวลาอีกไม่นาน 🙂