ใบรับรองรูทผู้มีสิทธิ์ออกใบรับรองหมดอายุและต่ออายุ

ในปี 2004 ฉันตั้งค่าการรับรองขนาดเล็กโดยใช้ OpenSSL บน Linux และสคริปต์การจัดการอย่างง่ายที่มาพร้อมกับ OpenVPN ตามคำแนะนำที่ฉันพบในขณะนั้นฉันตั้งค่าช่วงเวลาที่ใช้ได้สำหรับใบรับรองรูท CA เป็น 10 ปี ตั้งแต่นั้นมาฉันลงนามใบรับรองจำนวนมากสำหรับอุโมงค์ OpenVPN เว็บไซต์และเซิร์ฟเวอร์อีเมลซึ่งทั้งหมดนี้ก็มีช่วงเวลาที่ใช้งานได้ 10 ปี (ซึ่งอาจผิดปกติ แต่ฉันไม่รู้ตอนนั้นดีกว่า)

ฉันพบคำแนะนำมากมายเกี่ยวกับการตั้งค่า CA แต่มีข้อมูลน้อยมากเกี่ยวกับการจัดการและโดยเฉพาะเกี่ยวกับสิ่งที่ต้องทำเมื่อใบรับรอง CA หลักหมดอายุซึ่งจะเกิดขึ้นในปี 2014 ดังนั้นฉันจึงมีสิ่งต่อไปนี้ คำถาม:

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

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

การรักษาไพรเวตคีย์เดียวกันบนรูท CA ของคุณจะทำให้ใบรับรองทั้งหมดสามารถตรวจสอบกับรูทใหม่ได้สำเร็จ สิ่งที่คุณต้องการก็คือเชื่อใจในรูทใหม่

ความสัมพันธ์การลงนามใบรับรองขึ้นอยู่กับลายเซ็นจากคีย์ส่วนตัว การรักษารหัสส่วนตัวเดียวกัน (และโดยนัยคือรหัสสาธารณะเดียวกัน) ในขณะที่สร้างใบรับรองสาธารณะใหม่ด้วยช่วงเวลาที่มีผลบังคับใช้ใหม่และคุณลักษณะใหม่อื่น ๆ ที่เปลี่ยนไปตามที่จำเป็น CRL ก็สามารถดำเนินการต่อจากใบรับรองเก่าไปสู่ใบรับรองใหม่เช่นใบรับรองที่ลงนามโดยคีย์ส่วนตัว

ดังนั้นเรามาตรวจสอบ!

สร้างรูท CA:

openssl req -new -x509 -keyout root.key -out origroot.pem -days 3650 -nodes

สร้างใบรับรองลูกจากมัน:

openssl genrsa -out cert.key 1024
openssl req -new -key cert.key -out cert.csr

เซ็นชื่อรับรองเด็ก:

openssl x509 -req -in cert.csr -CA origroot.pem -CAkey root.key -create_serial -out cert.pem
rm cert.csr

ตั้งค่าทั้งหมดแล้วความสัมพันธ์ของใบรับรองปกติ ตรวจสอบความน่าเชื่อถือกันเถอะ:

# openssl verify -CAfile origroot.pem -verbose cert.pem
cert.pem: OK

ตกลงดังนั้นตอนนี้สมมติว่า 10 ปีผ่านไป มาสร้างใบรับรองสาธารณะใหม่จากรูทไพรเวตคีย์เดียวกัน

openssl req -new -key root.key -out newcsr.csr
openssl x509 -req -days 3650 -in newcsr.csr -signkey root.key -out newroot.pem
rm newcsr.csr

และ .. มันทำงานอย่างไร

# openssl verify -CAfile newroot.pem -verbose cert.pem
cert.pem: OK

แต่ .. ทำไม พวกมันต่างกันใช่ไหม?

# sha1sum newroot.pem
62577e00309e5eacf210d0538cd79c3cdc834020  newroot.pem
# sha1sum origroot.pem
c1d65a6cdfa6fc0e0a800be5edd3ab3b603e1899  origroot.pem

ใช่ แต่นั่นไม่ได้หมายความว่ารหัสสาธารณะใหม่ไม่ตรงกับลายเซ็นเข้ารหัสในใบรับรอง หมายเลขซีเรียลต่างกันโมดูลัสเดียวกัน:

# openssl x509 -noout -text -in origroot.pem
        Serial Number:
            c0:67:16:c0:8a:6b:59:1d
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d
# openssl x509 -noout -text -in newroot.pem
        Serial Number:
            9a:a4:7b:e9:2b:0e:2c:32
...
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bd:56:b5:26:06:c1:f6:4c:f4:7c:14:2c:0d:dd:
                    3c:eb:8f:0a:c0:9d:d8:b4:8c:b5:d9:c7:87:4e:25:
                    8f:7c:92:4d:8f:b3:cc:e9:56:8d:db:f7:fd:d3:57:
                    1f:17:13:25:e7:3f:79:68:9f:b5:20:c9:ef:2f:3d:
                    4b:8d:23:fe:52:98:15:53:3a:91:e1:14:05:a7:7a:
                    9b:20:a9:b2:98:6e:67:36:04:dd:a6:cb:6c:3e:23:
                    6b:73:5b:f1:dd:9e:70:2b:f7:6e:bd:dc:d1:39:98:
                    1f:84:2a:ca:6c:ad:99:8a:fa:05:41:68:f8:e4:10:
                    d7:a3:66:0a:45:bd:0e:cd:9d

ไปอีกหน่อยเพื่อตรวจสอบว่ามันทำงานในการตรวจสอบใบรับรองโลกแห่งความจริง

เปิดใช้งานอินสแตนซ์ Apache และปล่อยให้เป็นไป (โครงสร้างไฟล์เดเบียนปรับตามต้องการ):

# cp cert.pem /etc/ssl/certs/
# cp origroot.pem /etc/ssl/certs/
# cp newroot.pem /etc/ssl/certs/
# cp cert.key /etc/ssl/private/

เราจะตั้งค่าคำสั่งเหล่านี้เป็นการVirtualHostฟังใน 443 - จำไว้ว่าnewroot.pemใบรับรองหลักไม่ได้มีอยู่เมื่อcert.pemสร้างและเซ็นชื่อ

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/newroot.pem

มาดูกันว่า openssl เห็นอย่างไร:

# openssl s_client -showcerts -CAfile newroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIICHzCCAYgCCQCapHvpKw4sMjANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJB
...
-----END CERTIFICATE-----
(this should match the actual contents of newroot.pem)
...
Verify return code: 0 (ok)

ตกลงแล้วเบราว์เซอร์ที่ใช้ crypto API ของ MS ล่ะ ต้องเชื่อใจรูทก่อนแล้วทุกอย่างก็ดีด้วยหมายเลขซีเรียลใหม่:

และเราก็ควรจะทำงานกับรากเก่าเช่นกัน สลับการกำหนดค่าของ Apache ไปรอบ ๆ :

SSLEngine on
SSLCertificateFile /etc/ssl/certs/cert.pem
SSLCertificateKeyFile /etc/ssl/private/cert.key
SSLCertificateChainFile /etc/ssl/certs/origroot.pem

ทำการรีสตาร์ทแบบเต็มบน Apache การโหลดซ้ำจะไม่เปลี่ยน certs อย่างถูกต้อง

# openssl s_client -showcerts -CAfile origroot.pem -connect localhost:443

Certificate chain
 0 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=server.lan
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
   i:/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=root
-----BEGIN CERTIFICATE-----
MIIC3jCCAkegAwIBAgIJAMBnFsCKa1kdMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV
...
-----END CERTIFICATE-----
(this should match the actual contents of origroot.pem)
...
Verify return code: 0 (ok)

และด้วยเบราว์เซอร์ MS crypto API ทำให้ Apache แสดงรูทเก่า แต่รูทใหม่ยังอยู่ในที่เก็บรากที่เชื่อถือได้ของคอมพิวเตอร์ มันจะค้นหาโดยอัตโนมัติและตรวจสอบใบรับรองกับรากที่เชื่อถือได้ (ใหม่) แม้จะมี Apache แสดงห่วงโซ่ที่แตกต่าง (รูทเก่า) หลังจากลอกรูทใหม่ออกจากรูทที่ไว้ใจได้และเพิ่มรูทใบรับรองดั้งเดิมแล้วทั้งหมดก็ทำได้ดี:

