Giấy chứng nhận ủy quyền gốc hết hạn và gia hạn

Vào năm 2004, tôi đã thiết lập một tổ chức chứng nhận nhỏ sử dụng OpenSSL trên Linux và các tập lệnh quản lý đơn giản được cung cấp với OpenVPN. Theo các hướng dẫn tôi tìm thấy tại thời điểm đó, tôi đặt thời hạn hiệu lực cho chứng chỉ CA gốc là 10 năm. Kể từ đó, tôi đã ký nhiều chứng chỉ cho các đường hầm OpenVPN, các trang web và máy chủ email, tất cả đều có thời hạn hiệu lực là 10 năm (điều này có thể đã sai, nhưng lúc đó tôi không biết rõ hơn).

Tôi đã tìm thấy nhiều hướng dẫn về việc thiết lập CA, nhưng chỉ có rất ít thông tin về quản lý của nó và đặc biệt, về những gì phải làm khi chứng chỉ CA gốc hết hạn, điều này sẽ xảy ra vào năm 2014. Vì vậy, tôi có những điều sau đây Câu hỏi:

• Các chứng chỉ có thời hạn hiệu lực kéo dài sau khi hết hạn chứng chỉ CA gốc sẽ không hợp lệ ngay sau khi hết hạn, hay chúng sẽ tiếp tục có hiệu lực (vì chúng đã được ký trong thời gian hiệu lực của chứng chỉ CA)?
• Những hoạt động nào là cần thiết để làm mới chứng chỉ CA gốc và đảm bảo quá trình chuyển đổi suôn sẻ khi hết hạn?
  • Tôi bằng cách nào đó có thể ký lại chứng chỉ CA gốc hiện tại với thời hạn hiệu lực khác và tải lên chứng chỉ mới được ký cho khách hàng để chứng chỉ ứng dụng khách vẫn còn hiệu lực không?
  • Hoặc tôi có cần thay thế tất cả các chứng chỉ ứng dụng khách bằng các chứng chỉ mới được ký bởi chứng chỉ CA gốc mới không?
• Khi nào nên cấp lại chứng chỉ CA gốc? Gần hết hạn, hoặc một thời gian hợp lý trước khi hết hạn?
• Nếu việc gia hạn chứng chỉ CA gốc trở thành một công việc chính, tôi có thể làm gì tốt hơn bây giờ để đảm bảo quá trình chuyển đổi suôn sẻ hơn ở lần gia hạn tiếp theo (tất nhiên là không đặt thời hạn hiệu lực lên 100 năm)?

Tình hình trở nên phức tạp hơn một chút bởi thực tế là tôi chỉ truy cập vào một số khách hàng thông qua một đường hầm OpenVPN sử dụng chứng chỉ được ký bởi chứng chỉ CA hiện tại, vì vậy nếu tôi phải thay thế tất cả các máy khách, tôi sẽ cần sao chép các tập tin mới cho khách hàng, khởi động lại đường hầm, bắt chéo ngón tay của tôi và hy vọng rằng nó sẽ xuất hiện sau đó.

Giữ cùng khóa riêng trên CA gốc của bạn cho phép tất cả các chứng chỉ tiếp tục xác thực thành công đối với root mới; tất cả những gì bạn cần là tin tưởng vào root mới.

Mối quan hệ ký chứng chỉ dựa trên chữ ký từ khóa riêng; giữ cùng một khóa riêng (và, ngầm, cùng một khóa chung) trong khi tạo chứng chỉ công khai mới, với thời hạn hiệu lực mới và bất kỳ thuộc tính mới nào khác được thay đổi khi cần, sẽ giữ mối quan hệ tin cậy. CRL cũng vậy, có thể tiếp tục từ chứng chỉ cũ sang chứng chỉ mới, giống như chứng chỉ, được ký bởi khóa riêng.

Vì vậy, hãy xác minh!

Tạo một CA gốc:

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

Tạo chứng chỉ con từ nó:

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

Ký giấy chứng nhận con:

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

Tất cả đặt ở đó, mối quan hệ chứng chỉ bình thường. Hãy xác minh lòng tin:

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

Ok, vì vậy, bây giờ hãy nói 10 năm trôi qua. Hãy tạo một chứng chỉ công khai mới từ cùng một khóa riêng gốc.

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

Và .. nó đã làm việc?

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

Nhưng tại sao? Chúng là những tập tin khác nhau, phải không?

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

Có, nhưng, điều đó không có nghĩa là khóa công khai mới không khớp với chữ ký trên chứng chỉ. Số sê-ri khác nhau, cùng một mô-đun:

# 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

