PEM Certificate Decoder: ถอดรหัส X.509 certificate และ CSR ในเบราว์เซอร์ของคุณ

สักวันหนึ่ง วิศวกรทุกคนต้องเจอ certificate error ที่อธิบายไม่ได้ บราวเซอร์ขึ้น ERR_CERT_AUTHORITY_INVALID pipeline ดับด้วย unable to get local issuer certificate หรือเซอร์วิสปฏิเสธสตาร์ตเพราะ certificate "has expired or is not yet valid" ข้อความพวกนี้บอกว่ามีอะไรผิด แต่แทบไม่เคยบอกว่าผิดตรงไหนหรือเพราะอะไร — เพราะไม่มีใครเปิดไฟล์แล้วกวาดตาดูเลย certificate error ดูเป็นปริศนาก็เพียงเพราะไฟล์ PEM ที่อยู่ตรงหน้านั้นมีคำตอบครบทุกอย่างอยู่แล้ว: ออกให้ใคร ใครเซ็น ครอบคลุม hostname ไหน และหมดอายุเมื่อไหร่

นั่นแหละคือสิ่งที่ PEM Certificate Decoder ฟรีตัวนี้ทำ มันเปิดหีบห่อนั้นในเบราว์เซอร์ของคุณ คุณวาง certificate หรือ CSR ลงไป แล้วเครื่องมือจะแกะโครงสร้าง DER ข้างใน PEM wrapper แล้วเรียง subject, issuer, รายการ SAN, วันที่ validity, serial number และชนิด public key ออกมาเป็นแผงที่อ่านได้ ทุกอย่างรันฝั่ง client — ไม่มีการอัปโหลด ไม่มีการเก็บ log — certificate staging ภายในของคุณจึงไม่เคยออกจากเครื่องเลย

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

ทำไมต้องใช้ PEM Certificate Decoder?

• ความเป็นส่วนตัว: การถอดรหัสเกิดขึ้นในเบราว์เซอร์ของคุณ — ไฟล์ PEM มักมี hostname ภายใน ชื่อโดเมน staging และชื่อ internal CA อยู่ในรายการ SAN การเอาไปวางในเว็บบริการถอดรหัสสุ่มสี่สุ่มห้า คือการส่งข้อมูลพวกนี้เข้า log ของบุคคลที่สาม เครื่องมือนี้ parse DER ในเครื่องคุณเอง certificate ภายในจึงอยู่ภายใน
• ไม่ต้องพิธีกรรมกับ OpenSSL — คำสั่ง openssl x509 -in cert.pem -text -noout ใช้ได้ก็ต่อเมื่อเครื่องนั้นมี OpenSSL แต่ที่ไหนที่ไม่มี แท็บเบราว์เซอร์เร็วกว่าการติดตั้งเสมอ โดยเฉพาะตอนเกิดเหตุบนเครื่องที่ล็อกสิทธิ์ไว้
• certificate กับ CSR ในเครื่องมือเดียว — รู้จักทั้งบล็อก -----BEGIN CERTIFICATE----- และ -----BEGIN CERTIFICATE REQUEST----- จึงตรวจของที่ได้รับมา กับของที่ทีมกำลังจะขอ ได้ในที่เดียว
• โชว์เฉพาะฟิลด์ที่สำคัญจริง ๆ — subject, issuer, SAN, validity, serial และ public key type หกอย่างที่คุณต้องเช็คแทบทุกครั้ง
• ไม่มีอะไรลับถูกเปิดเผยโดยการออกแบบ — certificate เป็นข้อมูลสาธารณะที่ส่งให้ผู้เยี่ยมชมทุกคนระหว่าง TLS handshake การถอดรหัสไม่ต้องใช้ private key จึงไม่มีความลับให้หายไปจากการเปิดดู

ฟีเจอร์เด่น

มีรายละเอียดน่าสนใจอยู่สองสามข้อ:

