วิธีการตั้งค่า HTTPS และใบรับรอง SSL สำหรับ ONLYOFFICE Docker

ในการติดตั้ง ONLYOFFICE Docs ไว้หลัง HTTPS ใน Docker ให้ใช้ใบรับรองที่ตรงกับชื่อโฮสต์สาธารณะ ทำให้ใบรับรองนั้นสามารถใช้งานได้ภายในคอนเทนเนอร์ และเผยแพร่พอร์ต HTTPS ของคอนเทนเนอร์ HTTPS คือการเชื่อมต่อเว็บแบบเข้ารหัส ใบรับรอง TLS ช่วยให้เบราว์เซอร์ตรวจสอบได้ว่าได้เข้าถึงเซิร์ฟเวอร์ที่คาดหวังไว้แล้ว คู่มือนี้ใช้ใบรับรองและคีย์ส่วนตัวที่คุณได้รับจากหน่วยงานออกใบรับรองที่เชื่อถือได้ (CA) แล้ว หากคุณใช้พร็อกซีแบบย้อนกลับ ให้ทำตามตัวเลือกแยกต่างหากด้านล่าง เนื่องจากพร็อกซีอาจจัดการ HTTPS แทน

การตั้งค่า HTTPS แบบใดที่เหมาะสมกับการใช้งานของคุณ?

ONLYOFFICE Docs สามารถให้บริการ HTTPS ได้โดยตรงจากคอนเทนเนอร์ Docker หรืออาจใช้พร็อกซีแบบย้อนกลับ เช่น NGINX หรือ Traefik เพื่อรับ HTTPS และส่งต่อคำขอไปยัง Docs การใช้ TLS โดยตรงเป็นทางเลือกที่ตรงไปตรงมาสำหรับเซิร์ฟเวอร์แบบสแตนด์อโลนที่มีพอร์ตสาธารณะ 80 และ 443 ให้ใช้งานได้ พร็อกซีแบบย้อนกลับมักจะง่ายกว่าเมื่อบริการเว็บอื่นเป็นเจ้าของพอร์ตเหล่านั้นอยู่แล้ว หรือหลายเว็บไซต์ใช้เซิร์ฟเวอร์เดียวกัน หลีกเลี่ยงการกำหนดค่าทั้งสองเลเยอร์โดยไม่พิจารณาให้ดี: ตัดสินใจว่าส่วนประกอบใดเป็นตัวยุติ TLS และบันทึกไว้ว่าการเชื่อมต่อจากพร็อกซีไปยังคอนเทนเนอร์เป็น HTTP หรือ HTTPS

คู่มือนี้จะตั้งค่า HTTPS โดยตรงด้วยใบรับรองที่ออกโดย CA ONLYOFFICE ยังได้อธิบายตัวเลือก Let's Encrypt อัตโนมัติโดยใช้LETS_ENCRYPT_DOMAINและLETS_ENCRYPT_MAILซึ่งต้องใช้พอร์ต 80 และ 443 ที่สามารถเข้าถึงได้และไม่ได้ถูกใช้งานโดยพร็อกซีอยู่แล้ว ใบรับรองที่ลงนามด้วยตนเองมีประโยชน์สำหรับเครือข่ายทดสอบส่วนตัว แต่เบราว์เซอร์สาธารณะและบริการจัดเก็บข้อมูลที่เชื่อมต่อจะไม่เชื่อถือใบรับรองนั้นโดยอัตโนมัติ

คุณควรเตรียมอะไรก่อนเป็นอันดับแรก?

• โฮสต์ Linux ที่ติดตั้ง Docker Engine และปลั๊กอิน Docker Compose ไว้แล้ว
• เพิ่ม ระเบียน DNS A สำหรับชื่อโฮสต์ เช่นdocs.example.comที่ชี้ไปยังที่อยู่ IPv4 สาธารณะของโฮสต์นั้น เพิ่มระเบียน AAAA เฉพาะในกรณีที่กำหนดค่า IPv6 และสามารถเข้าถึงได้เท่านั้น
• กฎไฟร์วอลล์ขาเข้าและไฟร์วอลล์คลาวด์ที่อนุญาต TCP 443 หากคุณขอหรือต่ออายุใบรับรองที่มีการตรวจสอบ HTTP อาจจำเป็นต้องใช้ TCP 80 ด้วย
• ชุดใบรับรองสำหรับชื่อโฮสต์ที่ถูกต้องและคีย์ส่วนตัวที่ตรงกัน โดยทั่วไปหน่วยงานออกใบรับรองจะให้ไฟล์ชุดใบรับรองแบบเต็มและไฟล์คีย์ส่วนตัว
• ไดเร็กทอรีโฮสต์ถาวรสำหรับวอลุ่มข้อมูล ONLYOFFICE และรหัสลับ JWT ที่แข็งแกร่ง JWT (JSON Web Token) คือรหัสลับที่ใช้ร่วมกันเพื่อตรวจสอบความถูกต้องของคำขอระหว่าง Docs และแอปพลิเคชันที่ผสานรวมเข้าด้วยกัน