Chúng ta hãy đi xa hơn một chút để xác minh rằng nó hoạt động trong xác nhận chứng chỉ thế giới thực.

Khởi động một cá thể Apache và hãy thử xem (cấu trúc tệp debian, điều chỉnh khi cần):

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

Chúng tôi sẽ thiết lập các chỉ thị này khi VirtualHostnghe trên 443 - hãy nhớ rằng, newroot.pemchứng chỉ gốc thậm chí không tồn tại khi cert.pemđược tạo và ký.

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

Hãy xem cách openssl thấy nó:

# 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)

Ok, còn trình duyệt sử dụng API mật mã của MS thì sao? Trước tiên, hãy tin tưởng vào root, sau đó tất cả đều tốt, với số sê-ri của root mới:

Và, chúng ta vẫn nên làm việc với root cũ. Chuyển cấu hình của Apache xung quanh:

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

Thực hiện khởi động lại đầy đủ trên Apache, tải lại sẽ không chuyển đổi certs đúng cách.

# 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)

Và, với trình duyệt API mã hóa MS, Apache đang trình bày root cũ, nhưng root mới vẫn nằm trong kho gốc đáng tin cậy của máy tính. Nó sẽ tự động tìm thấy nó và xác nhận chứng chỉ dựa vào gốc đáng tin cậy (mới), mặc dù Apache trình bày một chuỗi khác (gốc cũ). Sau khi tước gốc mới từ gốc đáng tin cậy và thêm chứng chỉ gốc ban đầu, tất cả đều ổn:

À chính nó đấy! Giữ cùng khóa riêng khi bạn gia hạn, trao đổi trong thư mục gốc đáng tin cậy mới và hầu như tất cả chỉ hoạt động . Chúc may mắn!

Tôi đã nhận thấy rằng các tiện ích mở rộng CA có thể bị thiếu trong chứng chỉ được gia hạn của khóa CA gốc. Điều này hoạt động phù hợp hơn với tôi (nó tạo ra ./renewedelfsignca.conf trong đó các tiện ích mở rộng v3 CA được xác định và ca.key và ca.crt được coi là khóa và chứng chỉ CA gốc):

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

Chế độ cơ bản để kéo dài thời gian root hợp lệ (bạn cần khóa công khai X.509 và khóa riêng được liên kết):

Tạo CSR từ X.509 công khai và khóa riêng:

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

Ký lại CSR bằng khóa riêng:

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

@Bianconiglio plus -set_serial làm việc cho tôi. Máy chủ của tôi chỉ là mạng nội bộ nên tôi không lo lắng nhiều về tác dụng phụ là gì và bây giờ tôi có thời gian để làm việc với một giải pháp "phù hợp".

Tôi đã sử dụng kịch bản cấu hình sau đây. Chỉ cần đặt các biến CACRT, CAKEY và 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

Khi chứng chỉ gốc của bạn hết hạn, các certs bạn đã ký với nó cũng vậy. Bạn sẽ phải tạo một chứng chỉ gốc mới và ký chứng chỉ mới với nó. Nếu bạn không muốn lặp lại quy trình cứ sau vài năm thì lựa chọn thực sự duy nhất là gia hạn ngày hợp lệ trên chứng chỉ gốc giống như mười hoặc hai mươi năm: Root tôi tạo ra để sử dụng cho riêng mình, tôi đặt ra hai mươi năm.

Bạn không thể "gia hạn" chứng chỉ gốc. Tất cả những gì bạn có thể làm là tạo ra một cái mới.

Tạo một gốc mới ít nhất một hoặc hai năm trước khi cái cũ của bạn hết hạn để bạn có thời gian thay đổi mà không phải chống lại bức tường thời gian nếu có sự cố xảy ra. Bằng cách đó, bạn luôn có thể tạm thời quay trở lại các certs cũ cho đến khi bạn giải quyết được vấn đề mọc răng với cái mới.

Theo như các đường hầm VPN, tôi sẽ thiết lập một vài máy chủ thử nghiệm để thử nghiệm để bạn hiểu chính xác những gì bạn phải làm trước khi bạn làm điều đó với máy của khách hàng.

Chúng tôi đã có cùng một vấn đề và đó là trong trường hợp của chúng tôi vì máy chủ Debian đã lỗi thời và openSSL có vấn đề này:

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

Phiên bản OpenSSL cuối cùng có sẵn cho Debian 6 mang đến vấn đề này. Tất cả các chứng chỉ được tạo sau ngày 23.01.2018 tạo ra Vality: cho năm 1901!

Giải pháp là cập nhật OpenSSL. Bạn có thể tạo lại các tệp cấu hình (có chứng chỉ) cho máy khách.