• แยก certificate กับ CSR ให้เองอัตโนมัติ — header ของบล็อก PEM ที่วางลงไปเลือก parser ที่ถูกต้อง แม้วาง CSR ไปโดยไม่ตั้งใจ ก็ยังถอดรหัสได้อย่างมีความหมาย ไม่ใช่แค่ error
• อ่านอย่างเดียว ฝั่ง client ล้วน — ไม่สร้าง key ไม่เซ็นอะไร ไม่อัปโหลด ไม่เก็บอะไรเลย เป็น viewer ที่พฤติกรรมคาดเดาได้ ซึ่งเป็นสิ่งที่คุณต้องการตอนเกิดเหตุ

วิธีใช้งาน

1. เปิดเครื่องมือ ไปที่หน้า PEM Certificate Decoder
2. วางบล็อก PEM — คัดลอกจากไฟล์ .pem หรือ .crt ที่เปิดใน text editor, จากอีเมล certificate หรือดึงมาจาก ticket โดยตรงก็ได้ ทั้ง certificate และ CSR ใช้ได้หมด
3. ถอดรหัส — ตัว parser อ่านไบต์ DER แล้วเติมแผงฟิลด์ให้ทันที
4. อ่านฟิลด์ที่ถอดออกมา — subject, issuer, SAN, validity, serial number และ public key type ไล่ตามลำดับ
5. ลงมือตามที่เห็น — เทียบ SAN กับ hostname ที่เสิร์ฟจริง, จดวัน Not After ลงปฏิทิน, เก็บ serial ลง inventory และถ้าดู bundle ให้ถอดรหัส PEM ใน chain ทีละชิ้น

ตัว certificate บอกอะไรเราบ้าง

X.509 certificate แท้จริงคือเอกสารรับรองตัวตนของ hostname หนึ่ง ผูกกับ public key และถูกเซ็นโดย issuer พอลอก base64 wrapper ออกแล้ว ทุกฟิลด์ตอบคำถามเชิงปฏิบัติการคนละคำถาม

Subject กับ issuer — subject คือตัวที่ certificate พูดถึง ส่วน issuer คือคนที่ เซ็น มัน ถ้าสองค่านี้เหมือนกันเป๊ะ แปลว่า self-signed — ปกติใน dev แต่เป็นธงเตือนใน production เมื่อ chain validate ไม่ผ่าน การเทียบ issuer ของ leaf กับ subject ของ intermediate บอกได้ทันทีว่า chain แม้แต่จะเรียงลำดับถูกหรือยัง

SAN — ฟิลด์ที่เบราว์เซอร์ใช้จับคู่จริง ๆ — extension ชื่อ Subject Alternative Name ลิสต์ hostname ทั้งหมดที่ certificate ครอบคลุม รวมถึง wildcard เบราว์เซอร์จับคู่ชื่อเว็บที่คุณพิมพ์กับรายการ SAN เท่านั้น — จบข่าว ส่วน common name (CN) เป็นของเก่า: client ยุคใหม่เมินมันตอนจับคู่ เพราะฟิลด์นี้เก่ากว่า domain สากลและใส่ได้ค่าเดียว ใบที่ตรง CN แต่ไม่ตรง SAN จึงผิดตามกติกาสมัยใหม่ไปเลย

หน้าต่าง validity — Not Before และ Not After กำหนดว่าใบนี้เชื่อถือได้ช่วงไหน หมดอายุแล้วคือต้องต่อ ยังไม่ถึง Not Before มักหมายถึงนาฬิกาเบี่ยงที่ไหนสักแห่ง ส่วนหน้าต่างยาวผิดปกติใน certificate สาธารณะคือกลิ่นนโยบายที่ควรสงสัย ใบสาธารณะทุกวันนี้มีอายุราว 90 ถึง 397 วัน หมดอายุจึงเป็นเรื่องตารางงาน ไม่ใช่ edge case

Serial number — ผู้ออกกำหนดให้และไม่ซ้ำกันต่อใบ มันคือวิธีที่ revocation list, CA และ log ของคุณเองอ้างอิงถึง artifact ตัวจริงบนเซอร์เวอร์ การเก็บ serial ลง inventory คือ audit trail ที่ถูกที่สุดที่คุณจะสร้างได้

