Pertanyaan Sertifikat sertifikat otoritas sertifikat lisensi kedaluwarsa dan perpanjangan


Pada tahun 2004, saya menyiapkan otoritas sertifikasi kecil menggunakan OpenSSL di Linux dan skrip manajemen sederhana yang disediakan dengan OpenVPN. Sesuai dengan panduan yang saya temukan saat itu, saya menetapkan periode validitas untuk sertifikat CA akar hingga 10 tahun. Sejak itu, saya telah menandatangani banyak sertifikat untuk terowongan OpenVPN, situs web dan server e-mail, yang semuanya juga memiliki masa berlaku 10 tahun (ini mungkin salah, tetapi saya tidak tahu lebih baik pada saat itu).

Saya telah menemukan banyak panduan tentang pengaturan CA, tetapi hanya sedikit informasi tentang pengelolaannya, dan khususnya, tentang apa yang harus dilakukan ketika sertifikat CA root berakhir, yang akan terjadi beberapa waktu pada tahun 2014. Jadi saya memiliki yang berikut ini pertanyaan:

  • Apakah sertifikat yang memiliki masa berlaku perpanjangan setelah berakhirnya sertifikat CA akar menjadi tidak valid segera setelah berakhirnya kedaluwarsa sertifikat, atau apakah sertifikat akan tetap berlaku (karena ditandatangani selama masa validitas sertifikat CA)?
  • Operasi apa yang diperlukan untuk memperbarui sertifikat CA akar dan memastikan transisi yang mulus selama kadaluarsa?
    • Dapatkah saya entah bagaimana menandatangani kembali sertifikat CA akar saat ini dengan periode validitas yang berbeda, dan mengunggah sertifikat yang baru ditandatangani ke klien sehingga sertifikat klien tetap valid?
    • Atau apakah saya perlu mengganti semua sertifikat klien dengan yang baru yang ditandatangani oleh sertifikat CA akar baru?
  • Kapan sertifikat CA akar harus diperbarui? Dekat dengan kedaluwarsa, atau waktu yang wajar sebelum kedaluwarsa?
  • Jika pembaruan sertifikat CA akar menjadi bagian utama dari pekerjaan, apa yang dapat saya lakukan lebih baik sekarang untuk memastikan transisi yang lebih mulus pada pembaruan berikutnya (singkat dari pengaturan masa berlaku hingga 100 tahun, tentu saja)?

Situasi dibuat sedikit lebih rumit oleh fakta bahwa hanya akses saya ke beberapa klien adalah melalui terowongan OpenVPN yang menggunakan sertifikat yang ditandatangani oleh sertifikat CA saat ini, jadi jika saya harus mengganti semua sertifikat klien, saya perlu menyalin file baru ke klien, restart terowongan, silang jari saya dan berharap itu muncul sesudahnya.


87
2017-08-30 08:34






Jawaban:


Menjaga kunci pribadi yang sama di root root Anda memungkinkan semua sertifikat untuk terus memvalidasi berhasil terhadap root yang baru; semua yang diperlukan dari Anda adalah mempercayai akar yang baru.

Hubungan penandatanganan sertifikat didasarkan pada tanda tangan dari kunci privat; menjaga kunci privat yang sama (dan, secara implisit, kunci publik yang sama) sambil menghasilkan sertifikat publik baru, dengan periode validitas baru dan atribut baru lainnya diubah sesuai kebutuhan, menjaga hubungan kepercayaan tetap berlaku. CRL juga dapat melanjutkan dari sertifikat lama ke yang baru, sebagaimana adanya, seperti sertifikat, yang ditandatangani oleh kunci privat.


Jadi, mari verifikasi!

Buat root CA:

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

Hasilkan sertifikat anak dari itu:

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

Tandatangani sertifikat anak:

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

Semua diatur di sana, hubungan sertifikat normal. Mari verifikasi kepercayaannya:

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

Ok, jadi, sekarang katakanlah 10 tahun berlalu. Mari hasilkan sertifikat publik baru dari kunci privat yang sama.

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

Dan .. apakah itu berhasil?

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

Tapi kenapa? Mereka file yang berbeda, kan?

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

Ya, tetapi, itu tidak berarti bahwa kunci publik baru tidak secara kriptografis sesuai dengan tanda tangan pada sertifikat. Nomor seri yang berbeda, modulus yang sama:

# 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

Mari kita sedikit lebih jauh untuk memverifikasi bahwa itu berfungsi dalam validasi sertifikat dunia nyata.

Jalankan instance Apache, dan mari kita coba (struktur file debian, sesuaikan sesuai kebutuhan):

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

