กรณีการใช้งาน PKI: HTTPS, S/MIME และการลงนามโค้ด
ประยุกต์ใช้แนวคิด PKI กับสถานการณ์จริง ได้แก่ การรักษาความปลอดภัยของการรับส่งข้อมูลบนเว็บ การเข้ารหัสอีเมลด้วย S/MIME และการตรวจสอบความถูกต้องของซอฟต์แวร์ด้วยใบรับรองสำหรับการลงนามโค้ด
กรณีการใช้งาน PKI: HTTPS, S/MIME และการลงนามโค้ด เป็นบทเรียน Cloud & IT Cert Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Cloud & IT Cert Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
PKI ในการใช้งานจริง
โครงสร้างพื้นฐานกุญแจสาธารณะ (PKI) เป็นโครงสร้างเบื้องหลังที่ทำให้การสื่อสารดิจิทัลมีความปลอดภัย ใบรับรองและ CA ที่คุณได้ศึกษาไปถูกนำไปใช้ในสถานการณ์จริงมากมายทุกวัน การสอบ Security+ ทดสอบความสามารถของคุณในการระบุกรณีการใช้งาน PKI ทำความเข้าใจว่าใบรับรองประเภทใดเหมาะกับแต่ละกรณี และระบุได้ว่า PKI ให้การป้องกันอะไรในแต่ละบริบท กรณีการใช้งานสามประเภทที่สำคัญที่สุดในการสอบคือ HTTPS/TLS (ความปลอดภัยของเว็บ), S/MIME (ความปลอดภัยของอีเมล) และการลงลายมือชื่อโค้ด (ความถูกต้องสมบูรณ์ของซอฟต์แวร์)
HTTPS: PKI สำหรับความปลอดภัยของเว็บ
HTTPS (HTTP ผ่าน TLS) เป็นกรณีการใช้งาน PKI ที่เห็นได้ชัดเจนที่สุด เมื่อคุณเชื่อมต่อไปยัง https://bank.com เบราว์เซอร์ของคุณจะ: (1) รับใบรับรอง TLS ของเซิร์ฟเวอร์ (2) ตรวจสอบว่าโซ่ใบรับรองนำไปสู่ CA รากที่เชื่อถือได้ (3) ตรวจสอบชื่อโฮสต์กับฟิลด์ SAN (4) ตรวจสอบว่าใบรับรองไม่ถูกเพิกถอน และ (5) ใช้กุญแจสาธารณะสำหรับการแลกเปลี่ยนกุญแจแบบ Diffie-Hellman เพื่อสร้างเซสชันที่เข้ารหัส ไอคอนรูปแม่กุญแจในเบราว์เซอร์แสดงว่าการตรวจสอบทั้งหมดนี้ผ่าน หากไม่มีใบรับรองหรือใบรับรองไม่ถูกต้อง เบราว์เซอร์จะแสดงคำเตือน ซึ่งทำให้ผู้ใช้ส่วนใหญ่หยุดดำเนินการต่อ
# Check HTTPS certificate details
curl -v https://example.com 2>&1 | grep -A 10 'SSL certificate'
# Test TLS configuration quality
openssl s_client -connect example.com:443 -tls1_3 2>/dev/null | \
grep -E 'Protocol|Cipher|Verify'
# Protocol: TLSv1.3
# Cipher: TLS_AES_256_GCM_SHA384
# Verify return code: 0 (ok)S/MIME: PKI สำหรับความปลอดภัยของอีเมล
S/MIME (Secure/Multipurpose Internet Mail Extensions) ใช้ใบรับรอง PKI เพื่อให้บริการด้านความปลอดภัยสองประการสำหรับอีเมล การเข้ารหัส: ผู้ส่งเข้ารหัสเนื้อหาอีเมลด้วยกุญแจสาธารณะของผู้รับ ทำให้มีเพียงผู้รับเท่านั้นที่ถอดรหัสได้ จึงช่วยปกป้องความลับแม้อีเมลจะถูกดักระหว่างส่งหรือจัดเก็บอยู่บนเซิร์ฟเวอร์ที่ถูกบุกรุก ลายมือชื่อดิจิทัล: ผู้ส่งลงลายมือชื่อด้วยกุญแจส่วนตัว เพื่อพิสูจน์ให้ผู้รับทราบว่าอีเมลมาจากผู้ส่งจริงและไม่ถูกแก้ไข จึงช่วยปกป้องความถูกต้องสมบูรณ์และให้คุณสมบัติไม่สามารถปฏิเสธความรับผิดได้ S/MIME กำหนดให้ผู้ใช้แต่ละรายมีใบรับรองของตนเองที่ออกโดย CA
# S/MIME email signing and encryption with OpenSSL
# Sign an email
openssl smime -sign -in email_body.txt -signer alice_cert.pem \
-inkey alice_private.key -out signed_email.eml -outform PEM
# Encrypt an email (using Bob's public key/certificate)
openssl smime -encrypt -aes256 -in email_body.txt \
-out encrypted_email.eml bob_cert.pem
# Bob decrypts with his private key
openssl smime -decrypt -in encrypted_email.eml \
-recip bob_cert.pem -inkey bob_private.keyการลงลายมือชื่อโค้ด: PKI สำหรับความถูกต้องสมบูรณ์ของซอฟต์แวร์
การลงลายมือชื่อโค้ด ใช้ PKI เพื่อลงลายมือชื่อดิจิทัลให้ซอฟต์แวร์ เช่น ไฟล์ปฏิบัติการ สคริปต์ ไดรเวอร์ และตัวติดตั้ง เพื่อให้ผู้ใช้ตรวจสอบได้ว่าซอฟต์แวร์มาจากผู้เผยแพร่ที่เชื่อถือได้และไม่ถูกดัดแปลง ผู้จำหน่ายซอฟต์แวร์ลงลายมือชื่อให้โค้ดด้วยกุญแจส่วนตัวจากใบรับรองสำหรับลงลายมือชื่อโค้ดที่ออกโดย CA ที่เชื่อถือได้ เมื่อผู้ใช้เรียกใช้ซอฟต์แวร์ OS จะตรวจสอบลายมือชื่อโดยใช้กุญแจสาธารณะของผู้จำหน่ายจากโซ่ใบรับรอง Windows SmartScreen, macOS Gatekeeper และร้านแอป iOS/Android ต่างพึ่งพาการลงลายมือชื่อโค้ดเพื่อยืนยันแหล่งที่มาของซอฟต์แวร์ ซอฟต์แวร์ที่ไม่มีลายมือชื่ออาจถูกบล็อกหรือทำให้เกิดคำเตือนด้านความปลอดภัย
# Verify code signing on Windows (PowerShell)
Get-AuthenticodeSignature -FilePath 'C:\Software\installer.exe' | Format-List
# Status: Valid
# SignerCertificate: [certificate details]
# TimeStamperCertificate: [timestamp CA details]
# On Linux/macOS, verify GPG signature of downloaded software
gpg --verify hashicorp_public.gpg terraform.zip.sig terraform.zip
# Good signature from 'HashiCorp Security (hashicorp.com/security)'การตรวจสอบสิทธิ์ด้วยใบรับรอง Client
การตรวจสอบสิทธิ์ด้วยใบรับรอง Client (เรียกอีกอย่างว่า TLS แบบร่วมกันหรือ mTLS) ขยายรูปแบบ TLS มาตรฐานด้วยการกำหนดให้ Client ต้องแสดงใบรับรองด้วย ใน TLS มาตรฐาน จะตรวจสอบสิทธิ์เฉพาะเซิร์ฟเวอร์ด้วยใบรับรอง แต่ใน mTLS ทั้งสองฝ่ายจะตรวจสอบสิทธิ์ซึ่งกันและกัน วิธีนี้ใช้สำหรับ: การตรวจสอบสิทธิ์ VPN (ใช้สมาร์ตการ์ดหรือใบรับรอง Client แทนรหัสผ่าน), การตรวจสอบสิทธิ์ API (การตรวจสอบสิทธิ์ระหว่างเครื่องกับเครื่อง โดย Client เป็นบริการ ไม่ใช่มนุษย์) และการเข้าถึงของผู้ดูแลระบบที่มีสิทธิ์สูง (กำหนดให้ผู้ดูแลระบบใช้โทเค็นฮาร์ดแวร์ที่มีใบรับรองฝังอยู่)
# nginx configuration for mutual TLS (client certificate required)
# server {
# listen 443 ssl;
# ssl_certificate /path/to/server_cert.pem;
# ssl_certificate_key /path/to/server_key.pem;
# ssl_client_certificate /path/to/ca_cert.pem;
# ssl_verify_client on;
# ssl_verify_depth 2;
# }
# Test with a client certificate
curl --cert client_cert.pem --key client_key.pem https://api.example.com/การตรวจสอบกุญแจโฮสต์ SSH
SSH ใช้การเข้ารหัสด้วยกุญแจสาธารณะเพื่อวัตถุประสงค์สองประการ ได้แก่ การตรวจสอบสิทธิ์เซิร์ฟเวอร์ และการตรวจสอบสิทธิ์ Client การตรวจสอบสิทธิ์เซิร์ฟเวอร์: เมื่อคุณเชื่อมต่อกับเซิร์ฟเวอร์ SSH เป็นครั้งแรก เซิร์ฟเวอร์จะแสดงกุญแจโฮสต์ (กุญแจสาธารณะ) และ Client SSH ของคุณจะจัดเก็บกุญแจนี้ไว้ใน ~/.ssh/known_hosts ในการเชื่อมต่อครั้งถัดไป หากกุญแจโฮสต์เปลี่ยนแปลง ซึ่งอาจบ่งชี้ถึงการโจมตีแบบ MITM หรือการสร้างเซิร์ฟเวอร์ใหม่ SSH จะแจ้งเตือนคุณ การตรวจสอบสิทธิ์ Client: แทนที่จะใช้รหัสผ่าน ผู้ดูแลระบบจะใช้คู่กุญแจ โดยเพิ่มกุญแจสาธารณะลงใน authorized_keys ของเซิร์ฟเวอร์ และใช้กุญแจส่วนตัวซึ่งจะไม่ถูกส่งออกไปเพื่อพิสูจน์ตัวตน กุญแจโฮสต์ SSH แยกจากใบรับรอง PKI แต่ทำหน้าที่สร้างความไว้วางใจเช่นเดียวกัน
# First-time SSH connection stores server host key
ssh user@server.example.com
# The authenticity of host 'server.example.com' can't be established.
# ED25519 key fingerprint is SHA256:abc123...
# Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
# Host key stored in: ~/.ssh/known_hosts
cat ~/.ssh/known_hosts | grep server.example.com
# If host key changes:
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!การลงลายมือชื่อเอกสารและการประทับเวลา
PKI ช่วยให้สามารถลงลายมือชื่อเอกสารดิจิทัลที่มีผลผูกพันทางกฎหมายในหลายเขตอำนาจศาล ลายมือชื่อในเอกสาร PDF ของ Adobe, DocuSign และระบบลายมือชื่ออิเล็กทรอนิกส์ของหน่วยงานรัฐ ล้วนใช้ใบรับรอง PKI เพื่อลงลายมือชื่อเอกสาร ส่วนประกอบสำคัญที่ช่วยเสริมการลงลายมือชื่อเอกสารคือการประทับเวลา โดยหน่วยงานประทับเวลาที่เชื่อถือได้ (TSA) จะลงลายมือชื่อซ้ำให้แฮชของเอกสารพร้อมเวลาที่เชื่อถือได้ เพื่อพิสูจน์ว่าเอกสารมีอยู่ ณ จุดเวลาที่กำหนด การประทับเวลายังจำเป็นต่อการลงลายมือชื่อโค้ดด้วย หากไม่มีการประทับเวลา ลายมือชื่อโค้ดจะไม่ถูกต้องเมื่อใบรับรองสำหรับลงลายมือชื่อหมดอายุ แม้ซอฟต์แวร์นั้นจะเผยแพร่ก่อนวันหมดอายุก็ตาม
ใบรับรองอุปกรณ์ IoT
เมื่ออุปกรณ์ IoT แพร่หลายมากขึ้น PKI จึงเป็นกลไกสำหรับตรวจสอบสิทธิ์อุปกรณ์ในระดับขนาดใหญ่ อุปกรณ์แต่ละเครื่องจะได้รับใบรับรองเฉพาะตัวระหว่างการผลิต (กระบวนการที่เรียกว่าการจัดเตรียมข้อมูลระบุตัวตนอุปกรณ์) ทำให้เซิร์ฟเวอร์ตรวจสอบสิทธิ์อุปกรณ์แต่ละเครื่องจากใบรับรองของอุปกรณ์ได้ วิธีนี้รองรับสถานการณ์ต่าง ๆ เช่น มิเตอร์อัจฉริยะพิสูจน์ตัวตนกับเซิร์ฟเวอร์ของผู้ให้บริการสาธารณูปโภค อุปกรณ์ทางการแพทย์ตรวจสอบสิทธิ์กับเครือข่ายโรงพยาบาล หรือยานพาหนะทั้งกลุ่มตรวจสอบสิทธิ์กับระบบเบื้องหลังของผู้ผลิต PKI สำหรับ IoT ต้องรองรับอุปกรณ์หลายล้านเครื่องที่มีทรัพยากรจำกัด จึงผลักดันให้มีการใช้ใบรับรอง ECC เนื่องจากมีขนาดเล็กและตรวจสอบได้รวดเร็ว
การตรวจสอบสิทธิ์ VPN ด้วยใบรับรอง
การตรวจสอบสิทธิ์ VPN ด้วยใบรับรองมีความปลอดภัยมากกว่าการตรวจสอบสิทธิ์ VPN ด้วยรหัสผ่านอย่างมาก ผู้ใช้หรืออุปกรณ์ VPN แต่ละรายจะได้รับใบรับรอง Client ที่ออกโดย CA ภายในขององค์กร เมื่อเชื่อมต่อ เกตเวย์ VPN จะตรวจสอบใบรับรอง Client โดยยืนยันว่าใบรับรองออกโดย CA ภายในที่เชื่อถือได้ ยังอยู่ในช่วงเวลาที่ใช้งานได้ และยังไม่ถูกเพิกถอนผ่าน CRL/OCSP เมื่อพนักงานลาออก การเพิกถอนใบรับรองของพนักงานจะป้องกันการเข้าถึง VPN ได้ทันที ซึ่งน่าเชื่อถือกว่าการหวังว่าพนักงานจะไม่แบ่งปันรหัสผ่านให้ผู้อื่น
# OpenVPN client certificate configuration
# client
# remote vpn.example.com 1194
# proto udp
# ca ca.crt <- CA certificate (trust anchor)
# cert client.crt <- Client's certificate
# key client.key <- Client's private key
# tls-auth ta.key 1
# cipher AES-256-GCM
# The VPN server verifies the client cert chain against ca.crt
# Revoked certs listed in CRL won't be acceptedข้อผิดพลาดทั่วไปเกี่ยวกับใบรับรอง
ผู้เชี่ยวชาญด้านความปลอดภัยต้องสามารถวินิจฉัยข้อผิดพลาดทั่วไปเกี่ยวกับใบรับรองได้ ใบรับรองหมดอายุ: วันที่ notAfter ผ่านไปแล้ว ให้ต่ออายุใบรับรอง ชื่อโฮสต์ไม่ตรงกัน: SAN ของใบรับรองไม่ตรงกับชื่อโฮสต์ที่ร้องขอ ให้ตรวจสอบ CN และ SAN อาจต้องใช้ใบรับรองแบบไวลด์การ์ดหรือใบรับรองหลาย SAN ใบรับรองที่ลงลายมือชื่อด้วยตนเอง: ไม่มี CA รับรองใบรับรองนี้ ให้เพิ่มใบรับรองลงในที่เก็บความไว้วางใจภายในเครื่อง หรือเปลี่ยนเป็นใบรับรองที่ CA ลงลายมือชื่อ โซ่ใบรับรองไม่ครบ: เซิร์ฟเวอร์ไม่ได้ส่งใบรับรอง CA ระดับกลางมา ให้กำหนดค่าเซิร์ฟเวอร์เพื่อส่งโซ่ใบรับรองทั้งหมด ใบรับรองถูกเพิกถอน: CRL หรือ OCSP แสดงว่าถูกเพิกถอน ต้องรับมือกับการเปิดเผยกุญแจทันที
# Diagnose certificate errors with openssl
openssl s_client -connect server.example.com:443 2>&1
# Common error messages:
# depth=0 ... error 10 at 0 depth lookup: certificate has expired
# depth=0 ... error 18: self-signed certificate
# depth=0 ... error 20: unable to get local issuer certificate (broken chain)
# depth=0 ... error 23: certificate revoked
# Verify return code: 0 (ok) = successใบรับรองไวลด์การ์ดเทียบกับใบรับรอง SAN
ใบรับรองสองประเภทนี้รองรับชื่อโฮสต์หลายชื่อ ใบรับรองแบบไวลด์การ์ดครอบคลุมโดเมนย่อยระดับแรกทั้งหมดของโดเมนหนึ่ง: *.example.com ครอบคลุม www.example.com, mail.example.com, api.example.com แต่ไม่ครอบคลุม sub.api.example.com (สองระดับ) ใช้ใบรับรองหนึ่งใบและกุญแจส่วนตัวหนึ่งชุดกับทุกบริการ สะดวกแต่มีความเสี่ยง หากกุญแจถูกเปิดเผย บริการทั้งหมดจะได้รับผลกระทบ ส่วนใบรับรองหลาย SANจะแสดงรายการโดเมนเฉพาะหลายโดเมนไว้อย่างชัดเจนในส่วนขยาย SAN (เช่น example.com, www.example.com, api.example.com) มีความละเอียดในการกำหนดมากกว่า แต่ต้องปรับปรุงใบรับรองเมื่อเพิ่มโดเมนใหม่
ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิด CompTIA Security+ (SY0-701) จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า ใบรับรอง HTTPS/TLS ใช้เข้ารหัสข้อมูลเว็บและตรวจสอบสิทธิ์เซิร์ฟเวอร์; ใบรับรอง S/MIME ช่วยให้ลงลายมือชื่อและเข้ารหัสอีเมลได้; ใบรับรองการลงลายมือชื่อโค้ดพิสูจน์ความถูกต้องสมบูรณ์ของซอฟต์แวร์และตัวตนของผู้เผยแพร่ และใบรับรอง Clientช่วยให้เกิดการตรวจสอบสิทธิ์ซึ่งกันและกันสำหรับ VPN และ API ต่อไปเราจะศึกษานโยบายรหัสผ่านและการตรวจสอบสิทธิ์หลายปัจจัย
คำถามที่พบบ่อย
บทเรียน “กรณีการใช้งาน PKI: HTTPS, S/MIME และการลงนามโค้ด” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “กรณีการใช้งาน PKI: HTTPS, S/MIME และการลงนามโค้ด” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Cloud & IT Cert Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Cloud & IT Cert Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “กรณีการใช้งาน PKI: HTTPS, S/MIME และการลงนามโค้ด”
ประยุกต์ใช้แนวคิด PKI กับสถานการณ์จริง ได้แก่ การรักษาความปลอดภัยของการรับส่งข้อมูลบนเว็บ การเข้ารหัสอีเมลด้วย S/MIME และการตรวจสอบความถูกต้องของซอฟต์แวร์ด้วยใบรับรองสำหรับการลงนามโค้ด คุณปฏิบัติ Cloud & IT Cert Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Cloud & IT Cert Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Cloud & IT Cert Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “กรณีการใช้งาน PKI: HTTPS, S/MIME และการลงนามโค้ด” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Cloud & IT Cert Prep นี้ได้ไหม
ได้ บทเรียน Cloud & IT Cert Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- หน่วยงานออกใบรับรองและสายโซ่ความน่าเชื่อถือ
- โครงสร้างใบรับรอง X.509
- วงจรชีวิตและการเพิกถอนใบรับรอง
- กรณีการใช้งาน PKI: HTTPS, S/MIME และการลงนามโค้ด