นั่นแหล่ะ! เก็บคีย์ส่วนตัวเดิมไว้เมื่อคุณต่ออายุเปลี่ยนเป็นรูทที่เชื่อถือได้ใหม่และมันก็ใช้ได้ดีทีเดียว โชคดี!

ฉันพบว่าส่วนขยาย CA อาจหายไปในใบรับรองที่ต่ออายุของคีย์ CA ดั้งเดิม สิ่งนี้ทำงานได้อย่างเหมาะสมมากขึ้นสำหรับฉัน (มันสร้าง. /renewedselfsignedca.confโดยที่ v3 CA ส่วนขยายถูกกำหนดไว้และca.keyและca.crtจะถือว่าเป็นคีย์ CA ต้นฉบับและใบรับรอง):

openssl x509 -x509toreq -in ca.crt -signkey ca.key -out renewedselfsignedca.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > renewedselfsignedca.conf
openssl x509 -req -days 1095 -in renewedselfsignedca.csr -signkey ca.key -out renewedselfsignedca.crt -extfile ./renewedselfsignedca.conf -extensions v3_ca

โหมดพื้นฐานเพื่อขยายระยะเวลาของรูตที่ถูกต้อง (คุณต้องใช้ X.509 สาธารณะและคีย์ส่วนตัวที่เชื่อมโยง):

สร้าง CSR จากสาธารณะ X.509 และรหัสส่วนตัว:

openssl x509 -x509toreq -in XXX.crt -signkey XXX.key -out XXX.csr

ลงนาม CSR ด้วยคีย์ส่วนตัวอีกครั้ง:

openssl x509 -in XXX.csr -out XXX.crt -signkey XXX.key -req -days 365

@Bianconiglio plus -set_serial ใช้ได้สำหรับฉัน เซิร์ฟเวอร์ของฉันเป็นอินทราเน็ตเท่านั้นดังนั้นฉันจึงไม่ต้องกังวลกับผลข้างเคียงที่เกิดขึ้นและตอนนี้ฉันมีเวลาที่จะทำงานกับโซลูชันที่ "เหมาะสม"

ฉันใช้สคริปต์ที่กำหนดค่าได้ดังต่อไปนี้ เพียงตั้งค่าตัวแปร CACRT, CAKEY และ NEWCA

# WF 2017-06-30
# https://serverfault.com/a/501513/162693
CACRT=SnakeOilCA.crt
CAKEY=SnakeOilCA.key
NEWCA=SnakeOilCA2017
serial=`openssl x509 -in $CACRT -serial -noout | cut -f2 -d=`
echo $serial
openssl x509 -x509toreq -in $CACRT -signkey $CAKEY -out $NEWCA.csr
echo -e "[ v3_ca ]\nbasicConstraints= CA:TRUE\nsubjectKeyIdentifier= hash\nauthorityKeyIdentifier= keyid:always,issuer:always\n" > $NEWCA.conf
openssl x509 -req -days 3650 -in $NEWCA.csr -set_serial 0x$serial -signkey $CAKEY -out $NEWCA.crt -extfile ./$NEWCA.conf -extensions v3_ca
openssl x509 -in $NEWCA.crt -enddate -serial -noout

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

คุณไม่สามารถ "ต่ออายุ" ใบรับรองหลัก สิ่งที่คุณทำได้คือสร้างใหม่

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

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

เรามีปัญหาเดียวกันและในกรณีของเราเพราะเซิร์ฟเวอร์ Debian ล้าสมัยและ openSSL มีปัญหานี้:

https://en.wikipedia.org/wiki/Year_2038_problem

OpenSSL เวอร์ชันล่าสุดที่มีให้สำหรับ Debian 6 จะทำให้เกิดปัญหานี้ ใบรับรองทั้งหมดที่สร้างขึ้นหลังจาก 23.01.2018 สร้าง Vality: สำหรับปี 1901!

ทางออกคือการอัพเดท OpenSSL คุณสามารถสร้างไฟล์กำหนดค่าอีกครั้ง (พร้อมใบรับรอง) สำหรับลูกค้า