14.4.4. CA-signed certificate (ที่ได้รับการเชื่อถือสาธารณะ)¶

Self-signed certificate ใช้งานได้เมื่อคุณควบคุมทั้งสองฝ่าย หาก client ทั่วไป (เบราว์เซอร์, โทรศัพท์, ซอฟต์แวร์บุคคลที่สาม) ต้องเชื่อมต่อกับกล้อง โดยไม่ ต้องบอกให้เชื่อถือ certificate แบบกำหนดเอง certificate จะต้องได้รับการเซ็นชื่อโดย public Certificate Authority (CA) ที่ client เหล่านั้นเชื่อถืออยู่แล้ว โค้ด TLS บนกล้องเหมือนกับกรณี self-signed ทุกประการ -- load_cert_chain พร้อม certificate และ key ในรูปแบบ DER -- เฉพาะวิธีที่คุณได้รับ certificate นั้นเท่านั้นที่เปลี่ยนไป

ประเด็นสำคัญที่สุดประการเดียว: คุณสร้าง private key เองและมันจะไม่ออกจากเครื่องของคุณ CA ไม่เคยเห็นมัน สิ่งที่คุณส่งให้ CA คือ certificate signing request (CSR) -- ไฟล์ขนาดเล็กที่มี public key และชื่อโดเมนของคุณ -- และสิ่งที่คุณได้รับกลับมาคือ certificate (public key และชื่อของคุณ ที่ CA เซ็นชื่อ) key และ certificate เป็นไฟล์แยกต่างหากที่ผลิตโดยสองขั้นตอนแยกกัน CA จัดการเฉพาะฝั่ง public เท่านั้น

ขั้นตอนทั่วไป ทำทั้งหมดบนเครื่องปกติ (ไม่ใช่บนกล้อง):

รับชื่อโดเมน CA สาธารณะจะรับรอง DNS name ที่คุณควบคุม (เช่น cam.example.com) พวกเขาจะไม่ออก certificate สำหรับ IP address เปล่าๆ หรือชื่อที่ใช้ได้เฉพาะภายใน เช่น mycam
สร้าง key และ CSR คำสั่ง OpenSSL คำสั่งเดียวสร้าง private key และ CSR ที่ตรงกัน ใช้ประเภท key เดียวกับที่คุณจะใช้สำหรับ self-signed certificate (ดู แนวคิด: ความเชื่อถือ, key, และรูปแบบไฟล์); แนะนำ ECDSA P-256

ECDSA P-256 -- แนะนำ:
```
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"
```
ECDSA P-384 -- แข็งแกร่งกว่า ขนาดใหญ่กว่า/ช้ากว่า:
```
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"
```
RSA-2048 -- ความเข้ากันได้สูงสุด:
```
openssl req -new -newkey rsa:2048 \
    -nodes -keyout domain.key -out domain.csr \
    -subj "/CN=cam.example.com" \
    -addext "subjectAltName=DNS:cam.example.com"
```
เก็บ domain.key ไว้เป็นความลับ -- นี่คือไฟล์ key ที่คุณจะนำไปวางบนกล้องในที่สุด domain.csr คือไฟล์ที่คุณส่งให้ CA ไม่มีความลับใดอยู่ในนั้น
ส่ง CSR และพิสูจน์ว่าคุณควบคุมโดเมน นี่คือจุดที่เส้นทางทั่วไปสองเส้นทางแตกต่างกัน:
- ACME CA อัตโนมัติ เช่น Let's Encrypt ขับเคลื่อนโดยเครื่องมืออย่าง certbot หรือ acme.sh จะทำขั้นตอน 2 และ 3 ให้คุณ: มันสร้าง key, สร้าง CSR, ตอบ challenge โดยอัตโนมัติ (HTTP-01: ให้บริการ token ผ่าน port 80 บนโดเมน, หรือ DNS-01: เผยแพร่ TXT record ใน DNS) และเขียนไฟล์ที่เสร็จสมบูรณ์
- CA เชิงพาณิชย์ (ซื้อโดยตรงหรือผ่านตัวแทนขายโดเมน/hosting): คุณวางข้อความ domain.csr ลงในแบบฟอร์มบนเว็บ จากนั้นพิสูจน์การควบคุมโดยการตอบกลับอีเมลตรวจสอบ การเผยแพร่ DNS record หรือวางไฟล์บนเว็บเซิร์ฟเวอร์ของโดเมนนั้น เมื่อตรวจสอบแล้วคุณดาวน์โหลดไฟล์ที่ออกให้
รวบรวมไฟล์ที่ออกให้ เพื่อทำความเข้าใจสิ่งที่คุณได้รับ มีประโยชน์ที่จะทราบว่า certificate ก่อตัวเป็น chain of trust: certificate ของโดเมนคุณถูกเซ็นชื่อโดย intermediate CA ซึ่งในทางกลับกันถูกเซ็นชื่อโดย root CA แต่ละลิงก์รับรองลิงก์ที่อยู่ด้านล่าง คุณจะได้:
- Private key ของคุณ (จากขั้นตอน 2) CA ไม่เคยมีมัน มันอยู่บนเครื่องของคุณและเป็น key ที่คุณจะนำไปวางบนกล้องในที่สุด
- Leaf certificate -- เรียกอีกชื่อว่า end-entity หรือ server certificate นี่คือ certificate สำหรับโดเมนเฉพาะของคุณ (cam.example.com): มีประกอบด้วย public key และชื่อของคุณ และถูกเซ็นชื่อโดย intermediate ของ CA นี่คือ certificate ที่กล้องนำเสนอเพื่อระบุตัวตน
- Intermediate CA certificate หนึ่งรายการหรือมากกว่า ("chain" หรือ "CA bundle") CA ไม่ได้เซ็น leaf ของคุณกับ root โดยตรง -- key ของ root ถูกเก็บออฟไลน์และได้รับการปกป้องอย่างเข้มงวด -- ดังนั้นมันจึงเซ็นด้วย intermediate ซึ่ง intermediate เองก็ถูกเซ็นโดย root intermediate คือลิงก์ที่เชื่อมต่อ leaf ของคุณขึ้นไปถึง root
Root certificate คือ trust anchor: self-signed certificate ที่เป็นของ CA ที่อยู่บนยอดของ chain คุณจะไม่ได้รับมันและไม่เคย deploy มัน เพราะ client ทุกตัวมีมันอยู่แล้ว -- ระบบปฏิบัติการ, เบราว์เซอร์, โทรศัพท์ และ language runtime จะมาพร้อมกับ "trust store" ในตัวของ root certificate Client เชื่อถือ leaf ของคุณโดยการเดิน chain: มันเชื่อถือ root อยู่แล้ว, root รับรอง intermediate และ intermediate รับรอง leaf ของคุณ (นี่คือสิ่งที่ server.der / cafile เดียวของคุณทำในกรณี self-signed -- ที่นั่น คุณ เองคือ root ของตัวเอง)