Kami akan mengatur arahan ini pada VirtualHost mendengarkan di 443 - ingat, itu newroot.pem sertifikat root bahkan tidak ada saat itu cert.pem dihasilkan dan ditandatangani.

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

Mari kita lihat bagaimana openssl melihatnya:

# 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, dan bagaimana dengan browser menggunakan API crypto MS? Harus mempercayai root, pertama, maka semuanya baik, dengan nomor seri root yang baru:

newroot

Dan, kita harus tetap bekerja dengan root lama juga. Beralih konfigurasi Apache di sekitar:

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

Lakukan restart penuh pada Apache, reload tidak akan mengganti sertifikat dengan benar.

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

Dan, dengan browser API crypto MS, Apache menyajikan root lama, tetapi root yang baru masih ada di root store yang tepercaya pada komputer. Secara otomatis akan menemukannya dan memvalidasi sertifikat terhadap akar (baru) tepercaya, meskipun Apache menyajikan rantai yang berbeda (akar lama). Setelah mengupas akar baru dari akar tepercaya dan menambahkan sertifikat root asli, semuanya baik-baik:

oldroot


Jadi, itu dia! Simpan kunci pribadi yang sama saat Anda memperbarui, tukar di akar tepercaya baru, dan cukup banyak hanya berfungsi. Semoga berhasil!


124
2017-09-04 18:40



Anyways, apa gunanya membuat sertifikat root baru jika Anda hanya akan menggunakan kembali kunci pribadi yang sama? Jika Anda terus melakukan ini berulang-ulang, maka apa gunanya memiliki tanggal kedaluwarsa untuk sertifikat? Saya pikir berakhirnya root digunakan untuk memaksa admin untuk membuat kunci pribadi yang lebih baru (kemungkinan kuat) yang lebih aman terhadap mesin maju yang mencoba memecahkan kunci. Kunci 40 bit yang dibuat 20 tahun lalu tidak cukup aman untuk - jvhashe
@jvhashe Jika sertifikat root tidak lagi cukup kuat secara kriptografi, maka Anda harus menyingkirkannya terlepas dari tanggal kedaluwarsanya. Jika Anda menghasilkan akar Anda sendiri, tidak ada yang menghentikan Anda dari pengaturannya hingga kedaluwarsa ratusan tahun yang lalu ketika Anda tidak lagi berada di planet ini. Kedaluwarsa hampir tidak relevan pada sertifikat root - dan untuk sertifikat anak, kedaluwarsa tidak terlalu mengenai kekuatan kriptografi (minta CA yang bersiap untuk mencabut semua sertifikat 1024-bit pada bulan Oktober) - lihat sini untuk info lebih lanjut. - Shane Madden♦
Selain di atas, saya menemukan bahwa nomor seri harus sama agar metode ini berfungsi. - Scott Presnell
-set_serial 01 - WTF ??? ANDA TIDAK BISA MENGUBAH NOMOR SERIAL. Apakah Anda bahkan berkonsultasi RFC 4158, Internet X.509 Infrastruktur Kunci Publik: Pembuatan Jalur Sertifikasi? Atau apakah Anda hanya mengada-ada saat Anda pergi? Anda tidak tahu masalah yang Anda timbulkan di agen pengguna ketika mereka mulai membangun jalur. - jww
@jww Apakah Anda sudah membaca jawabannya? Itu hanya demonstrasi fakta bahwa kriptografi itu bekerja. Perintah itu secara harfiah hanya menghasilkan sertifikat uji yang dapat kami verifikasi nanti, untuk keperluan menguji hubungan antara sertifikat akar lama dan baru. Jika seseorang aku s menggunakan perintah-perintah itu secara langsung, saya pasti berharap ada sesuatu yang pecah, dan mereka menyadari bahwa mereka perlu memperhatikan konteks sesuatu sebelum secara membabi buta menjalankannya (atau melepaskan pegangan tentang apakah 01 adalah serial yang dapat diterima di laboratorium). - Shane Madden♦


Saya telah memperhatikan bahwa ekstensi CA bisa hilang dalam sertifikat baru dari kunci CA asli. Ini bekerja lebih tepat untuk saya (itu menciptakan a ./renewedselfsignedca.conf di mana ekstensi v3 CA didefinisikan, dan ca.key dan ca.crt diasumsikan sebagai kunci dan sertifikat CA asli):

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

13
2018-04-22 10:31



