OpenSSL Command Generator: สร้าง CSR, self-signed certificate และ PKCS12 ได้ในไม่กี่วินาที

ลองให้ developer คนไหนเขียนคำสั่ง openssl จากความจำดูสิ รับรองว่าต้องนิ่งไปแป๊บหนึ่ง ทุกคนรู้จักเครื่องมือนี้ แต่แทบไม่มีใครจำได้ว่า flag ที่ให้ key ไม่ถูกเข้ารหัสคือ -nodes หรือ -no-des, SAN ต้องใส่ใน config file หรือส่งผ่าน -addext หรือทำไมการสร้าง certificate ถึงต้องใช้คำสั่ง openssl req ตั้งแต่แรก CLI ของ openssl นั้นทรงพลังแต่ก็โด่งดังเรื่อง "จำไม่ได้" — มี subcommand หลายสิบตัว flag ตัวอักษรเดียวที่เดาไม่ออก และ syntax ที่เปลี่ยนเล็กน้อยระหว่างเวอร์ชัน

OpenSSL Command Generator ช่วยตัดปัญหานี้ออกไป คุณเลือกงาน — สร้าง CSR, ทำ self-signed certificate, แปลงไฟล์ key หรือ PKCS12 หรือตรวจสอบ certificate — กรอก common name และรายละเอียด SAN แล้วเครื่องมือจะประกอบคำสั่งที่ถูกต้องออกมาให้ทันที พร้อม copy ไปวางใน terminal ได้เลย ไม่ต้องเปิด man page ไม่ต้องไล่ Stack Overflow หลายแท็บ และไม่ต้องพึ่ง snippet จาก gist ปี 2016 อีกต่อไป

ที่สำคัญไม่แพ้กัน: เครื่องมือนี้ประมวลผล 100% ฝั่ง client-side ชื่อโดเมน รายละเอียดองค์กร และตัวเลือกของ private key ของคุณไม่เคยออกจากเบราว์เซอร์ ไม่มีการอัปโหลด บันทึก หรือเก็บข้อมูลใด ๆ ซึ่งเป็นมาตรฐานที่สมควรได้จากเครื่องมือที่อยู่แกนกลางของ workflow ด้าน TLS ของคุณ

ทำไมต้องใช้ OpenSSL Command Generator

• เลิกไล่ล่า flag ที่ลืมไปแล้ว CLI ของ openssl มี option หลายร้อยตัวกระจายอยู่ตาม subcommand อย่าง req, x509, genrsa, pkcs12 เครื่องมือนี้ประกอบชุดคำสั่งที่ถูกต้องให้คุณเอง เลิกเดาแล้วเริ่มลงมือทำได้เลย
• ได้ SAN ครบถ้วนตั้งแต่ครั้งแรก การตรวจสอบ certificate ยุคใหม่ไม่สนใจ common name แล้ว แต่อ่านจาก extension ชื่อ Subject Alternative Name แทน เครื่องมือสร้าง argument หรือ config ของ SAN ให้ถูกรูปแบบ ซึ่งเป็นจุดพลาดที่พบบ่อยที่สุดของ openssl
• ออกแบบรอบ 4 งานที่คุณทำจริง แทนที่จะเป็น command builder ทั่วไปที่มีช่องกรอกพันช่อง เครื่องมือจัดระบบตาม workflow จริง: สร้าง CSR, ออก self-signed certificate, แปลง format และตรวจสอบสิ่งที่มีอยู่แล้ว
• ปลอดภัยกับข้อมูลอ่อนไหว ทุกอย่างทำงานในเบราว์เซอร์ ชื่อ host ภายในและชื่อองค์กรของคุณ — ซึ่งมักถูกนับเป็นข้อมูลอ่อนไหวในการ security review — ไม่ถูกส่งออกไปที่ไหนเลย
• คำสั่ง copy-paste พร้อมคำอธิบาย ทุกคำสั่งที่สร้างมาพร้อมคำอธิบาย flag แบบอ่านเข้าใจง่าย คุณจะได้เรียนรู้ syntax ไปด้วยระหว่างใช้ อีกเดือนข้างหน้าอาจไม่ต้องใช้เครื่องมือเลยก็ได้
• ผลลัพธ์สม่ำเสมอทุกสภาพแวดล้อม คำสั่งเดียวกันใช้ได้ทั้ง macOS, Linux และ Windows ที่ติดตั้ง OpenSSL — ไม่มีอาการ "ทำไมในเครื่องผมถึงรันได้" อีกต่อไป