Fullchain file คือ leaf และ intermediate(s) ที่เชื่อมต่อกันเป็นไฟล์เดียว leaf ก่อน โดยตั้งใจ ไม่รวม root (การส่ง root ไม่มีประโยชน์ -- client เชื่อถือเฉพาะ root ที่มีอยู่แล้ว) server ปกติจะนำเสนอ fullchain ทั้งหมดนี้เพื่อให้ client ใดก็ตามสามารถเดินมันได้ แต่กล้องไม่สามารถทำได้: มันโหลดและนำเสนอ certificate หนึ่งใบ -- leaf -- และไม่สามารถส่ง intermediate certificate(s) ที่ CA ให้มาได้ด้วย

ชื่อไฟล์ที่คุณจะเห็นจริงๆ: เครื่องมือ ACME เช่น certbot จะเขียน privkey.pem (key ของคุณ), cert.pem (leaf เท่านั้น), chain.pem (intermediate(s) เท่านั้น) และ fullchain.pem (leaf + intermediate(s)) CA เชิงพาณิชย์มักจะให้ .crt สำหรับ leaf และ .ca-bundle สำหรับ intermediate(s) โดยที่ .key คือสิ่งที่คุณสร้างเอง
แปลงและคัดลอก แปลง private key และ leaf certificate เป็น DER และคัดลอกไปยังกล้องเหมือนกับใน ใบรับรอง Self-signed จากนั้นกล้องจะนำเสนอเป็น server certificate และ client มาตรฐานจะยอมรับการเชื่อมต่อโดยอัตโนมัติ เพราะพวกเขาเชื่อถือ CA อยู่แล้ว -- ไม่จำเป็นต้องกำหนดค่าฝั่ง client

Tip

ในทางปฏิบัติ กล้องที่นำเสนอเฉพาะ leaf (และไม่เคยนำเสนอ intermediate) จะส่งผลดังนี้:

Client ที่มี intermediate ของ CA cached อยู่แล้ว -- เบราว์เซอร์กระแสหลักและ HTTPS library มักจะทำ -- จะเติม chain ด้วยตัวเองและเชื่อมต่อได้ปกติ
Client ที่พึ่งพา server ในการจัดหา intermediate จะล้มเหลวใน handshake กับกล้อง

หากต้องการให้ client ทุกตัวที่เป็นไปได้สำเร็จ อย่าสิ้นสุด public TLS บนกล้องโดยตรง ให้วาง gateway / reverse proxy ไว้หน้ามันที่ให้บริการ chain เต็มรูปแบบกับโลกภายนอก และให้ proxy เข้าถึงกล้องผ่าน self-signed flow ที่อธิบายไว้ด้านบน