ขั้นตอนที่ 1: วางใบรับรองและคีย์ส่วนตัวไว้บนโฮสต์

ในตัวอย่างนี้ โฮสต์จะเก็บข้อมูลถาวรไว้ใน/srv/onlyoffice/data. แทนที่ชื่อโฮสต์และเส้นทางตัวอย่างด้วยของคุณเอง เก็บห่วงโซ่ใบรับรองทั้งหมดไว้ในtls.crtและคีย์ส่วนตัวที่ตรงกันไว้tls.keyในcertsไดเร็กทอรีย่อย:

sudo mkdir -p /srv/onlyoffice/data/certs
sudo install -m 0644 /path/to/fullchain.pem /srv/onlyoffice/data/certs/tls.crt
sudo install -m 0600 /path/to/privkey.pem /srv/onlyoffice/data/certs/tls.key
sudo chown root:root /srv/onlyoffice/data/certs/tls.key

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

ตรวจสอบวันที่และชื่อโฮสต์ของใบรับรองก่อนเริ่มใช้งานบริการ:

openssl x509 -in /srv/onlyoffice/data/certs/tls.crt -noout -subject -issuer -dates -ext subjectAltName

รายการ Subject Alternative Name (SAN) ควรประกอบด้วยชื่อโฮสต์ที่ผู้คนจะเข้าชมอย่างถูกต้อง คุณสามารถเปรียบเทียบกุญแจสาธารณะที่ได้จากใบรับรองและกุญแจส่วนตัวได้ โดยค่าแฮชทั้งสองควรตรงกัน:

openssl x509 -in /srv/onlyoffice/data/certs/tls.crt -pubkey -noout | openssl sha256
openssl pkey -in /srv/onlyoffice/data/certs/tls.key -pubout | openssl sha256

ขั้นตอนที่ 2: กำหนดค่าบริการ Docker Compose

เอกสาร Docker ของ ONLYOFFICE ระบุว่าใบรับรองจะอยู่ภายใต้/var/www/onlyoffice/Data/certsรายการตัวแปรสภาพแวดล้อมปัจจุบันกำหนดชื่อไฟล์ใบรับรองเริ่มต้นเป็นtls.crtและtls.keyในขณะที่คำแนะนำการติดตั้งตัวอย่างก็ใช้onlyoffice.crtและonlyoffice.keyเช่นกัน การกำหนดเส้นทางอย่างชัดเจนจะช่วยหลีกเลี่ยงการพึ่งพารูปแบบการตั้งชื่อไฟล์ ไดเร็กทอรีโฮสต์จะถูกเชื่อมต่อเข้ากับไดเร็กทอรีข้อมูลคอนเทนเนอร์ที่ตรงกัน และพอร์ต 443 จะถูกเผยแพร่เป็นพอร์ต 443 ของโฮสต์

สร้างcompose.yamlไฟล์ลักษณะนี้ โดยแทนที่ค่า JWT ตัวอย่างด้วยรหัสลับที่สร้างขึ้นสำหรับการติดตั้งของคุณ แท็กรูปภาพด้านล่างเป็นเพียงตัวอย่าง โปรดตรวจสอบรายการรูปภาพอย่างเป็นทางการและใช้เวอร์ชันที่คุณต้องการดูแลรักษา

services:
  documentserver:
    image: onlyoffice/documentserver:9.4.0
    container_name: onlyoffice-documentserver
    restart: unless-stopped
    ports:
      - "443:443"
    volumes:
      - /srv/onlyoffice/data:/var/www/onlyoffice/Data
    environment:
      SSL_CERTIFICATE_PATH: /var/www/onlyoffice/Data/certs/tls.crt
      SSL_KEY_PATH: /var/www/onlyoffice/Data/certs/tls.key
      JWT_SECRET: replace_with_a_long_random_secret