Key Features

• Workflow แบบเลือก preset ก่อน เลือกงานเป็นอันดับแรก แล้วเครื่องมือจะแสดงเฉพาะช่องกรอกที่จำเป็นของงานนั้น
• รองรับ syntax ยุคใหม่ คำสั่งที่สร้างใช้รูปแบบปัจจุบันที่รองรับกว้าง เช่น -addext เมื่อใช้ได้
• เข้าถึงง่ายไม่มีขั้นต่ำ ไม่ต้องสมัคร ไม่ต้องติดตั้ง ไม่ต้องดาวน์โหลด template ใด ๆ

วิธีใช้งาน

1. เปิด OpenSSL Command Generator ในเบราว์เซอร์ แล้วเลือก task preset: สร้าง CSR, self-signed certificate, แปลง key หรือ PKCS12 หรือตรวจสอบ certificate
2. กรอกรายละเอียด subject — common name, organization และ locality — สำหรับงานที่ต้องใช้ ส่วน preset สร้าง CSR และ self-signed อย่าลืมเพิ่ม hostname ทุกตัวที่จะใช้เป็น Subject Alternative Name
3. เลือกตัวเลือก key เช่น RSA ขนาด 2048 หรือ 4096 บิต และว่าจะให้ private key ไม่ถูกเข้ารหัสหรือป้องกันด้วย passphrase
4. ตรวจคำสั่งที่สร้างออกมา แต่ละ flag มีคำอธิบายสั้น ๆ อยู่ข้าง ๆ ให้ยืนยันพฤติกรรมก่อนรันจริง
5. Copy คำสั่งไปวางใน terminal แล้วตรวจสอบผลลัพธ์ — เช่นด้วย preset ตรวจสอบ certificate ของเครื่องมือเดียวกันหรือ openssl x509 -text — ก่อนนำไป deploy

4 งานที่คุณทำจริง

1. สร้าง CSR

Certificate Signing Request คือไฟล์ที่คุณส่งให้ certificate authority — ไม่ว่าจะเป็น internal CA, Let's Encrypt ผ่าน client หรือผู้ให้บริการเชิงพาณิชย์ — เพื่อขอ certificate ที่เซ็นกลับมา ไฟล์ CSR มี public key และรายละเอียด subject ของคุณ ส่วน private key ยังอยู่กับคุณ ไม่ถูกส่งออกไปไหน

openssl req -new -newkey rsa:2048 -nodes \
  -keyout server.key -out server.csr \
  -subj "/CN=api.example.com/O=MyCompany" \
  -addext "subjectAltName=DNS:api.example.com,DNS:www.example.com"

• req — subcommand ที่ดูแลเรื่อง certificate request (และ self-signed certificate ด้วย ซึ่งค่อนข้างสับสน)
• -new — สร้าง request ใหม่ ไม่ใช่อ่านจากไฟล์ที่มีอยู่
• -newkey rsa:2048 — สร้าง RSA private key ขนาด 2048 บิตใหม่ควบคู่กับ request
• -nodes — "no DES": ให้ private key ไม่ถูกเข้ารหัส เพื่อให้ service ที่รันอัตโนมัติอ่านได้โดยไม่ต้องกรอก passphrase
• -keyout server.key — ตำแหน่งที่จะเขียน private key
• -out server.csr — ตำแหน่งที่จะเขียน CSR ที่จะส่งให้ CA
• -subj — ใส่ข้อมูล subject แบบ inline เพื่อข้ามคำถามแบบ interactive ของ openssl
• -addext subjectAltName=... — ฝัง SAN extension ลงไปตรง ๆ ถ้าไม่ใส่ CA ส่วนใหญ่จะออก certificate ที่เบราว์เซอร์ปฏิเสธ เพราะการตรวจสอบยุคนี้พึ่ง SAN ไม่ใช่ CN

สำหรับ request แบบหลายโดเมนที่ซับซ้อน วิธีดั้งเดิมคือใช้ config file ที่มี section req ระบุ distinguished_name และ subjectAltName เครื่องมือจะสร้างรูปแบบ inline เมื่อใช้ได้ และคุณดึงข้อมูลชุดเดียวกันไปทำเป็น config template ได้เสมอ

2. ออก self-signed certificate สำหรับ development