Ini merupakan tambahan yang sangat membantu. Jawaban yang benar-benar valid tidak menghasilkan sertifikat yang cukup kompatibel untuk saya jika Anda memiliki pengaturan sewenang-wenang pada ca root asli Anda. - Theuni
Ditingkatkan, sangat membantu. Tambahan lainnya: seperti Scott Presnell di komentar untuk jawaban yang diterima, saya juga harus secara manual menentukan nomor seri heksadesimal dari sertifikat baru sehingga cocok dengan yang lama. Ini berarti menambah -set_serial 0xdeadbeefabba (bukan serial nyata tidak :)) ke perintah x509 yang terakhir. Baru kemudian sertifikat klien saya berhasil diverifikasi terhadap sertifikat CA yang diperbarui. - JK Laiho
Metode ini lebih mudah karena menyimpan informasi yang sama dari sertifikat sebelumnya. - lepe
Saya telah membuat skrip untuk solusi ini plus -set_serial - lihat jawaban saya - Wolfgang Fahl
Jawaban ini menyelamatkan saya banyak pekerjaan, setelah menghabiskan hampir satu hari pada masalah yang membutuhkan ini, saya hampir menyerah, saya memberi tip kepada Anda untuk ini! - Onitlikesonic


Mode dasar untuk memperpanjang periode root yang valid (Anda membutuhkan X.509 publik dan kunci pribadi yang terkait):

Hasilkan CSR dari publik X.509 dan kunci pribadi:

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

Tandatangani ulang CSR dengan kunci pribadi:

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

2
2018-01-22 16:35





Ketika sertifikat root Anda berakhir, begitu juga sertifikat yang Anda tanda tangani dengannya. Anda harus membuat sertifikat root baru dan menandatangani sertifikat baru dengannya. Jika Anda tidak ingin mengulangi proses tersebut setiap beberapa tahun, satu-satunya pilihan yang nyata adalah memperpanjang tanggal valid pada root cert sesuatu seperti sepuluh atau dua puluh tahun: Akar yang saya hasilkan untuk penggunaan saya sendiri saya tetapkan dua puluh tahun.

Anda tidak dapat "memperbarui" sertifikat root. Yang bisa Anda lakukan adalah menghasilkan yang baru.

Hasilkan akar baru setidaknya satu atau dua tahun sebelum yang lama Anda berakhir sehingga Anda punya waktu untuk berganti tanpa melawan dinding waktu jika ada yang salah. Dengan cara itu Anda selalu dapat secara sementara beralih kembali ke sertifikat lama sampai Anda mendapatkan masalah gigi Anda dengan yang baru diselesaikan.

Sejauh terowongan VPN pergi, saya akan menyiapkan beberapa server percobaan untuk bereksperimen sehingga Anda memahami dengan tepat apa yang harus Anda lakukan sebelum Anda melakukannya dengan mesin klien.


0
2017-09-03 23:59



Balasan ini nampaknya menyarankan untuk memperbaharui sertifikat root, dengan menggunakan kembali kuncinya. Tapi saya menduga ini tidak berbeda dari memulai dari awal, karena sertifikat baru akan memiliki tanda tangan yang berbeda, dan karenanya tidak akan memvalidasi sertifikat klien yang ada. - Remy Blank
ya, Anda dapat memperpanjang masa berlaku ... dan lebih sedikit bekerja daripada membuat ulang semua pki, sertifikat klien, dan me ... - ggrandes
Bagian tentang mengeluarkan sertifikat entitas akhir yang baru belum tentu benar. Itu tergantung pada bagaimana Pengidentifikasi Kunci Otoritas (AKID) direpresentasikan dalam CA bawahan dan sertifikat entitas akhir. Jika AKID didasarkan {Nama Dibedakan, Nomor Seri}, maka kontinuitas akan tercapai. Juga lihat RFC 4518, Internet X.509 Infrastruktur Kunci Publik: Pembuatan Jalur Sertifikasi. - jww


@Bianconiglio plus -set_serial bekerja untuk saya. Server saya hanya intranet jadi saya tidak khawatir dengan banyak efek samping dan sekarang saya punya waktu untuk mengerjakan solusi yang "tepat".

Saya menggunakan skrip yang dapat dikonfigurasi berikut ini. Atur saja variabel CACRT, CAKEY dan 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

0
2018-06-30 17:33





Kami memiliki masalah yang sama, dan itu dalam kasus kami karena server Debian sudah kedaluwarsa, dan openSSL memiliki masalah ini:

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

Versi terakhir OpenSSL yang tersedia untuk Debian 6 membawa masalah ini. Semua sertifikat yang dibuat setelah 23.01.2018 menghasilkan Vality: untuk tahun 1901!

Solusinya adalah memperbarui OpenSSL. Anda dapat membuat lagi file konfigurasi (dengan sertifikat) untuk klien.


0
2018-03-09 10:38