สร้างรหัสลับที่ปลอดภัยopenssl rand -hex 32และวางไว้ลงในไฟล์สภาพแวดล้อมหรือการกำหนดค่า Compose โดยกำหนดสิทธิ์การเข้าถึงไฟล์ให้เหมาะสม หากแอปพลิเคชันอื่นทำงานร่วมกับ Docs ให้กำหนดค่าแอปพลิเคชันนั้นด้วยรหัสลับ JWT เดียวกันและที่อยู่ HTTPS สาธารณะ หากเป็นการติดตั้งที่มีอยู่แล้ว ให้รักษาไดรฟ์ข้อมูล เครือข่าย ตัวแปรสภาพแวดล้อมอื่นๆ และการตั้งค่าการทำงานร่วมกันไว้เมื่อแก้ไขไฟล์ Compose ที่มีอยู่ อย่าแทนที่คำจำกัดความบริการที่ใช้งานได้อยู่แล้วด้วยตัวอย่างขั้นต่ำนี้

เริ่มหรือสร้างบริการขึ้นใหม่จากไดเร็กทอรีที่มีไฟล์ Compose:

docker compose up -d
docker compose ps
docker compose logs --tail=100 documentserver

ขั้นตอนที่ 3: ทดสอบ HTTPS และใบรับรอง

เปิดhttps://docs.example.comในเบราว์เซอร์ โดยแทนที่ด้วยชื่อโฮสต์ของคุณ ตรวจสอบว่าเบราว์เซอร์แสดงการเชื่อมต่อที่ปลอดภัยและไม่รายงานข้อผิดพลาดเรื่องชื่อไม่ตรงกัน ใบรับรองหมดอายุ หรือผู้ออกใบรับรองที่ไม่น่าเชื่อถือ ยืนยันว่าหน้าต้อนรับของ ONLYOFFICE Docs โหลดขึ้นมา เมื่อ Docs เชื่อมต่อกับ Nextcloud, ownCloud หรือแพลตฟอร์มอื่น ให้ทดสอบการเปิดและบันทึกเอกสารด้วย การล็อกเบราว์เซอร์เพียงอย่างเดียวไม่ได้พิสูจน์ว่าคำขอเรียกกลับหรือการกำหนดค่า JWT ของการผสานรวมทำงานได้

จากหน้าต่างคำสั่ง ให้ขอใบรับรอง TLS จากเซิร์ฟเวอร์ และทดสอบการตอบสนอง HTTPS:

openssl s_client -connect docs.example.com:443 -servername docs.example.com </dev/null
curl -I https://docs.example.com/

ตัวเลือก นี้-servernameจะส่งชื่อโฮสต์โดยใช้ Server Name Indication (SNI) ซึ่งช่วยให้เซิร์ฟเวอร์เลือกใบรับรองที่ถูกต้องเมื่อมีชื่อโฮสต์หลายชื่อใช้ที่อยู่เดียวกัน วันที่ของใบรับรอง ผู้ออกใบรับรอง และ SAN ควรตรงกับใบรับรองที่คุณติดตั้ง ตรวจสอบdocker compose logsว่าเบราว์เซอร์ไม่สามารถเชื่อมต่อได้หรือไม่ หรือคอนเทนเนอร์รีสตาร์ทซ้ำ ๆ

แล้วถ้าหากว่า Reverse Proxy จัดการ HTTPS อยู่แล้วล่ะ?

หาก NGINX, Traefik, Caddy หรือเกตเวย์โฮสติ้งมีพอร์ตสาธารณะ 80 และ 443 อยู่แล้ว อาจเป็นการดีกว่าที่จะติดตั้งใบรับรองสาธารณะที่พร็อกซีนั้น ในโครงสร้างดังกล่าว ให้เผยแพร่คอนเทนเนอร์ Docs เฉพาะบนเครือข่าย Docker ส่วนตัว หรือผูกพอร์ต HTTP เข้ากับ loopback จากนั้นกำหนดค่าพร็อกซีเพื่อส่งต่อคำขอและทราฟฟิก WebSocket ที่จำเป็น ตั้งค่าที่อยู่ ONLYOFFICE ของแอปพลิเคชันที่ผสานรวมเป็นhttps://URL สาธารณะ ปฏิบัติตามคำแนะนำปัจจุบันของพร็อกซีและ ONLYOFFICE สำหรับส่วนหัวที่ส่งต่อและ TLS ต้นทาง อย่าเผยแพร่พอร์ต 443 ของคอนเทนเนอร์บนพอร์ตโฮสต์เดียวกันกับที่พร็อกซีใช้งานอยู่แล้ว

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

ปัญหาที่พบได้บ่อยและวิธีแก้ไข