Self-signed certificate ช่วยให้คุณรัน https://localhost ตอน dev ได้โดยไม่ต้องจ่ายเงินหรือเกี่ยวข้องกับ CA เบราว์เซอร์จะเตือนเรื่อง certificate ไม่น่าเชื่อถือ — คุณกดผ่านครั้งเดียวแล้วเชื่อถือ certificate นั้นในเครื่อง — แต่ชั้น TLS ทำงานเหมือน production ทุกประการ

openssl req -x509 -newkey rsa:2048 -nodes -days 365 \
  -keyout localhost.key -out localhost.crt \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

• -x509 — ส่งออกเป็น self-signed certificate แทน certificate request ตัว flag เดียวนี่แหละที่ต่างจากคำสั่ง CSR
• -days 365 — ระยะเวลาอายุ certificate สำหรับ dev อายุสั้นก็พอ และการหมุนเวียนก็ง่ายมาก
• -addext พร้อม DNS:localhost,IP:127.0.0.1 — ใส่ SAN แม้จะเป็น hostname ในเครื่อง Chrome และเบราว์เซอร์อื่นก็ตรวจ SAN ของ localhost เช่นกัน ถ้าไม่มี SAN จะเจอ warning ที่แก้นานกว่าพิมพ์ flag อีก

ข้อควรรู้เรื่องความน่าเชื่อถือ: self-signed certificate จะน่าเชื่อถือเท่ากับที่คุณไปเชื่อถือมันในเครื่องไหน สำหรับ developer คนเดียวถือว่าโอเค แต่ถ้าเป็นทีม ควรพิจารณาทำ local root CA แล้วเซ็น certificate อายุสั้นให้แต่ละโปรเจกต์แทน

3. แปลงระหว่าง PEM, DER และ PKCS12

เรื่อง format ของ certificate เป็นแหล่งปัญหา integration ชั้นเยี่ยม เพราะแต่ละระบบนิยมคนละแบบ PEM คือข้อความ base64 ที่มี marker -----BEGIN CERTIFICATE----- ครอบ — เป็นภาษากลางของ server Linux, nginx, Apache และเครื่องมือส่วนใหญ่ DER คือรูปแบบ binary ที่พบบน Windows และระบบแวดวง Java มักใช้นามสกุล .cer หรือ .der PKCS12 (.pfx/.p12) คือ container ที่มี password ป้องกัน รวม certificate และ private key ไว้ด้วยกัน — เป็น format ที่ appliance, load balancer และบริการบน Windows หลายตัวต้องการ

openssl pkcs12 -export -out bundle.pfx \
  -inkey server.key -in server.crt -certfile chain.pem

• pkcs12 -export — สร้าง container แบบ PKCS12 โดย openssl จะถาม export password
• -inkey server.key — private key ที่จะรวมเข้าไป
• -in server.crt — server certificate
• -certfile chain.pem — intermediate certificate ที่จะใส่เพิ่มเพื่อให้ client ต่อ chain ได้ครบ

ทางกลับกัน — ดึง key และ certificate ออกจากไฟล์ PKCS12 เพื่อใช้กับ server ที่กิน PEM — ใช้ openssl pkcs12 -in bundle.pfx -out extracted.pem -nodes และเมื่อ Java หรือ appliance ขอ DER ให้ใช้ openssl x509 -in server.crt -outform der -out server.cer แปลงให้จบในบรรทัดเดียว เครื่องมือจะสร้างคำสั่งตามทิศทางที่คุณเลือก ไม่ต้องจำแล้วว่าคราวนี้ใช้ -outform หรือ -inform

4. ตรวจสอบ certificate และ CSR โดยไม่ต้องติดตั้งอะไร

ก่อน deploy คุณอยากรู้คำตอบของคำถามง่าย ๆ: certificate นี้ใช้ได้ถึงวันไหน ครอบคลุม hostname ใดบ้าง และใครเซ็นให้ ไม่จำเป็นต้องติดตั้งมันลง server ใด ๆ ก็หาคำตอบได้

openssl x509 -in server.crt -noout -text -dates -subject

• x509 — subcommand สำหรับประมวลผล certificate
• -noout — ไม่ต้องพิมพ์ certificate ต้นฉบับ (แบบ encoded) ออกมา แสดงเฉพาะสิ่งที่ขอ
• -text — dump แบบอ่านได้ทั้ง extension, SAN และรายละเอียด key
• -dates — พิมพ์ notBefore และ notAfter สองค่าที่อยู่เบื้องหลังเหตุ certificate หมดอายุแบบเงียบ ๆ
• -subject — พิมพ์บรรทัด subject รวมถึง common name