ชนิด public key — RSA, ECDSA หรือ Ed25519 กำหนดความเร็ว handshake, ขนาดลายเซ็น และความเข้ากันได้กับ client: RSA 2048 คือตัวสำรองสากล, ECDSA P-256 คือค่า default ยุคใหม่ที่เร็ว, Ed25519 นิยมในระบบภายใน ทั้งชนิด key และ signature algorithm มองเห็นได้จากผลถอดรหัส

CSR กับ certificate ต่างกันอย่างไร — CSR (PKCS#10 certificate signing request) คือคำขอที่ยังไม่ได้เซ็น: มีแค่ subject กับ public key เท่านั้น — ไม่มี issuer ไม่มี validity ไม่มี serial เพราะ CA เป็นคนใส่พวกนั้นตอนเซ็น แก้ SAN ผิดก่อนเซ็นไม่เสียอะไร แก้หลังเซ็นคือ certificate ที่พัง ดังนั้นถอดรหัสคำขอก่อนเสมอ และตัว decoder จะบอกเองว่าคุณวางสองอย่างนี้อย่างไหนลงไป

นี่คือตัวอย่าง PEM แบบย่อ พร้อมจุดเด่นที่การถอดรหัสโชว์ให้เห็น:

-----BEGIN CERTIFICATE-----
MIIDkzCCAnOgAwIBAgIUX3Y2G7A0sLq9zC4KqF1wY8nS5jQwCgYIKoZIzj0EAwIw
... (ย่อเพื่อการอธิบาย) ...
-----END CERTIFICATE-----

• Subject: CN=api.example.com
• Issuer: CN=dev-lab-root CA
• SANs: DNS:api.example.com, DNS:www.api.example.com
• Validity: Not Before 2026-09-13, Not After 2027-09-13
• Serial: 5f 76 36 1b b0 34
• Public key: ECDSA, curve P-256

ตัวอย่างการใช้งานจริง

ดีบั๊ก TLS error

เมื่อ client รายงาน certificate error ให้ถอดรหัส certificate ที่เซอร์เวอร์เสิร์ฟจริง — ไม่ใช่ใบที่คุณเชื่อว่าคุณ deploy ไป — แล้วอ่านรายการ SAN ช่องว่างระหว่าง hostname ที่ขอกับรายการ SAN อธิบาย error พวก "เข้าเว็บผิด" ได้ในแวบเดียว และฟิลด์ issuer เผยสาเหตุคลาสสิกอีกอย่าง: certificate ทดสอบจาก internal CA หลุดไปอยู่บน endpoint สาธารณะ

ตรวจ SAN ก่อน deploy ใบต่ออายุ

การต่ออายุคือจุดที่ SAN เปลี่ยนเงียบ ๆ: subdomain หลุดจากออเดอร์ใหม่ แล้ว production ดับหลังผ่านไปหลายสัปดาห์ ถอดรหัสใบเก่ากับใบใหม่เอาไว้เทียบข้าง ๆ กันแล้วเทียบรายการ SAN — สามสิบวินาทีที่กัน outage แบบน่าอายที่สุดได้

ตรวจ CSR ก่อนเซ็น

ถ้าทีมคุณรัน internal CA ทุก CSR ที่เข้ามาควรถูกอ่านก่อนเซ็น ถอดรหัสคำขอ เช็คการสะกด subject กับรายการ SAN เทียบกับ ticket และยืนยันว่าชนิด public key ตรงตามนโยบายการออกใบ — เพราะ certificate ที่คุณ emit ออกไปคือสิ่งที่ทุกคนจะเชื่อถือ

Best Practices

• จับคู่ด้วย SAN ไม่ใช่ CN — common name คือฉลาก รายการ SAN ต่างหากคือสัญญา
• เช็ค chain ทั้งเส้นแยกทีละใบ — ถอดรหัส leaf, intermediate แต่ละใบ และ root แล้วยืนยันว่า issuer ของใบบนตรงกับ subject ของใบล่าง
• อย่าวาง private key ไว้ที่ไหนเด็ดขาด — การถอดรหัสต้องใช้แค่ส่วนสาธารณะ เครื่องมือที่ขอ private key เพื่อ "ดูรายละเอียดเพิ่ม" คือธงแดง ไม่ใช่ฟีเจอร์
• ตั้ง reminder เรื่องหมดอายุทันทีที่ถอดรหัส — วัน Not After มีค่าเมื่อมีคนลงมือ ใส่ reminder ต่ออายุล่วงหน้า 30 วันในปฏิทินทีม
• เก็บ serial number ลง inventory — ตาราง serial ต่อ service เปลี่ยน triage เรื่อง revocation จากเรื่องที่ต้องเดาเป็นชั่วโมง ให้เหลือเพียงการค้นหาไม่กี่นาที
• ตรวจ CSR เทียบกับเจตนา ไม่ใช่การสะกด — ถอดรหัสผ่านสะอาดไม่ได้แปลว่าคำขอถูก เทียบ SAN กับสิ่งที่เซอร์วิสเสิร์ฟจริงก่อนออกใบ

เริ่มถอดรหัส certificate แรกของคุณวันนี้

ไฟล์ PEM ไม่ใช่กล่องดำ — มันคือเอกสารรับรองตัวตนแบบสาธารณะที่รอให้ใครสักคนอ่าน เปิด PEM Certificate Decoder วาง certificate ที่อยู่เบื้องหลัง error ปริศนาตัวถัดไป แล้วอ่านทุกฟิลด์ได้ในไม่กี่วินาที ทั้งหมดในเบราว์เซอร์ของคุณ ถอดรหัสก่อน สรุปทีหลัง

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Certificate Generator — ออก self-signed certificate และ key สำหรับ dev และทดสอบในเครื่อง
• OpenSSL Command Generator — ประกอบคำสั่ง openssl สำหรับ key, CSR และ certificate โดยไม่ต้องจำ flag ใด ๆ
• Security Headers Generator — จับคู่ certificate ที่ถูกต้องกับชุด header ที่แข็งแรง ตั้งแต่ HSTS ไปจนถึง CSP

ทุก certificate เล่าเรื่องของมัน — ตอนนี้คุณอ่านออกแล้ว

คำถามที่พบบ่อย

ถ: วาง certificate ลงในตัวถอดรหัสได้อย่างปลอดภัยจริงหรือ?

ตอบ: ปลอดภัยสองชั้น หนึ่ง certificate เป็นข้อมูลสาธารณะ — ผู้เยี่ยมชมทุกคนบนเว็บคุณได้รับมันระหว่าง TLS handshake อยู่แล้ว — จึงไม่มีอะไรลับอยู่ในนิยาม สอง เครื่องมือนี้ถอดรหัสทั้งหมดในเบราว์เซอร์ สิ่งที่วางจึงไม่เคยออกจากเครื่องคุณ สิ่งเดียวที่ห้ามวางที่ไหนก็ได้คือ private key ซึ่งการถอดรหัสไม่เคยขอด้วย

ถ: เครื่องมือถอดรหัส CSR ได้ด้วยหรือไม่?

ตอบ: ได้ มันจำได้ว่าอะไรคือ PKCS#10 certificate signing request แล้วถอดรหัส subject กับ public key ที่อยู่ในนั้น อย่าลืมว่า CSR ขาดอะไรโดยตั้งใจ: issuer, validity และ serial ยังไม่เกิดจนกว่า CA จะเซ็น แผงที่ดูสั้นหลังวาง CSR จึงเป็นเรื่องปกติตามสเปก ไม่ใช่บั๊ก

ถ: ทำไมเบราว์เซอร์ปฏิเสธ certificate ทั้งที่ common name ตรง?

ตอบ: เพราะเบราว์เซอร์จับคู่ hostname ที่ขอกับรายการ SAN ไม่ใช่ CN certificate ที่ CN บอกว่า api.example.com แต่รายการ SAN ไม่มีชื่อนั้น จะโดนปฏิเสธบน client ยุคใหม่ทุกตัว ถอดรหัสแล้วเช็ครายการ SAN เป็นอย่างแรก — เท่านี้ก็ระงับรายงาน hostname mismatch ส่วนใหญ่ได้