• เบราว์เซอร์แจ้งว่าใบรับรองไม่ถูกต้อง โปรดตรวจสอบชื่อโฮสต์ SAN วันหมดอายุของใบรับรอง ห่วงโซ่ใบรับรองทั้งหมด และตรวจสอบว่า DNS ชี้ไปยังโฮสต์ที่ต้องการ ใบรับรองสำหรับโดเมนหลักไม่ได้ครอบคลุมโดเมนย่อยโดยอัตโนมัติ
• คอนเทนเนอร์แจ้งว่าใบรับรองหรือคีย์หายไปตรวจสอบเส้นทางต้นทางของโฮสต์ ปลายทางของการเชื่อมต่อ (bind mount) ชื่อไฟล์ที่ถูกต้อง และSSL_..._PATHค่าทั้งสองค่า ไวยากรณ์ของ Docker --mountกำหนดให้เส้นทางต้นทางต้องมีอยู่จริง การเชื่อมต่อ (bind mount) ของ Compose ก็ควรชี้ไปยังไดเร็กทอรีที่มีอยู่จริงเช่นกัน
• พอร์ต 443 ถูกใช้งานอยู่แล้วโปรดหยุดบริการที่ขัดแย้ง ใช้พร็อกซีแบบย้อนกลับ หรือเลือกพอร์ตสาธารณะอื่น และตรวจสอบให้แน่ใจว่า URL และไฟร์วอลล์แสดงพอร์ตนั้น หากมีพร็อกซีอยู่ด้านหน้า พร็อกซีนั้นมักจะเป็นเจ้าของพอร์ตสาธารณะ 443 อยู่แล้ว
• HTTPS ใช้งานได้ แต่การแก้ไขเอกสารล้มเหลวตรวจสอบ URL การเชื่อมต่อ, รหัสลับ JWT บนทั้งสองบริการ, กฎการส่งต่อพร็อกซี และตรวจสอบว่า Docs สามารถเข้าถึงแพลตฟอร์มจัดเก็บข้อมูลได้หรือไม่ ทดสอบวงจรการเปิดและบันทึกจริง
• ใบรับรองได้รับการต่ออายุแล้ว แต่เว็บไซต์ยังคงใช้ใบรับรองเก่าอยู่ตรวจสอบว่าการต่ออายุได้อัปเดตไฟล์ที่ติดตั้งบนโฮสต์แล้ว และ ONLYOFFICE ได้โหลดไฟล์นั้นใหม่แล้ว หากจำเป็น ให้รีสตาร์ทบริการหลังจากต่ออายุ เช่น โดยใช้ Certbot deploy hook ที่ทำงานdocker compose restart documentserverจากไดเร็กทอรีโปรเจ็กต์ Compose ทดสอบการต่ออายุด้วยตัวเลือก dry-run ของ Certbot ก่อนที่จะใช้งานแบบอัตโนมัติ

หมั่นตรวจสอบใบรับรองให้เป็นปัจจุบันอยู่เสมอ

การตั้งค่า HTTPS จะไม่สมบูรณ์จนกว่าจะมีการวางแผนการต่ออายุ บันทึกว่าใครเป็นผู้ออกและต่ออายุใบรับรอง ตำแหน่งที่เก็บคีย์ส่วนตัว กระบวนการใดที่คัดลอกไฟล์ที่ต่ออายุแล้วไปยังไดเร็กทอรีที่เชื่อมต่อ และบริการจะโหลดไฟล์เหล่านั้นใหม่ได้อย่างไร เรียกใช้การทดสอบแบบจำลอง (dry-run test) ของไคลเอนต์การต่ออายุ ตรวจสอบการหมดอายุของใบรับรอง และตรวจสอบปลายทางสาธารณะหลังจากต่ออายุทุกครั้ง หากคุณใช้ตัวแปร Let's Encrypt ในตัวของ ONLYOFFICE แทนใบรับรองที่จัดการโดยโฮสต์ ให้ปฏิบัติตามคำแนะนำ Docker ปัจจุบันสำหรับวิธีการนั้น และตรวจสอบพฤติกรรมการต่ออายุสำหรับอิมเมจและการปรับใช้ที่คุณใช้งาน

สำหรับข้อมูลอ้างอิง โปรดดูคู่มือการติดตั้ง Docker และ HTTPS ของ ONLYOFFICE Docs , เอกสาร Docker bind-mount , เอกสาร Docker Compose , แท็กรูปภาพ Docker อย่างเป็นทางการของ ONLYOFFICEและคำแนะนำอย่างเป็นทางการของ Certbotแท็กและรายละเอียดอินเทอร์เฟซที่มีอยู่อาจมีการเปลี่ยนแปลง โปรดตรวจสอบเมื่อเตรียมการปรับใช้ใหม่