การตรวจสอบแบบเดียวกันใช้กับ CSR ได้ด้วย openssl req -in server.csr -noout -text — มีประโยชน์มากตอนยืนยันว่ารายการ SAN ถูกใส่ลง request จริง ก่อนคุณเผาโควตาการเซ็นของ CA ไป

Use Cases ในทางปฏิบัติ

พัฒนาเว็บแบบ HTTPS ในเครื่อง

งาน frontend ยุคนี้สมมติว่ารันใน secure context เสมอ: service worker, fetch ไปยัง API ที่เป็น HTTPS, cookie ที่ติด flag Secure สร้าง self-signed certificate ที่มี SAN ครบสำหรับ localhost ชี้ dev server หรือ reverse proxy ของคุณไปที่มัน แล้วสภาพแวดล้อม local ของคุณก็จะทำงานเหมือน production preset self-signed ของเครื่องมือสร้างคำสั่งนี้ให้ในคลิกเดียว

Workflow กับ internal CA

องค์กรที่รัน certificate authority ภายใน — ไม่ว่าจะ Microsoft ADCS, HashiCorp Vault, smallstep หรือ root CA ที่ทำเอง — รับ CSR เป็นจำนวนมาก engineer ใช้ preset สร้าง CSR เพื่อสร้าง CSR ที่มีรายการ SAN ถูกต้อง ส่งเข้า CA แล้วรับ certificate ที่เซ็นกลับมา คำสั่งที่เป็นมาตรฐานเดียวกันหมายถึง request ที่ถูกปฏิเสธน้อยลงและไม่มี subject line กำกวมอีกต่อไป

การหมุนเวียน certificate ก่อนหมดอายุ

Certificate หมดอายุเสมอ และอาการคือเงียบจนกว่าผู้ใช้จะเห็น warning ในเบราว์เซอร์ ลูปการหมุนเวียนที่เป็นระเบียบ: สร้าง CSR ใหม่ด้วยรายการ SAN ที่ตรวจสอบแล้ว ต่ออายุผ่าน CA ของคุณ แปลงเป็น format ที่ server ต้องการ deploy แล้วรันคำสั่งตรวจสอบเพื่อยืนยันว่า notAfter ใหม่ถูกต้อง ก่อนเก็บ certificate ตัวเก่าออก เมื่อทุกขั้นตอนเป็นคำสั่งที่ทำซ้ำได้ ทั้งลูปก็เขียนเป็น script ได้

อัปโหลดขึ้น appliance และ load balancer

Firewall, VPN concentrator, load balancer และคอนโซลจัดการ IoT จำนวนมากต้องการไฟล์ PKCS12 ที่มี password การแปลง key และ certificate chain แบบ PEM เป็น .pfx ใช้เวลาสองนาทีด้วย preset PKCS12 แทนที่จะออกเดินทางยี่สิบนาทีผ่านเอกสารที่อ้างถึงเวอร์ชัน openssl เมื่อสิบปีก่อน

Best Practices

• ใส่ SAN ให้ครบทุกครั้ง ระบุ hostname และ IP ทุกตัวที่ certificate ต้องครอบคลุม รวมถึงตัว www และชื่อภายใน SAN ที่ขาดหายคือสาเหตุอันดับหนึ่งของ browser warning บน certificate ที่ถูกต้องแล้ว
• ใช้ RSA อย่างน้อย 2048 บิต หรือเลือก ECDSA RSA 2048 คือขั้นต่ำที่ควรใช้ในทางปฏิบัติ RSA 4096 เพิ่มความปลอดภัยแต่แลกกับประสิทธิภาพ ถ้า stack รองรับ ECDSA P-256 ให้ความปลอดภัยสูงด้วย key ที่เล็กและเร็วกว่า
• ปกป้องไฟล์ private key หลังสร้าง server.key จำกัดสิทธิ์ทันทีด้วย chmod 600 server.key private key แบบไม่เข้ารหัสที่ user อื่นบน host ร่วมอ่านได้ คือเหตุการณ์ข้อมูลรั่วที่รอวันเกิด
• ตรวจสอบหลังทุกการเปลี่ยนแปลง รันคำสั่งตรวจสอบกับ certificate ใหม่และไฟล์ที่แปลงแล้วทุกครั้ง ยืนยันรายการ SAN, วันที่ และ chain ก่อน deploy — สามสิบวินาทีที่ช่วยประหยัดการจัดการเหตุการณ์หลายชั่วโมง
• อย่าใช้ certificate เดียวทุกที่ แยก key และ certificate ตามสภาพแวดล้อม เพื่อให้ key ของ dev ที่รั่วไม่เป็นภัยต่อ production
• จดวันหมดอายุไว้ในปฏิทินหรือระบบเฝ้าระวัง คำสั่งตรวจสอบบอกวันหมดอายุได้ เอาไว้ในที่ที่มีอะไรแจ้งเตือนคุณก่อนวันนั้นมาถึงจริง

เริ่มสร้างคำสั่งแรกของคุณวันนี้

CLI ของ openssl จะไม่มีวันอ่อนโยนลง แต่คุณเลิกต่อสู้กับมันได้ เปิด OpenSSL Command Generator เลือกงานที่ต้องการ — CSR, self-signed certificate, แปลง format หรือตรวจสอบ — แล้ววางคำสั่งที่ถูกต้องลงใน terminal ภายในไม่ถึงนาที เครื่องมือรันในเบราว์เซอร์ทั้งหมด ชื่อ host และข้อมูลองค์กรของคุณจึงอยู่บนเครื่องคุณเท่านั้น และทุก flag มีคำอธิบายกำกับ คราวหน้าคุณอาจไม่ต้องใช้เครื่องมือนี้เลยก็ได้

เครื่องมือที่เกี่ยวข้อง:

• PEM Certificate Decoder — ถอดรหัส X.509 certificate และ CSR ในเบราว์เซอร์ เพื่อดู subject, SAN และวันหมดอายุ
• Certificate Generator — สร้าง self-signed certificate ในเบราว์เซอร์โดยตรง สำหรับใช้ local development แบบรวดเร็ว
• Basic Auth Generator — สร้าง HTTP Basic authentication header สำหรับทดสอบ API endpoint อย่างปลอดภัย

ขอให้สนุกกับการสร้าง certificate!

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

ถ: ข้อมูลของฉันถูกส่งไปที่ server หรือไม่? ตอบ: ไม่ เครื่องมือนี้ประมวลผล 100% ฝั่ง client-side — การประกอบคำสั่งทั้งหมดเกิดขึ้นในเบราว์เซอร์ของคุณ ชื่อโดเมน รายละเอียดองค์กร หรือตัวเลือก key ไม่เคยถูกส่งหรือเก็บไว้ที่ใดเลย

ถ: ทำไมเบราว์เซอร์ถึงปฏิเสธ certificate ของฉันทั้งที่ common name ตรงแล้ว? ตอบ: เบราว์เซอร์ยุคใหม่ไม่ใช้ common name ในการตรวจสอบแล้ว แต่ต้องการให้ hostname ปรากฏใน extension ชื่อ Subject Alternative Name ควรใส่ argument -addext subjectAltName=... หรือ entry SAN ใน config ทุกครั้งที่สร้าง

ถ: PEM กับ DER ต่างกันอย่างไร? ตอบ: PEM คือข้อความ base64 ที่ห่อด้วย marker -----BEGIN และ -----END ใช้กับ nginx, Apache และเครื่องมือฝั่ง Unix ส่วน DER คือรูปแบบ binary ล้วนที่พบบน Windows และระบบ Java แปลงระหว่างกันด้วย openssl x509 -outform der หรือ -inform der

ถ: เมื่อไรต้องใช้ไฟล์ PKCS12 แทนไฟล์ PEM แยกกัน? ตอบ: เมื่อระบบปลายทาง — appliance, load balancer หรือบริการบน Windows — ต้องการ certificate และ private key ที่รวมอยู่ในไฟล์เดียวแบบ .pfx หรือ .p12 พร้อม password ป้องกัน ใช้คำสั่ง pkcs12 export เพื่อสร้างไฟล์นั้น

ถ: ใช้ self-signed certificate ที่สร้างได้ใน production ได้ไหม? ตอบ: ทำได้ในทางเทคนิคแต่ไม่แนะนำ self-signed certificate ทำให้ผู้เยี่ยมชมทุกคนเจอ browser warning และไม่มีการยืนยันตัวตนจากบุคคลที่สาม ควรใช้ certificate จาก CA สำหรับเว็บสาธารณะ และเก็บ self-signed certificate ไว้ใช้กับ local development และการทดสอบเท่านั้น